mulle_objc: inheriting methods from protocols
Continued from mulle-objc: object layout, retain counting, finalize
A protocol in mulle-objc "lives" only in the compiler. Whereas in the legacy runtimes, a protocol existed at runtime as it's own object, in mulle-objc it is just a hash value, whose presence can be queried on the class. At runtime you don't know, what methods are part of a protocol.
As before there is nothing that stops you from creating a class with the same name as a protocol. This is put to good use now.
Inheriting methods from protocols
A class decides at runtime, what to inherit with a ->instance bitfield, that is part of the
||for completeness sake, useless|
||be obnoxious and seal your class|
||inherit methods from protocol class, but not it's categories|
||inherit methods from categories of protocol class|
A class can set these bits during
+initialize. I am toying with the idea of making
MULLE_OBJC_CLASS_INHERIT_PROTOCOLS the default.
Alternative idea: A class has a method
+inheritsSelector:protocol:category:and this method is queries, whenever the method cache is filled.
A scheme to have protocols with ivars (sort of)
Create a struct that contains the instance variables, the protocol needs. Define a method in the protocol to get the address of this struct in the instance variable area of an instance.
Together with the extremely fast forwarding that mulle-objc offers through the meta-ABI, this makes multiple-inheritance-like schemes possible and performance wise acceptable.
I might get accused of "ripping off" Swift here, which apparently has something like this now. But when I designed this feature into the runtime some months ago, I didn't know about it.
Continue to mulle-objc: present and absent language features