Apple has deprecated NSObject's poseAsClass: method for OS X v10.5 and above. Is there another way to make class posing work?
I don't think there is a class-level equivalent, but you can exchange the implementation of two methods, which was often the purpose of using poseAsClass: (of course, you can exchange more than one method if you need to override multiple methods in a class). You want method_exchangeImplementations in the Objective-C 2.0 runtime (#import objc/runtime.h). A word of warning: after calling method_exchangeImplementations, calling the 'new' method actually calls the original method definition.
Lap Cat gives an alternative.
What are you trying to do? There are often ways around posing. I will concede, though, that it is sometimes the only way :)
Related
I'm desperately trying to learn and implement the AVCaptureMetadataOutput object type which Apple has documentation for here:
But you can see that on that page all of the code types are crossed out, saying they're only available in OS X 10.9. But that method seems like it is a pre-requisite for implementing AVMetadataFaceObject which is only available in OS X 10.10 - per this page:
I'm very confused and don't know why they (Apple) would introduce a new feature but require a method which has been depreciated for it to work.
Now my code is just throwing out "not available on OS X" errors and I don't know where to turn. Have I completely missed something and can anyone help?
Quoting OP in comment:
"also sorry for calling things the wrong names - perhaps when I'm typing like this I should just call things "things" rather than randomly guessing at "object" "type" "method" etc."
Use Core Image’s CIDetector and CIQRCodeFeature classes. They’ll find and decode the information and even correct for rotation and perspective issues.
(Source)
I'm build a library for generic reporting, Excel(using Spreadsheet), and most of the time I'll be writing things out on the last created worksheet (or active as I mostly refer to it).
So I'm wondering if there's a naming convention for methods that are mostly sugar to the normal/unsugared method.
For instance I saw a blog post, scroll down to Composite, a while ago where the author used the #method for the sugared, and #method! when unsugared/manual.
Could this be said to be a normal way of doing things, or just an odd implementation?
What I'm thinking of doing now is:
add_row(data)
add_row!(sheet, data)
This feels like a good fit to me, but is there a consensus on how these kinds of methods should be named?
Edit
I'm aware that the ! is used for "dangerous" methods and ? for query/boolean responses. Which is why I got curious whether the usage in Prawn (the blog post) could be said to be normal.
I think it's fair to say that your definitions:
add_row(data)
add_row!(sheet, data)
are going to confuse Ruby users. There is a good number of naming conventions is the Ruby community that are considered like a de-facto standard for naming. For example, the bang methods are meant to modify the receiver, see map and map!. Another convention is add the ? as a suffix to methods that returns a boolean. See all? or any? for a reference.
I used to see bang-methods as more dangerous version of a regular named method:
Array#reverse! that modifies array itself instead of returning new array with reversed order of elements.
ActiveRecord::Base#save! (from Rails) validates model and save it if it's valid. But unlike regular version that return true or false depending on whether the model was saved or not raises an exception if model is invalid.
I don't remember seeing bang-methods as sugared alternatives for regular methods. May be I'd give such methods their own distinct name other then just adding a bang to regular version name.
Why have two separate methods? You could for example make the sheet an optional parameter, for example
def add_row(sheet = active_sheet, data)
...
end
default values don't have to just be static values - in this case it's calling the active_sheet method. If my memory is correct prior to ruby 1.9 you'd have to swap the parameters as optional parameters couldn't be followed by non optional ones.
I'd agree with other answers that ! has rather different connotations to me.
For example, is it theoretically safe to modify Object#object_id since there's always Object#__id__ if you really need to know what an object's id is?
Background: Curiosity piqued by What's another name for object_id?
In an ideal system where everything is perfectly documented and all people working with the code are aware of what's been re-defined and patched - then yes, maybe.
But as we all know, such situations rarely exist. Personally, I feel that patching anything already defined in Kernel, Class, Module or Object is a no-no (unless you're doing it at a framework level.)
Ultimately, I believe that Principle of Least Surprise should permeate coding decisions at all levels.
is it theoretically safe to modify Object#object_id
Well, I think we are probably more concerned with reality than theory here. The fact is, people aren't going to use the __X__ version until they realize that you have overriden and completely jacked up the default behavior. With power comes responsibility; use monkey-patching carefully and never introduce unexpected behavior. Better just to add a new method to the class instead.
I find myself doing this pretty often. Currently I am cut/pasting the variable declaration, the property, the #synthesize, and usually also the release call in the dealloc method. That's four copy and pastes. Is there an easy way to do all of that at once.
There's not an automated to do this per se, however this article by Matt Gallagher has a user script you can use to add the #property, #synthesize, and -release lines from a given ivar. This should alleviate some of your pain.
http://cocoawithlove.com/2008/12/instance-variable-to-synthesized.html
As a ruby newbie, I was wondering, will gems ever conflict with eachother? For example, if 2 gems overrode the << method on array, which would win, or is there something to stop this?
Thanks
I assume you are talking about redefining methods, not overriding them, right? If two libraries overrode the same method in two different subclasses, there wouldn't be any problem.
If two or more libraries redefine the same method, then whichever one happens to be loaded last wins. In fact, this is actually no different than just one library redefining a method: the Ruby interpreter provides an implementation of Array#<< for you, and if you redefine it, your definition wins, simply because it came later.
The best way to stop this is simple: don't run around screwing with existing methods. And don't use libraries that do. The -w commandline flag to enable warnings is very helpful there, since at least in Ruby 1.9.2 it prints a warning if methods get redefined.
In Ruby 2.0, there will probably be some kind of mechanism to isolate method (re-)definitions into some kind of namespace. I wouldn't hold my breath, though: these so-called selector namespaces have been talked about in the Ruby community for almost 10 years now, and in the Smalltalk community even longer than that, and AFAIK nobody has ever produced a working implementation or even a working design for Ruby. A newer idea is the idea of Classboxes.
As far as I can tell, you're talking about monkeypatching (also known as duck punching in the ruby community).
This article has another example of monkeypatching (and other practices) gone bad.
In practice, no, though you could probably construct a situation like that if you really tried. Here's an interesting article (though old) that explains how this could happen.
If two gems "overrode the << method on array" they would need to be subclassing Array, and those classes would have different names or be in different modules.