How do I implement C# style signals or AS3 style events in Scala? I mean mostly observer pattern. To dispatch change events. Thanks.
Or (what's even better) are there any libraries/framework which do just that?
I'd suggest reading Deprecating the Observer Pattern first, for inspiration and to get a taste of where things are going.
Then, have a look at how scala-swing uses "reactions" to see how you can do this kind of thing in a library.
Finally, note that first-class functions make implementing the observer pattern yourself relatively easy.
Related
I've seen some discussion going on around using Observables instead of tasks with async/await. I currently make use of CreateFromTask almost exclusively. I've been trying to understand the reasoning behind using CreateFromObservable instead of CreateFromTask.
And if so, what would be the best way to convert a CreateFromTask to a CreateFromObservable.
CreateFromTask is really only there as a helper because we live in a predominantly Task based world :-) In a perfectly reactive world all the libraries you use would just expose Observables. Then you can just be end to end Observables. But seeing as how this isn't the case RxUI includes some helpers to easily pull Tasks into the Commands.
If you look here
https://github.com/reactiveui/ReactiveUI/issues/1245
You'll see there's even a discussion to just get rid of these helpers.
if you look at the code for "CreateFromTask" all it does is call ToObservble() on the task to convert it to an Observable and then the code calls CreateFromObservable
https://github.com/reactiveui/ReactiveUI/blob/develop/src/ReactiveUI/ReactiveCommand.cs#L418
So to that question I would just say calling ToObservable on the Task is the best way to convert it. You'll need to include this using statement
using System.Reactive.Threading.Tasks
What I normally do is just wrap all my Task based libraries with a facade and expose them using ToObervable. If you're going with a reactive solutions it will just make life easier to work in the land of Observables opposed to mixing and matching.
The reasoning behind CreateFromObservable over CreateFromTask is that the library assumes your solution is primarily reactive so that's going to be the primary way it is going to expect things. All the other ways to create those Commands are really just helpers that eventually make there way to CreateFromObservable
This is probably another thick, newbie question that will have everyone smacking their foreheads and going 'Duhhhhh!' BUT, after another long spell of reading and watching countless Brad Larson videos, I'm left perplexed at why delegation in general and CALayer delegation in particular seems to be such an enigmatic theme.
All the books and Dr Larson bang on about 'not sub-classing CALayers' unless you want a high degree of encapsulation but nowhere have I found a succinct and to-the-point example of the benefits that CALayer delegation can offer. Everyone seems to use either, the host view controller object as a, sort-of, perfunctory delegate or they shovel everything into the App delegate "as a brief example of what can be achieved".
I'm trying to learn "BEST PRACTICE" up-front - because I'm so new and because I don't want to develop any bad or slovenly programming traits - so I'm keen to examine each new step I take in minute detail. From what I can gather, a CALayer delegate class only has about 3 delegate-specific methods in it. These are 'displayLayer:', 'drawLayer:InContext:' and 'actionForLayer:ForKey:'. In my Opacity-generated Quartz stuff, I have used colour variables which I want to manipulate at runtime and do so without sub-classing CALayer. One of the side-effects of using Key-Value pairs is that there exists a class method called 'defaultValueForKey:' which describes the initial value of my colours according to the key value used to identify them. This is NOT (apparently) a CALayer delegate method. So how can I implement this code (which, after, all only sets a default value) without sub-classing CALayer? It seems that delegation is OK as long as you only need the few delegate-specific methods.
Could anyone explain why, when implementing delegation, the boffins at Apple didn't simply transpose the method-definition compilation unit from the class unit to the assigned delegate unit. e.g. Simply place an initial parameter in front of every method usually available in the class (or sub-class) by the phrase; 'forLayer: (CALayer *) TheRest: OfThe: method'? This way a simple switch or if-then stack could apply the usual method-ry of the class in one centralised object - the delegate.
As I said at the beginning, I'm probably missing something pretty basic but could anyone tell me how I implement all my key-value colour variable inits without sub-classing CALayer?
Thanks in advance,
V.V.
You're over thinking it all. As you mentioned, you're new to the platform. There are many idioms in Cocoa, but one of the idioms is a bit like Perl: "there's more than one way to do it".
Cocoa has a history of delegation because much of the time, you just need a method or two, and who wants the complexity of a zillion classes with few methods. Delegates let you work around that in a simple way.
So, basically rather than analyzing everything from the overall engineering point of view, just use the platform. Write some code. Write some code the "wrong way". Write lots of it.
Why? Because if it's the "wrong way", you will feel it yourself. You'll start cursing it in maintenance or whatever, and then you'll figure out the "right way". What is the "right way"? The way that feels better for YOU.
Most of these decisions have minimal impact on performance, etc., so don't worry about it. And because of that, it doesn't really matter which technique you choose.
Write code. Write lots of it. The more you write the more you'll get a feel as to when what technique is right, and which one is wrong. Or when the right way before now becomes the wrong way and should be refactored in to the new right way.
Because what's right or wrong now may not be later.
I've occasionally found myself in situations where I have to type out redundant code... where only one variable or two will change in each block of code. Usually I'll copy and paste this block and make the necessary changes on each block of code... but is there a better way to handle this?
Heavy use of cut and paste usually means there's something not quite right in the design of the code. Think about how you could refactor such as breaking out the cut/paste functionality into commonly called methods.
Yes. There is always a better way to do it than copy-and-paste. You should always get a little uneasy (kind of like you feel when you're about to give a speech in front of a huge crowd) when you're about to hit "Ctrl-V."
In almost any introductory class you're likely to be using a language that has functions, methods, or sub procedures. (What they're called and what they do depends on the language in question). Any variable that changes needs to be a parameter to that function/method/subprocedure.
When you do that (and the method/function/sub is accessible) you can replace the HUGE chunks of code with a single call to your new m-f-s.
There are a lot of other ways to do this, but when you're just getting started this is probably the way to go.
you have a lot of approaches to this situation. I don't know if you're working with OO or structured programming but you can build methods or functions and give them cohesion and unique responsibilities. I think it's an easy way of thinking...
In the OO paradigm we use some therms on how to avoid this situation: cohesion and low decoupling (you could search for them over the Internet). If you can apply both of them in your code, it will be easier to read and maintain.
That's all
Pardon my ignorance, but What is a Metaobject protocol, and does Ruby have one? If not, is it possible to implement one for Ruby? What features might a Metaobject protocol possess if Ruby was to have one?
What is a Metaobject protocol?
The best description I've come across is from the Class::MOP documentation:
A meta object protocol is an API to an object system.
To be more specific, it abstracts the components of an object system (classes, object, methods, object attributes, etc.). These abstractions can then be used to inspect and manipulate the object system which they describe.
It can be said that there are two MOPs for any object system; the implicit MOP and the explicit MOP. The implicit MOP handles things like method dispatch or inheritance, which happen automatically as part of how the object system works. The explicit MOP typically handles the introspection/reflection features of the object system.
All object systems have implicit MOPs. Without one, they would not work. Explicit MOPs are much less common, and depending on the language can vary from restrictive (Reflection in Java or C#) to wide open (CLOS is a perfect example).
Does Ruby have one?
According to this thread on Reopening builtin classes, redefining builtin functions? Perlmonks article I think the answer is no (at least in the strictest sense of what a MOP is).
Clearly there is some wriggle room here so it might be worth posting a question in the Perl side of SO because the Class::MOP / Moose author does answer questions there.
If you look closer to the definition, youll see that Ruby does have a MOP. Is it like the one in CLOS? No, CLOS is a meta-circular MOP which is great (I'd even say genius), but it's not the one true way, take a look at Smalltalk. To implement a (let's say basic) MOP all you need is to provide functions that allow your runtime to:
Create or delete a new class
Create a new property or method
Cause a class to inherit from a different class ("change the class structure")
Generate or change the code defining the methods of a class.
And Ruby provides a way to do all that.
On a side note: The author of Class::MOP is right (IMHO) when it claims that some of the things you can do with a meta circular MOP can be hard to do in Ruby (DISCLAIMER: I have zero, zilch, nada Perl knowledge, so I'm thinking Smalltalk like MOP vs CLOS like MOP here) but most of them are very specific (I'm thinking about metaclass instantation here) and there are ways to make things work without them. I think it all depends on your point view, meta circular MOPs are cooler but more on the academic side and non meta circular MOPs are more practical and easier to implement.
Is there is a generic, widely understood term for GUI elements. I have programmed so many GUI toolkits, I couldn't tell if Windows-only programmers know what the Java crowd means when they talk about widgets. Does a GTK+ user know what a control is? And does anybody besides me remember gadgets?
Qt uses widgets, Swing uses Components. Most gui programmers will understand what you mean when you say a scroll-widget/component.
As component is to generic, I'd say: Visual component.
It just describes exactly what it is: a visible, self-contained element, that does some well-defined task.
According to my Human-Computer Interaction teacher and to the this HCI manual the name is "widget".
Component?
I would say "element". "Component" evokes COM object for me.
I don't think there is one term to cover it, but window, component, widget and control are all in widespread use, so I would think most developers understand them all, although they may mean slightly different things in different frameworks (i.e. which is the lowest common class/component in the framework).
Actually, I think GUi element (or graphical element/interface element) is a pretty good catch-all term.
As noted in this SO question, naming is hard, and that makes this question very much program-related!
As specified in the javadoc of org.eclipse.swt.widgets.Widget, a Widget refers to "user interface objects" in general.
So it might be more precise than the too-generic term "component".
Symbian (currently) uses controls, but S60 is in the process of moving to QT so this is likely to move to widgets.
I'd suggest that you stick to the convention of your GUI framework. That way people who invested the time to learn the framework will know what you mean, and those who don't wouldn't know what you meant till they did anyway. If it's for a framework independent article or some such, define what you mean either at the start or in an appendix (for example: control - a GUI element, also commonly known as component, widget, etc).