Since Xcode 6 still has a lots of bugs with Swift, I'm not sure is it one or I'm missing something.
My class adopts protocol NSLayoutManagerDelegate. But it seems impossible to override method I need. I do as documentation describes:
override func layoutManager(_ aLayoutManager: NSLayoutManager!,
didCompleteLayoutForTextContainer aTextContainer: NSTextContainer!,
atEnd flag: Bool) {
}
But I get error here: method does not override any method from its superclass.
What should I do?
You're implementing a method from the protocol, yes, but it's not an override. Just remove the override keyword. An override is when your superclass also implements that method and you're providing a version that replaces or modifies the behavior of the superclass implementation. That's not what's happening here.
Related
Is there any way I can make sure I can take advantage of override keyword without writing override after each method.
I have couple of points to desire such a thing
Its error prone to mark each method override when you are dealing with legacy code and introducing the override keyword in the existing class
You have too many override methods
Override methods maybe scattered around in class declaration mangled with bunch of other methods
I am looking for something like override block using scope, when any method is part of this block its same as writing override after the method signature.
I am pretty sure there is no such thing as override block in standard but can we implemnt something using macro or other stuff?
e.g.
class derived
{
public:
override {
int blah();
void blahBlah();
.. so on
};
};
Is there any way I can make sure I can take advantage of override keyword without writing override after each method.
I'm afraid not. There's nothing in the Standard regarding override blocks or anything similar.
If you feel like this should be added to the language, write a proposal.
I have a base class with two init methods - one is designated with a list of parameters, the other is a convenience init that obtains the parameter values from an NSDictionary (which is used to serialise objects). All is well until I attempt to create a subclass - the convenience init produces an error if I attempt to call the matching super.init(...) and demands that I call a designated init of the subclass. The superclass contains the keys used to extract the parameter values and I don't want to duplicate the code or have public key values.
I could set up dummy values and use a separate loadFromDict() method (which can then be overridden) but this seems awkward. Is there another way?
The error you are seeing is normal, as if follows the rules for initialization in Swift. A convenience init must always call another init in the same class. The other init could be another convenience, or it could be a designated. At some point though a designated init needs to be called in the subclass before it calls up to the super class. Swift enforces that only a designated init can call up to super class init. This is from the Swift Language reference
To simplify the relationships between designated and convenience
initializers, Swift applies the following three rules for delegation
calls between initializers:
Rule 1
A designated initializer must call a designated initializer from its immediate superclass.
Rule 2
A convenience initializer must call another initializer from the same class.
Rule 3
A convenience initializer must ultimately call a designated initializer.
A simple way to remember this is:
Designated initializers must always delegate up.
Convenience initializers must always delegate across.
This portion of the apple docs may also be helpful:
Assuming that you provide default values for any new properties you introduce in a subclass, the following two rules apply:
Rule 1
If your subclass doesn’t define any designated initializers, it automatically inherits all of its superclass designated initializers.
Rule 2
If your subclass provides an implementation of all of its superclass designated initializers—either by inheriting them as per rule 1, or by providing a custom implementation as part of its definition—then it automatically inherits all of the superclass convenience initializers.
These rules apply even if your subclass adds further convenience initializers.
NOTE
A subclass can implement a superclass designated initializer as a subclass convenience initializer as part of satisfying rule 2.
This means that if your subclass overrides all of the superclasses designated initializers, then your subclass will inherit the convenience initializer that you want to avoid coding twice. In other words, you don't try to re-write the convenience initializer in the subclass at all. You just inherit it and use it as is.
Here is how it might look:
Superclass: DesignatedInit ConvenienceInit
| /
(override) / // ConvenienceInit
| / // will call overridden
| / // designated initializer
Subclass: DesignatedInit // in subclass.
In the end I've made the superclass convenience init into a designated one and duplicated the code from the other designated init, that seems to be the only way to call it from a subclass. Adding a 'setup' method that could be called later meant introducing optionals which confused the code.
To clarify my question, I wanted to subclass the convenience init so I could call super.init(...) as well as doing some subclass-specific stuff. This is now trivial with making it a designated init but it means that the two designated inits cannot share processing code, which is inconvenient.
I appreciate that the Swift init design is meant to protect coders from introducing bugs but it does feel a little too inflexible at times.
BTW I appreciate the helpful intention but posting chunks of documentation isn't ideal - just a link is fine.
I have a signal produced from a module. I want to define a signal listener class in another module but whenever I want to subclass it from CIListener, it says it cannot make a new instance from my subclassed listener because the CIListener class is a pure virtual class (interface class). But I have re-declared or redefined all the pure virtual methods in my listener class. Instead when I user CListener class to subclass my listener it works! Do I have to subclass from CIListener?
I guess you believe that you have re-defined all pure methods, but in fact the compiler thinks otherwise. There are 7 pure virtual methods that should be implemented with the proper signatures. If you want to support only certain data types (as it is in most cases) I would suggest to implement (extend) the cListener as it is just a NOP implementation of the cIListener interface (with all its methods throwing a datatype not supported error). Be sure to see whether you indeed override the necessary methods. You may use the override C++ keyword in your method definition.
I got answer about Foundation magic for this question: What's the most *simple* way to implement a plain data object which conforms key-value-observing?
What's the magic? How it work internally? Because it's dangerous using framework which I can't understand its internal behavior, I want to know its behavior. Currently, I cannot understand how it work without any method definitions.
Apple's documentation describes how KVO is implemented internally.
The gist of it is that when you register an observer on an object, the framework dynamically creates a subclass of the object's original class, and adjusts the object to appear as an instance of this new dynamic class. You can see this if you inspect an object in the debugger after it has had an observer registered.
This new class intercepts messages to the object and inspects them for those matching certain patterns (such as the getters, setters, and collection access).
In a nutshell: Objective-C 2.0's #property declaration creates accessor methods for the named property, so there are method definitions. #property is just a shorthand way to define them which avoids a lot of repetitious boilerplate code.
When you observe a property, a private subclass is created which implements accessors that call the appropriate notification methods before and after changing the property value. A technique known as "isa swizzling" is then used to change the class of the observed object.
I'm writing a Cocoa API for a project and the API takes a delegate. The protocol that I came up with declares all the methods as optional, but why would I do that instead of just documenting the delegate methods in a header file and taking a plain id as a parameter?
For the benefit of your users. If the object takes delegates conforming to some protocol and they pass something else in, the compiler can tell them. That isn't possible if you take an id and use a category as the delegate method interface.
Because having "all of these methods" optional isn't quite the same as permitting "anything you care to send".
It also produces code that is more usable in the IDE. For example if I'm looking at
#interface MyController : NSObject <FooBarDelegate> {
}
#end
I can command+double click in Xcode to jump to the definition of FooBarDelegate. With a category there's no formal declaration of intent to be a delegate.
Also, #required can be a problem for future plans with regard to backward binary compatibility and a new preferred method signature.