Okay, so the whole Observer Pattern discussion this morning went way off track after I mentioned this idea, but a few people expressed interest in my proposal:

I'd rather see a mechanism for injecting first class extensions to existing classes. That way, it really doesn't matter what pattern is implemented where.

So, what are these "class extensions"? Some mentioned Class Helpers, ala, Delphi. This is not what I envisioned. My idea was more me "riffing" on the notions I've encountered in DotNet and Objective-C.

In DotNet, well, C# specifically, we have the concept of "partial classes". That is to say, a class that is implemented in more than one section. In the world of DotNet, the partial classes are assembled at compile time in to a single concrete "class". The mechanism is a little clunky, and the rules prohibit some things from happening, e.g. not being able to add partial classes cross logical code block (in DotNet parlance, assembly.) What a partial class does allow the programmer to do is modularise their class structure. It is therefore possible to add/remove functionality from a class by including or excluding source files at compile time. I see this as an extremely basic version of my next item: The Objective-C Category.

In Objective-C, the Category often seems a lot like the Partial class in a superficial way. It is the same kind of idea - a breaking up of a class in to sections. Sections can be added and removed in a similar way. However the category goes further (as Objective-C always seems to) and allows functionality to be plumbed in to an existing class, without the need to alter the original source code - indeed you actually do not need the is what I envisioned when I stated the above "class extension". It could also be seen as a mechanism to overcome the issues often encountered with an OO system lacking multiple inheritance. One of the more interesting features of Categories in Objective-C is the ability to replace methods in the base class, but using the same signature.

http://en.wikipedia.org/wiki/Objective-C#Categories

So, yes, this is all pie in the sky. I'm in no way making any offer or commitment making this happen. I'm also fully expecting some criticism and probably to be told it is unlikely to be implemented (or at least, only in the Objective-P dialect), but I though that I would try to spin something positive from what was discussed earlier.

To recap - this has little to do with the crippled Class Helper functionality that Borland grafted on to Delphi DotNet and then Delphi in general. This is all to do with enabling something useful and helpful.

M

Having implemented support for Objective-C/Pascal categories in the compiler, I don't think that this concept can be translated to the (Delphi-compatible) Object Pascal model/implementation. It only works in Objective-C/Pascal because there all dispatching is based on the name of the method/selector (instead of based on VMT offsets or static binding).

It may be doable with a separate class hierarchy (like TInterfacedObject for COM) and compiler/RTL magic (that would probably duplicate large parts of the Objective-C run time's functionality to get everything running at a reasonable speed), but in that case it might be more worthwhile to add support for GNUStep and extend the Objective-Pascal support to all platforms (since it wouldn't work with the regular Object Pascal classes in the RTL anyway). Objective-Pascal and Object Pascal can be mixed in the same file, so you can use delegation and other ways to bridge the two kinds of classes.

Jonas

I figured it would be pretty difficult to implement. It's definitely a nice feature though. Maybe as it matures, it might be possible to migrate and refactor?

I wonder how easy it would be to do something with the Cocotron runtime? It is geared to being compiled on Mac, but uses a MINGW based cross compiler to target Windows and also compiles to target LINUX and BSD. The compiled library binaries should be movable to also uses a more Cocoa like runtime mechanism than the GNUStep one. I don't remember all the technicalities, but there is a difference that was fairly important. That's probably a little vague, but I have a head cold and feel a bit groggy today ;-)

Food for thought.

M

Speaking of .NET and partial classes, there are also extension methods in newer versions if C# that allow a similar level of bolting methods on to and is likely even simpler to handle than open classes and categories; it amounts to writing a function with a special naming so the compiler knows it's an extension and that's only available to modules who can see the extension method.

It's effectively syntactic sugar in some ways, though I think an extension method might be allowed to access private variables of the class being extended but I'm not fully confident about that. In the basic form, it's equivalent to having a FooStuff(x) but you can call it like it was always there as long as you know if the extension; x.Stuff() for instance. If Stuff is in both, issue a warning or error and pick the one from the class before an extension method.

I find them useful in C# as the syntactic sugar helps keep things readable (I can say x.ToUTF8 instead of ThingToUTF8(x) which in my mind routes quite a bit of the point of object relative syntax.)

Sent from my iPod