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.
Related
In object-oriented languages like C++ you don't have to call the base constructor. I don't understand why I need to do it in a psuedo object-oriented language like javascript. My base constructor has virtual elements that need to be setup before I call it. Constructors worked fine in ES5, why ruin them with this restriction. This error is garbage, it should be removed.
In C++ the compiler creates code to call the base constructor for you before your derived class constructor is called. Your C++ derived class definition can specify which base constructor to call and what to pass it (if there is a choice).
That's how the C++ specification is written. See short explanation here.
Javascript ES6 classes do not work the exact same way. You have to insert a place in your code where the base constructor is called with super(...) and you can specify or compute the parameters to pass to the base constructor.
In both C++ and Javascript, you can't access your own instance methods or properties before the base constructor has been called.
FYI, Java is even more restrictive than Javascript. You must put a call to super() or this() as the first statement of your constructor. Javascript at least lets you put logic that doesn't use this before calling the constructor.
In your Javascript, you can't stop this error without rewriting your code to work a different way. It's not an error you can disable.
There are valid OOP reasons (whether you agree with them or not) to not allow references to an object until all base classes have been fully initialized. Or, you can go back to the pre-ES6 way of initializing objects where there are no controls on how you do things and you can do whatever you want.
If you show us your code and explain what you're trying to do, we can likely suggest a different design that solves your problem and does not have this issue.
As it commonly known, one cannot extend or redefine interface of the overridden method in the inherited ABAP class. Help:
The interface and the category of the method (a general or functional instance method or event handler) are not changed in a redefinition.
This covers both global and local classes redefinition.
What are the probable workarounds of this limitation if one wants to add or remove methods parameters or change their type? Optional parameters is a way, though not very comfy. Any other ways?
You cannot change the signature of an interface method in any way in its implementations. This is simply because there is no way to do this that would not produce hard-to-analyze syntax errors at run time. An interface is a contract - any class implementing it promises that it will implement all methods (and variables...) that are present in the interface.
Assume there is a method METH of interface IF1 taking a single parameter PAR1 of type TYPE1. If you now write a class that implements a method METH with a single parameter PAR1 of type TYPE2, then you have not written a class that implements IF1. A caller that passes a parameter of type TYPE1 to the method of your class will encounter a type conversion error (whether at runtime or at compile time depends somewhat on the genericity of the types).
Therefore, there is no way to change the signature of an interface method in its redefinition without producing such runtime errors - your class does not implement the interface. Implementing an interface means that the class will accept exactly the number, type and kind of parameters specified for the methods in the interface. There is literally no use case in which you could meaningfully want to change this while still claiming that your class implements the interface. Whatever you're trying to do, this isn't the solution.
You can create your own interface, extending the existing interface. Add same method with different parameters. Then create abstract class from your extended interface and fill methods with code for calling real method with setting values to optional parameters. After then create your class from abstract.
interface
|--> extented interface
|--> abstract class
|--> class
I understand what purpose protocols serve (to have a type conform to a set list of methods or/and properties), but I don't understand what the purpose is of a protocol with all optional methods. One example would be UITextFieldDelegate.
If all methods are optional in a protocol, why would you conform to the protocol instead of just writing the methods from scratch in your class? I don't see what the benefit or purpose of conforming to the protocol is in this case.
Are the optional methods there just as suggestions of functionality that could be implemented?
Historically, for delegates and data sources in Cocoa, informal protocols were used. Informal protocol was implemented trough a category for NSObject class:
#interface NSObject (NSTableViewDelegate)
- (int)numberOfRowsInTableView:(NSTableView *)tableView;
// ...
#end
Later, optional methods in protocols were introduced. This change leads to better documenting of class responsibilities. If you see in code, that class conforms to NSTableViewDelegate, you suspect that somewhere exists a table view, that managed by instance of this class.
Also, this change leads to stronger checks in compile time. If programmer accidentally assign wrong object to delegate or dataSource properties, compiler will warn.
But your assumption is also correct. Optional methods are also suggestions for possible functionality.
By default, all methods in a protocol are required. Each method has to be marks as optional if the nor required for everything to function correctly.
If all methods are optional in a protocol, why would you conform to the protocol instead of just writing the functions from scratch in your class?
Conforming to a protocol allow your class to tell another object the methods it has without the other object needing to know about your class. This is really useful when using Delegation as it allows the delegate to decide what information they wish to receive/provide to another class.
For example,the UIScrollViewDelegate protocol only defines optional methods. Lets say we have a class Foo that we want to know when things change with a UIScrollView.
If we decided to throw that protocol away and implement the functions from scratch, how would we tell UIScrollView which methods we implement and which methods to call when certain event occur? There is no good way it could find out. When UIScrollView was built, it didn't know about Foo so it can't know what methods it implements. Also, Foo has no way of knowing what methods can be called on it by the UIScrollView.
However, when UIScrollView was built, it did know about UIScrollViewDelegate. So if Foo conforms the the UIScrollViewDelegate protocol, there is now a common definition that both Foo and UIScrollView can follow. So Foo can implement any methods it cares about, like scrollViewDidScroll: and the UIScrollView just needs to check if the delegate implemented the methods in UIScrollViewDelegate.
The protocol establishes a contract for the interface between one object and another. The fact that the methods are optional simply says that you don't have to implement that particular method, but you can if your app calls for it.
Generally, if you're conforming to a protocol for which all of the methods are optional, though, you're doing that for a reason, namely that you plan on implementing one or more of those methods. Just because all of the protocol's methods are optional doesn't mean you will not implement any of them, but rather simply that you can elect which are relevant in your particular situation.
For example, consider the UITextFieldDelegate protocol. You'd generally conform to that because you want to specify, for example, whether certain characters should be allowed to be inserted into the text field or what to do when the return key is pressed. Sometimes you only want to implement the former. Sometimes you only want to implement the latter. Sometimes you do both. But just because you choose to implement one or the other doesn't mean you necessarily want to do other one (but you can if you want). Frankly, though, if you really didn't want to implement any of the methods, you probably wouldn't even bother to specify the delegate of the text field, nor bother to specify that you're conforming to the protocol.
Bottom line, the protocol that consists solely of optional methods basically says "if you need it, this is the documented interface for the methods you may elect to implement". The protocol still is very useful to establish the possible interfaces, but doesn't force you to implement those methods you do not need.
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 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.