As far as I understand when you use properties the compiler still converts them to accessor methods during compilation. I got a little irritated when I read you need OSX 10.5 or later to use properties. Why is that so?
If in the compiled application are in fact still accessor methods I see no need for OSX 10.5. Or is there something else going on during run-time?
Because the Objective-C 2.0 runtime was not back ported to 10.4. You need compiler and runtime support to handle all of ObjC 2.0 properly.
Related
trying to use the initwithcoder init method in my custom NSControl Class.
It works just fine and does what I need it to do. However and this leads me to asking this question on this here forum -> in the class reference of NCControl when you scroll down to initWithCoder and click on it it states SDKs
macOS 10.10+ which leads me to believe that it would not work and do what I need it to do on versions prior to that... Unless Apple's documentation once again is wrong...
BTW - from Apple's own reference (Online as well as offline) apparently the NSCoder Class is also suffering from this SDKs macOS 10.10+
https://developer.apple.com/reference/foundation/nscoder
The strange thing is that in the documentation describing how a NIB is loaded and which init methods it calls on various objects, it describes initWithCoder as being the designated initializer but that documentation is from before 10.10.
Thanks to anyone who can set my mind at ease ;-)
Yes it will not work before defined version. I think you are checking versions of Swift, if you select objective-c you should see version 10.0+ which i think should work fine for your need. If you change the language, you can put your mind to ease :)
I am assuming if you would like to support things that far back you are going to use objective-c over swift.
Check the below image for NSCoder documentation after you select objective-c on right hand side.
I am new to IOS developing, and want to use the Swift language instead of Objective-C.
I know few concepts about Cocoa touch, and I want to know : Can Swift do everything that Objective-C can do ?
There are a lot of things that can be done in Objective-C but cannot be done in Swift, without implementing it in Objective-C and then using it from Swift. Some of them include:
Catching Objective-C exceptions
Using C++ APIs (through Objective-C++)
Using NSInvocation, performSelector: and other ways of making calls dynamically where the method to call is chosen at runtime
Handling unimplemented method calls using forwardInvocation:
Provide a function for use in C APIs that take a function pointer
The only concept I know that is in Objective-C but not in Swift, is Key-Value Observing (KVO). You can use KVO for a Swift class to observe the property of an Objective-C class, but you cannot observe any arbitrary property of a Swift class. See this answer for more details.
This is an interesting question but essentially the answer must be NO because you can use Objective-C resources in swift using bridging-headers. Xcode automatically translates Swift to Objective-C and vice versa. However, if you cannot write Objective-C code then you cannot include your own custom objective-c classes in your swift projects!
It all depends on how you like to code. Apple have said that Objective-C is still a 'first class' language meaning that they are going to run Swift and Objective-C side by side for the foreseeable future. Personally I prefer Objective-C because you can use C very easily (as anything that is legal in C is also legal in Objective-C) added to which Swift is a more procedural in style where Objective-C is quite clearly object orientated.
It is worth noting that the Cocoa and Cocoa Touch classes are all objective-c classes and so it may be useful to have a working knowledge of Objective-C. I think the best advice I've heard so far is, if you have the time, learn both!
In xcode, it's possible given some Objective-C code, to see the code it would output in Assembly.
Is it possible to see given ARC enabled code, to see the Objective-C that would be outputted by ARC?
It is not possible, because ARC does not produce Objective-C code. ARC is a compiler feature that modifies the assembly produced in the same way that enabling optimizations might do. You can't tell the compiler to show you "optimized" C code; the optimizations are not applied at the level of C code. Likewise, you cannot ask to see the "ARC-ified" Objective-C, because the ARC memory management calls are not applied at the level of Objective-C code.
If you really want to see where the memory management calls are being made, you'll have to look at the assembly.
ARC doesn't as such output Objective-C, it a phase of the compiler which alters the assembler/machine code the compiler produces - and as you noted you can see that in Xcode. However if you use a decompiler on the binary you should see a "MRC equivalent", which is as good as you'll get. Try Hopper - demo available, I've not used it myself, don't know the producers, etc. However it produces psuedo-code, which looks like structured assembly, not Objective-C. HTH.
I have made my own Objective-C base class to use in Objective-C projects (without Foundation/Cocoa classes or API). While I don't mind writing my own retains and releases, it's a tedious process so I'm wondering if I can use ARC with my custom classes.
Specifically:
Is it possible to use ARC with custom classes?
Do my reference-counting selectors have to be called retain and release (and autorelease)?
What additional requirements are there to make ARC work as expected for custom classes (other than including the -fobjc-arc argument when compiling)?
Is it possible to use ARC with custom classes?
Of course it is.
Do my reference-counting selectors have to be called retain and release (and autorelease)?
Yes, they do. Apple has hardcoded the method names of its favorite Objective-C library (Foundation) into the compiler. Damn bad programming pattern, isn't it?
What additional requirements are there to make ARC work as expected for custom classes (other than including the -fobjc-arc argument when compiling)?
As far as I know, nothing.
I'm trying to use Objective-C 2.0 feature Property in GNUstep(using Windows).
But i can't use #property sign and #synthesize.
Although All of my codes are correct,compiler can't compile my property code.
Compiler also can't understand "#" sign.
Can i use Property feature in GNUstep.
If it's can use,Please tell me how can i do that?
Thanks you for your time.
The GNUStep GCC compiler does not support #property (or any of the the other Objective-C 2.0 language changes). However, if you can use Clang, you have access to Objective-C 2.0 features at compilation. As long as you can find an Objective-C 2.0-compatible runtime, you're all set. See http://wiki.gnustep.org/index.php/ObjC2_FAQ#Which_Bits_of_Objective-C_2_Work.3F.
Now you can use Clang 3.3 + libobjc2 + GNUstep to compile all the current Objective-C 2.0 language features. (blocks/ARC/properties...)
But if you're on Windows, I think you may have some trouble to run Clang...
Quick answer is that out-of-the-box, you can't. Version 2.0 of the language specification is specific to Apple's implementation. See here for a summary.