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
wrote:
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
