I've been declaring private methods in class extensions, according to Best way to define private methods for a class in Objective-C.
But, I just realized that, in Xcode 4, if I leave out the declaration of a private method altogether and just implement it, the app compiles and runs without warning or error.
So, should I even bother declaring private methods in class extensions?
Why should we have to declare methods anyway? In Java, you don't... neither in Ruby.
A method definition only needs to be defined if the caller is declared before the method. For consistency I would recommend defining your private methods in the extension.
-(void)somemethod
{
}
-(void)callermethod
{
//No warning because somemethod was implemented already
[self somemethod];
}
-(void)callermethod2
{
//Warning here if somemethod2 is not defined in the header or some extension
[self somemethod2];
}
-(void)somemethod2
{
}
This answer has already been correctly answered by Joe for Xcode prior to v4.3. However, in v4.3 and above, not only do private methods not need to be declared, but declaration order is now irrelevant. For details, see:
Private Methods in Objective-C, in Xcode 4.3 I no longer need to declare them in my implementation file ?
This will compile and run fine without declaration:
- (void)foo {
}
- (void)bar {
[self foo];
}
But last I checked, this will give a warning:
- (void)bar {
[self foo];
}
- (void)foo {
}
In other words, it's just like in C: a declaration is not necessary if the definition comes before any use. C requires this to avoid having to add an extra pass to the compiler (one to find the functions and then one to actually parse them). As for whether you should declare them when not necessary, it's really up to the style of the codebase you're working with.
As for other languages that don't require declarations, some just go ahead with the extra pass, while others don't need to know the number and types of the arguments or the return type at compile time (they look up functions at runtime instead, or they don't have strongly-typed variables to begin with so it doesn't "matter") so they can just skip it.
Related
swift code is below:
func swizzleMethod()
{
let method:Method = class_getInstanceMethod(object_getClass(self), Selector("function1"))
self.function1()
let swizzledMethod:Method = class_getInstanceMethod(object_getClass(self), Selector("function2"))
method_exchangeImplementations(method, swizzledMethod)
self.function1()
}
func function1()
{
print("function1 log")
}
func function2()
{
print("function2 log")
}
it logs:
function1 log
function1 log
/////
my environment is swift based project, xcode7.2
This always run into the funtion1 method body, so I think it exchanged failed, this two method is in the same class, anyone know why?
I get the answer, add "dynamic" keyword in front of method name!!!
like this:
dynamic func function1()
{
print("function1 log")
}
dynamic func function2()
{
print("function2 log")
}
Reason:
Swift optimizes code to call direct memory addresses instead of looking up the method location at runtime as in Objective-C. so we need tell the code run treat it as Objective-C code.
Answer Detail:
Method swizzling is a technique that substitutes one method implementation for another. If you're not familiar with swizzling, check out this blog post. Swift optimizes code to call direct memory addresses instead of looking up the method location at runtime as in Objective-C. So by default swizzling doesn’t work in Swift classes unless we:
1. Disable this optimization with the dynamic keyword. This is the preferred choice, and the choice that makes the most sense if the codebase is entirely in Swift.
2. Extend NSObject. Never do this only for method swizzling (use dynamic instead). It’s useful to know that method swizzling will work in already existing classes that have NSObject as their base class, but we're better off selectively choosing methods with dynamic .
3. Use the #objc annotation on the method being swizzled. This is appropriate if the method we would like to swizzle also needs to be exposed to Objective-C code at the same time.
thanks to the article: 15 Tips to Become a Better Swift Developer
I've got a class deriving from a simple protocol. It looks like this:
protocol Interface {
func f() -> Void;
}
class TestInterface : Interface {
var arr: [Int] = [];
func f() {
// stuff
}
}
Unfortunately, I can't create this class as Swift has it has no initializers (although the default one would blatantly suffice).
However, the more serious problem is trying to define the initializer. Initially I tried to define an empty initializer. Swift told me that this was illegal because I did not call the super initializer (even though it's a protocol...). Fine, I thought. I called super.init(). Swift then told me this was illegal because the base is a protocol and not a class, so it has no init function. So I can't define an init function because I must call a nonexistent init function inside my own init function. And the normal init function is randomly unavailable for no good reason.
How the hell can I create an instance of my super simple class?
This is actually a totally unrelated issue. The protocol actually used to be a class. For an unrelated reason, the module that this class was imported from crashed the Swift compiler, and corrupted the metadata. So when Swift came to read the metadata for this class/protocol, it was inconsistent and confused the compiler.
As soon as I resolved the issue with the source module (and actually noticed it, thanks crappy XCode error reporting) this was no longer an issue for me.
Did Swift drop the underscore-prefix convention for instance variables, e.g., _window? If so, why?
Apple still uses _ in its Xcode boilerplate code as a convention for a non-public variable. You'll see a pattern like such:
class Foo {
var _bar : Bar? = nil
var bar : Bar {
if _bar == nil {
/* compute some stuff */
_bar = Bar (/* ... */)
}
return _bar!
}
}
where access to the property is meant to be through the bar computed property. You find this in Apple CoreData templates.
In Objective-C when you declare a property #synthesize would create the getter and setters for you automatically since clang 3.2. So, the default #synthesize for a property "foo" would look like this:
#synthesize foo = _foo
because of that _foo would then be the iVar. In other words you could have done the #synthesize yourself and called the iVar whatever you liked:
#synthesize foo = myiVarFoo
so in this case there is no "_"
So now in Swift from the documentation:
Swift unifies these concepts into a single property declaration. A Swift property does not have a corresponding instance variable, and the backing store for a property is not accessed directly.
So from the documentation it's clear that swift does not have a corresponding instance variable thus no need to have the "_" around anymore.
The underscore prefix was meant not to confuse the instance variable _foo with its getter foo.
In swift there's not such distinction between ivars and getters. Instead you only have properties, making the _ convention non necessary.
The answer is no because there are no "instance variables" right now in Swift. Only properties (stored properties and computed properties).
I'd say this _underscoreName convention is dropped (although some Apple templates still have it).
Swift's "Lazy Stored Properties" make _these unnecessary. This post:
http://mikebuss.com/2014/06/22/lazy-initialization-swift/
explains it well.
I use a leading underscore to denote a private symbol.
Yes, the underscores do hamper readability at first, but there is a valuable payoff in comprehension and maintainability.
e.g.:
final class SomeClass
{
fileprivate let _kMagicNumber: CGFloat = 3.14
fileprivate struct _PrivateInfo
{
let foo: Int
let bar: String
}
fileprivate var _privateInfo: _PrivateInfo
fileprivate func _setup(with info: _PrivateInfo) { ... }
}
etc.
At a glance, you can see which elements belong where.
You don't need to option-click or do the "who does this belong to?" dance.
Code comprehension shouldn't rely on an IDE's features. And there are times (GitHub, raw text files) where an IDE isn't available.
I understand the "it's not convention" argument. But conventions aren't written on stone tablets. Swift is rapidly evolving, as is our usage of it.
If the Swift team were to produce an annotation syntax for private symbols tomorrow, I'd use it. But until then...
Since I've got my soapbox out, please prefix your extensions.
Consider this snippet:
let color = "#ff7733".hexColor
Where does the "hexColor" come from? Your own code? The Swift standard library? Foundation? UKit? (Hah!) A CocoaPod? Who knows?
(Seasoned CocoaPods users will know that every second open-source library implements a "hexColor" property. With all the problems that entails.)
So, given a company or project name like "Double Secret Probation", consider using:
let color = "#ff7733".dsp_hexColor
Finally, I strongly recommend the books "Writing Solid Code" and "Code Complete".
The convention of a prefixing private vars long preceeded that of ObjCs (weird) property synthesis concept. Clarity was the original reason for such a prefix, not differentiation though it was useful and common to expose a public getter without the underscore...for obvious reasons. IMO, ObjC prop synthesis just put a big fat monkey wrench in the works confusing the h*** out of everyone...
What if you wanted a private synthesized property? In order to underscore-prefix your private synthesized property, you'd need a double underscore backing var. Apple specifically warned against double underscores and this created confusion. Should we bother to use synth'ed properties internally or stick with the backing var (which still had an underscore and was clearly private)? Should we just stop differentiating between private and public vars? Why??
In practice people would use the synthesized version internal to a class as a kind of smart setter, if and only if they wanted the smarts – but that broke down the ideal of encapsulation – choosing whether to use the synth'ed setter required apriori knowledge of what happened behind the scenes.
Meanwhile, as pointed out above, apple's internal code still used the convention, sometimes for synthesized properties too IIRC. And they still do for swift properties! But not consistently...The biggest evidence your language design policy is confusing is when your own devs aren't using it consistently!
Clarity was the original motive and it worked well. I say:
BRING BACK THE UNDERSCORE!
...for private vars and methods :)
(P.S. Dart even has this as an actual language convention in lieu of a private keyword!)
What is the best practice approach to private methods in objective-c. That is a method that's only going to be used the class as a helper method.
In particular what's not clear to me is:
Is there a need to have the method specified in the header file as private at all? i.e. why not just leave it out of the header file, and
If you can leave it out of the header file, then what is the point of having private methods?
Or is it the case in objective-c there is no such thing as real private methods, in which case is it better just to specify everything in the header file and no bother marking the private at all?
thanks
There is no need to specify the method in the public header file. You may want a "private" header file for use by other classes in your module, if the classes in your module are supposed to be "friends". You could even have a "protected" header file, as Apple does with UIGestureRecognizerSubclass.h for example. It's all just convention, though, nothing supported by the language itself.
A private method in Objective-C is just one that is not publicly documented; any method can still be called from anywhere, as long as the caller knows the name of it in order to create the appropriate selector. The advantage of not publicly documenting a method is that you are free to change or remove it without worrying about backwards compatibility. Leaving them out of the header file is one way of not publicly documenting them.
What you probably want to use is called "Class Extensions". They look similar, but shouldn't be confused with Categories. This will allow you to declare private methods in your .m file, and you'll get all the nice IDE corrections and suggestions.
Here's a decent article on it
And a related SO question
Best practice (and is even a compiler option to check) is that ALL methods be declared one way or the other. To 'hide' helper methods from prying eyes, declare it as such in the implementation .m file, as in:
#import Client;
#interface myClass (Private)
- (void) privateMethod;
- (float) bankAccountBalanceForClient:(Client *)client;
#end
#implementation myClass
- (void) privateMethod;
{
//foo here
}
and so on. the private methods are a Category called Private of myClass methods. This category can be declared anywhere, even in a master .h file called private methods, although that would be a maintenance nightmare.
So, using the public .h file for public methods, and the .m file to declare private methods, you have all your methods declared somewhere. I use this compiler option to ensure and force it, so that any method used is actually declared somewhere (or I get a syntax error) and thus I dont get any runtime crashes due to method not found.
Coming from a C++ background, one thing that confuses me about Objective C is the fact that you can add a method to a class without actually specifying it in the class interface. So I had a barrage of questions:
Why would someone choose to not add the method in the class interface?
Is it simply because of visibility?
Methods without a declaration in the interface are private?
Is declaring methods in a class interface just optional?
Is it different for overriding a base class' method?
The main difference is that C++ sets up much of its inheritance and types at compile time and Objective C does it mostly at runtime.
The only differences in putting a method in the interface (if all parameters are objects) in objective-C are that the compiler can see it at compile time and check that an object could respond to the method - if it does not then you get a warning but the compilation does succeed and the program will run and loo for the method at runtime. If the method is in the implementation of the class or a category (or some other way) then the run time will find it and call it successfully.
There are NO private methods you can call any method.
I believe that this is the only way to create private methods in Objective-C. The language does not support the ability to declare a private method so by not declaring a method in the header file you are making private from all callers.
Proper data encapsulation requires that you lock down access to members that either expose data or manipulates it. Not all members ought to be exposed.
Yes it is.
Yes, this is true.
Yes, this is true as well.
This I am not sure about - perhaps someone with more Objective-C knowledge could answer this one.
Extending Andrew Hare's answer to answer 5, no, it doesn't: whether declared in an #interface or otherwise, method replacement/refinement works the same.