I'm new to Reactive Programming. I have gone through the documentation of Reactive Cocoa but couldn't realize the differences between RACAble(), RACObserve() and RACBind().
Please, help ,me in understanding the aspects by some example code snippets.
I think the RACAble() is replaced with RACObserve() with some options/arguments. If I am not correct then please correct me in this regard.
Is RACObserve() skip: similar to RACAble()?
I think one big source of confusion here is that 3 months ago the ReactiveCocoa team released v2.0, which had quite a few breaking changes. This was a great release - and has some amazing features, but it does mean that much of the information you will find on the web is now out-dated.
To your specific points:
RACAble has been replaced with RACObserve
RACBind has been replaced with RACChannelTo
RACObserve is used to create a signal from an object and a keypath, in other words it allows you to take regular properties and 'lift' them into the ReactiveCocoa world. It is a handy replacement for KVO.
RACChannelTo provides a mechanism for two-way binding. In other words you can keep two properties synchronised. A good example of this is if you want to have a property in your view controller, or some model class, bound to a property on a UIKit control.
Another macro you will probably come across is RAC, this provides one-way binding. In other words it will set the value of the given property based on the latest value from a signal.
Related
I was looking into Fractal (tldr : data object/collection to json formatting library) today and saw some benefits to using it. However it's functionality seems to span across multiple layers of the app I'm working on. Hence a question appeared -- where does a code utilising Fractal belong to? Model, service, controller, some other place? The examples given in the documentation at the project docs seem to favour putting it in the controller or right in a route callback (more complex examples seem to be coming from Laravel app and the author mentioned it in his book on API).
My concern is coupling -- if I put it in the controller, as most of the usage examples show, then I'm pretty much bound to it in the future. My first instinct is to abstract it a little, make that abstraction bound to a contract and then put it to use. Might sound over engineered, but the API I'm working on "is aspiring" to be JSON-API compliant, so exchanging such a "json formatter" for something else sounds less crazy. Besides I still need to format error messages and Fractal seems no to touch that at all.
I'd like to take advantage of support for Eloquent's paginator and embedded resources, because that's always a pain. Only doing that makes it awkward (to say the least) at presentation/control layer. Even in the Fractal docs they resort to adding some extra methods to the controller class to prep Fractal objects. It seems a bit weird to me, but maybe it's just me. That's why take it here.
I'm aware that it might be a matter of preference, but I'm counting on somebody to have a reasonably sounding one :). Or perhaps a better solution altogether, keeping in mind that automation and json-api compliance are key reasons.
I did this once with an API class for a proprietary system with which my application needed to interface. The API returned objects that looked a lot like models, so I implemented a number of classes for the objects I needed and implemented a library to make the API calls and return the objects. Luckily, I only needed read access to the API, so my library implements only a small subset of the actions available.
Maybe you could abstract all the functionality you need (both Fractal and any Eloquent features) into a library class for which you have defined an interface. That way all the Fractal code is in one place and if you ever need to replace it, you just rewrite your custom library class (which might be a lot of work, but probably better than hunting down references to Fractal sprinkled throughout your code).
I have used pragmas in Pharo Smalltalk and have an idea about how they work and have seen examples for what they are used in Pharo.
My questions are:
what are pragmas conceptually,
to what construct do they compare in other languages,
when should i introduce a pragma?
I already found an interesting article about their history: The history of VW Pragmas.
You must think of it as Annotations attached to a CompiledMethod, or if you want as additionnal properties.
Then, thanks to reflection, some tools can walk other compiled methods, collect those with certain annotations (properties) and apply some special handling, like constructing a menu, a list of preferences, or other UI, invoking every class methods marked as #initializer, or some mechanism could be walking the stack back until a method is marked as an #exceptionHandler ...
There are many possibilities, up to you to invent your own meta-property...
EDIT
For the second point, I don't know, it must be a language that can enumerate the methods, and can attach properties to them.
The third point is also hard to answer. In practice, I would say you would use some already existing annotations, but very rarely create a new one, unless you're trying to create a new framework for exception handling, or a new framework for GUI (you want to register some known events or some handlers...). The main usage I would see is for extending, composing an application with unrelated parts, like a main menu. It seems like a relatively un-intrusive way to introduce DECLARATIVE hooks - compared to the very intrusive way to override a well known method TheWorld>>mainMenu. It's also a bit lighter than registering/un-registering IMPERATIVELY via traditional message send at class initialization/unoading. On the other hand, the magic is a bit more hidden.
While implementating aspect oriented programming i am getting confuse
Why Dojo having to two differentaspect library files?
When to use
dojo.aspect and dojox.lang.aspect ?
I have never heard about dojox.lang.aspect before, but according to git log the latest commit dates to 2008.
You can find an explanation why dojox.lang.aspect exists in an article by its author Eugene Lazutkin: AOP aspect of JavaScript with Dojo.
While it doesn't make much sense in some cases, we should realize that the primary role of dojo.connect() is to process DOM events.
[...]
To sum it up: events != AOP. Events cannot simulate all aspects of AOP, and AOP cannot be used in lieu of events.
So AOP in JavaScript sounds simple! Well, in reality there are several sticky places:
Implementing every single advice as a function is expensive.
Usually iterations are more efficient than recursive calls.
The size of call stack is limited.
If we have chained calls, it'll be impossible to rearrange them. So if we want to remove one advice in the middle, we are out of luck.
The “around” advice will “eat” all previously attached “before” and “after” advices changing the order of their execution. We cannot guarantee anymore that “before” advices run before all “around” advices, and so on.
Usually in order to decouple an “around” advice from the original function, the proceed() function is used. Calling it will result in calling the next-in-chain around advice method or the original method.
Our aspect is an object but in some cases we want it to be a static object, in other cases we want it to be a dynamic object created taking into account the state of the object we operate upon.
These and some other problems were resolved in dojox.lang.aspect (currently in the trunk, will be released in Dojo 1.2).
As of the latest Dojo 1.7, there is a strong tendency to differentiate between events and aspects, i.e. between dojo/on and dojo/aspect (both were implemented via dojo.connect before).
From a usage standpoint, dojo/aspect is a very simplified version of dojox/lang/aspect.
With dojo/aspect, you can create aspects corresponding to a named function (e.g. the "get" method in the "xhr" class), allowing you to create a before, after or around advice anytime xhr.get is called.
On the other hand, (TMHO) only dojox/lang/aspect provides enough features to play with aop.
It allows you to define your pointcuts with regular expressions, therefore allowing things like "execute an around advice for any functions whose name starts with get on any object"...
You can even pass-in an array of function names or regular expressions to which your aspects will be applied.
The blog post pointed by phusick gives good examples of that.
I asked a question earlier on here regarding the use of First Responder - and got a response here:
Trouble with First Responder
Would anyone mind giving me a 'dummies' version of this? Being new to Cocoa, I don't really know where to start with either one of these methods. I award answers quickly
Zach
First Responder is specifically this.
What you're asking about, though, is target-action. You have a UI object (button, menu item) that you need to cause multiple things to happen, but the UI object only sends one action.
Hence the solution: Make that action do multiple things.
Hook the UI object up to an action method you implement in your controller object (in your case, the document). In that method, do all the things the button needs to cause.
The subclassing solution is basically the same thing, except instead of hooking the UI object up to your document, you hook it up to the font manager, but you also make the font manager an instance of a subclass of NSFontManager that you create, rather than an instance of NSFontManager directly. In your subclass, you override addFontTrait: and add the other behavior in your implementation. At either the start or the end of that method, you send [super addFontTrait:sender] to invoke NSFontManager's implementation, so the original implementation gets done.
Long paragraph, but it's not actually all that much more work: The difference is just making the subclass and making the instance an instance of that subclass.
You've said before that “the Apple Documentation is incredibly vague”, but it's really not. There just happens to be a lot of it, and maybe you haven't been looking at the right documents.
These are the documents you need to read, from start to finish, and in order:
EDIT: This list is for Xcode 3. I posted an updated (for Xcode 4) version of this list in another answer.
The Objective-C Programming Language
The Memory Management Programming Guide for Cocoa
The Cocoa Fundamentals Guide (which explains target-action, among other things)
Application Architecture Overview
Resource Programming Guide
Interface Builder User Guide
The Xcode 3 guides:
Xcode Project Management Guide
Xcode Workspace Guide
Xcode Build System Guide
Xcode Debugging Guide
Document-Based Applications Overview
There is also an Instruments User Guide, but, unfortunately, that one is vague—or, to be more precise, incomplete. It omits a lot of useful information, like how to use Instruments' Zombies template to debug crashes. It's a high-level overview, nothing more.
Also, bookmark these:
Cocoa Core Competencies, a quick reference to all the concepts you need to use
The Foundation Framework Reference
The AppKit Framework Reference
The Core Foundation Framework Reference
The Core Graphics Framework Reference
That's a lot of reading, but it'll tell you everything you need to know, and that order is roughly the order you'll need to know it in.
The other answer says that you have two options:
First: Do replace the action by the one created by you and then implement the feature of the original version yourself. In this case, it suffices to just call the appropriate method of NSFontManager. That is, you add the original functionality to your own implementation of the method. This way, both actions are executed.
Second: Subclass the class where the original functionality is implemented and add your implementation by overriding the method that is called -addFontTrait. This way, your code gets executed "alongside". This question might help you to find the correct implementation.
So, the essence is that you can either add the original functionality to your implementation or the other way around. In this case, I would try the first one.
Has anyone implemented Futures in Objective-C? I (hopefully not naively) assume that it should be reasonably simple to wrap NSInvocations in a nice API?
Mike Ash has implemented Futures using Blocks:
http://www.mikeash.com/pyblog/friday-qa-2010-02-26-futures.html
http://www.mikeash.com/pyblog/friday-qa-2010-03-05-compound-futures.html
PromiseKit seems quite popular. There's my Collapsing Futures library. There's also RXPromise. And plenty more.
Some notes between those three:
PromiseKit has Swift support
Each can be installed via CocoaPods.
Each automatically flattens doubly-future values into singly-future values.
Each is thread-safe.
RXPromise and PromiseKit act like Promises/A+ from JavaScript.
They differ in how futures are controlled. In collapsing futures there's a FutureSource, which has-a future instead of is-a future. In RXPromise and PromiseKit, a future is its own source.
They differ in how future are cancelled. In RXPromise the consumer calls cancel on the future itself. In collapsing futures, the producer cancels a token it gave to the method that made the future. I don't know what PromiseKit does.
All have excellent documentation on each method.
I'm biased towards collapsing futures, since I wrote it and so clearly prefer the design decisions it made. I think keeping control separate is hugely important because it helps prevent self-sustaining reference cycles (not an issue in JS, but definitely an issue in Obj-C when working with blocks). I also think cancel tokens simply make things easier. On the other hand, acting like a well-known spec from a well-known language would be really nice.
MPWFoundation has futures based on Higher Order Messaging:
Assuming you have a regular computation with a message computeResult:
result = [someObject computeResult];
prefixing that message with the future message will compute the result in the background:
result = [[someObject future] computeResult];
The object in result is a proxy that will block when messages are sent to it until the value is received.
Apple's documentation on blocks in Grand Central Dispatch may be of interest.