> On Feb 13, 2021, at 12:38 PM, Sven Barth <pascaldra...@googlemail.com> wrote:
>
> Right now, Ryan, your suggestion looks like a solution in search of a
> problem, or a "hey, look at that feature in language X, I so must have that
> in Pascal as well". Those concepts more likely then not tend to end in
> problems or should be rejected. So let's first define what we're trying to
> solve here:
What I'm trying to solve is the dilemma of OOP where we want to extend a class
but the addition does not fit cleanly into an existing hierarchy. I know we've
all had this problem and we were forced to settle on injecting some base class
into a hierarchy even though other classes higher up don't need this
functionality. Things like class helpers and interface delegation have already
been added into the language so clearly there is a need not being addressed.
We've all had this problem haven't we?
First off lets go summarize the differences/limitations of interface delegation
(as it is now) when compared to good, old fashion normal inheritance and OOP:
1) Does not support fields, class operators, properties
2) Only supports classes so we're required to manage memory (more fragmented
also which could be bad)
3) Requires you to define an interface with duplicate methods, so boilerplate
code
4) Does not combine namespaces so you must cast the class as the interface or
use the reference directly using dot notation (with performance implications?)
inheritance is so much easier and powerful. Just add the class name () and
you're good to go. That's my starting point, what ever solution should be close
to as easy as what already exists in OOP.
> === code begin ===
>
> type
> ITest = interface
> procedure Test;
> end;
>
> TTestImpl = record
> procedure Test;
> end;
>
> TTest = class(TObject, ITest)
> private
> fTest: TTestImpl;
> public
> property Test: TTestImpl read fTest implements ITest; default;
> end;
>
> var
> t: TTest;
> begin
> t := TTest.Create;
> try
> t.Test; // calls t.fTest.Test
> finally
> t.Free;
> end;
> end.
>
> === code end ===
>
> As the compiler needs to generate corresponding thunks anyway whether it
> needs to do this for a record or object is not really much more effort either.
>
> Whether the class needs to declare the interface in its interface clause can
> be argued about.
>
> But all in all one can see that with a few extensions of existing features
> one can easily provide a mixin-like, convenient functionality.
Great, this is getting closer to inheritance. It requires a default property
(which is basically what traits were anyways) and a lifting of restrictions on
the object being implemented. What we solved here is:
1) Default properties merge the namespaces, which is the perhaps the most
important part of OOP, that is the class is "one thing". If there is one thing
to accomplish it's this. Imagine how annoying OOP would be if you you have to
do "sphere.circle.shape.Draw()" because we had TSphere which inherited from
TCircle and in turn inherited from TShape.
2) If we can lift the restriction of classes-only by using records/objects then
we don't need to write boilerplate to alloc/free classes and our fields are now
contagious in memory. Again that would be so annoying if classes made us
allocate and free the super class we were inheriting from.
What it leaves desired:
1) Making a dummy interface is annoying boiler plate but not a deal breaker.
2) No fields or properties although you have some solution below which will
probably require some additional boiler plate. Class operators would are kind
of sad to lose too but not a deal breaker.
I stand by that using some concept of traits/mixins does all the stuff we want
with less boiler plate but I'm happy to explore any other ideas.
>
> Of course this does not provide any mechanism to directly add fields, however
> the compiler could in theory optimize access through property getters/setters
> if they're accessed through the surrounding class instance instead of the
> interface.
How does this look?
>
> Also this does not address the point of whether these delegates are able to
> access functionality of the surrounding class. In my opinion however this can
> be explicitely modelled by providing the class instance through a constructor
> or property or whatever.
Indeed but this can be solved by more boiler plate. :) In AfterConstruction you
can set references as desired. I had other ideas on this as they related to
traits but that wouldn't make sense if we were using an existing type like
records or classes.
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
