[fpc-devel] Class extension
joshua.cearley at gmail.com
Fri May 28 20:08:02 CEST 2010
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
On May 20, 2010, at 7:29 AM, Matt Emson <memson.lists at googlemail.com>
> 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 source at all. This 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.
> 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.
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel