Re: [fpc-pascal] Traits Proposal

Ok my summary thus far with this syntax (default interface delegation) is that composition is possible (which is very nice) but polymorphism is not really possible so it's not exactly an alternative to multiple inheritance. Besides the complications of implementing method resolution for

Re: [fpc-pascal] Traits Proposal

Ryan Joseph via fpc-pascal schrieb am Mo., 22. Feb. 2021, 10:07: > > > > On Feb 19, 2021, at 8:50 AM, Ryan Joseph wrote: > > > > I just realized another potential problem. If we use the "default" > keyword that means there could be multiple "defaults" unless we limit the > property to 1 per

Re: [fpc-pascal] Traits Proposal

> On Feb 19, 2021, at 8:50 AM, Ryan Joseph wrote: > > I just realized another potential problem. If we use the "default" keyword > that means there could be multiple "defaults" unless we limit the property to > 1 per class, which would kind of defeat the purpose of the feature (like the >

Re: [fpc-pascal] Traits Proposal

On Fri, 19 Feb 2021 15:37:03 -0700 Ryan Joseph via fpc-pascal wrote: > > On Feb 19, 2021, at 3:14 PM, Sven Barth via fpc-pascal > > wrote: > > > > TObject *is* always the root, but the first entry of the > > inheritance list of a class *must* be a class as well. > > I'm testing interface

Re: [fpc-pascal] Traits Proposal

> On Feb 19, 2021, at 3:14 PM, Sven Barth via fpc-pascal > wrote: > > TObject *is* always the root, but the first entry of the inheritance list of > a class *must* be a class as well. I'm testing interface delegation now in ObjFPC mode and I don't see that including TObject is required.

Re: [fpc-pascal] Traits Proposal

Am 19.02.2021 um 20:37 schrieb Ryan Joseph via fpc-pascal: On Feb 19, 2021, at 11:01 AM, Sven Barth via fpc-pascal wrote: Your example is not quite correct and it's also not really complete: if a class implements an interface there *must* be a parent class mentioned (at least TObject).

Re: [fpc-pascal] Traits Proposal

Op 2021-02-19 om 16:50 schr So the method resolution doesn't actually change the VMT table of the class, just the interface? See it like this: An interface is a fragment of VMT. All methods of the interface are there in order. If implemented right, it is like a pointer into the

Re: [fpc-pascal] Traits Proposal

> On Feb 19, 2021, at 11:01 AM, Sven Barth via fpc-pascal > wrote: > > Your example is not quite correct and it's also not really complete: if a > class implements an interface there *must* be a parent class mentioned (at > least TObject). Also your example should demonstrate that one can

Re: [fpc-pascal] Traits Proposal

Ryan Joseph via fpc-pascal schrieb am Fr., 19. Feb. 2021, 17:32: > Btw, here's point of reference for this other proposed syntax. > > https://github.com/genericptr/freepascal/wiki/Default-Implements-Property Your example is not quite correct and it's also not really complete: if a class

Re: [fpc-pascal] Traits Proposal

Btw, here's point of reference for this other proposed syntax. https://github.com/genericptr/freepascal/wiki/Default-Implements-Property Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Traits Proposal

> On Feb 18, 2021, at 11:30 PM, Sven Barth wrote: > > The only thing that will not work and which will continue not to work is that > m_circle.Draw will not be called if you access the TMyShape through a > TShape.Draw call. For that one needs to use an explicit declaration: > > === code

Re: [fpc-pascal] Traits Proposal

Am 18.02.2021 um 23:58 schrieb Ryan Joseph via fpc-pascal: On Feb 18, 2021, at 3:07 PM, Sven Barth wrote: So "class type method resolution" is what's missing? I never used the interface method resolution so I don't really understand this feature. What needs to happen as far as the

Re: [fpc-pascal] Traits Proposal

On 18/02/2021 23:47, Ryan Joseph via fpc-pascal wrote: On Feb 18, 2021, at 12:33 PM, Martin Frb via fpc-pascal wrote: TMyFoo = class(specialize TTrait) procedure Foo; end; Of course that can get out of hand, if you want to include many traits. I'm not really understand this at

Re: [fpc-pascal] Traits Proposal

> On Feb 18, 2021, at 3:07 PM, Sven Barth wrote: > >> So "class type method resolution" is what's missing? I never used the >> interface method resolution so I don't really understand this feature. What >> needs to happen as far as the compiler is concerned? > > The problem is this: if you

Re: [fpc-pascal] Traits Proposal

> On Feb 18, 2021, at 12:33 PM, Martin Frb via fpc-pascal > wrote: > > TMyFoo = class(specialize TTrait) > procedure Foo; > end; > > Of course that can get out of hand, if you want to include many traits. I'm not really understand this at all. You're still using subclassing, which

Re: [fpc-pascal] Traits Proposal

On 18/02/2021 22:42, Sven Barth wrote: You need to constrain T as a TObject, then it works. Ah that works. With 2 restrictions TBase can be any class, since a trait can be applied to any class. So the only known common base is TObject. (restriction 1) But "TBase: TObject" means that the

Re: [fpc-pascal] Traits Proposal

Am 17.02.2021 um 16:22 schrieb Ryan Joseph via fpc-pascal: On Feb 17, 2021, at 6:10 AM, Sven Barth wrote: Simply because no one has come around to implement it yet. The class type case is more complicated than the interface case. (Same would be true for record and objects) So, yes, we'll

Re: [fpc-pascal] Traits Proposal

Am 18.02.2021 um 20:33 schrieb Martin Frb via fpc-pascal: could be written as   generic TTrait = class(T)     procedure Bar;   end;   TMyFoo = class(specialize TTrait) procedure Foo;   end; Of course that can get out of hand, if you want to include many traits. You need to constrain T

Re: [fpc-pascal] Traits Proposal

On 18/02/2021 18:46, Ryan Joseph via fpc-pascal wrote: On Feb 18, 2021, at 10:40 AM, Benito van der Zander via fpc-pascal wrote: Traits are like reverse type helpers. With the type helper you first declare the class and then the extending helper. Indeed, but with the crucial distinction

Re: [fpc-pascal] Traits Proposal

> On Feb 18, 2021, at 10:40 AM, Benito van der Zander via fpc-pascal > wrote: > > Traits are like reverse type helpers. With the type helper you first declare > the class and then the extending helper. Indeed, but with the crucial distinction that helpers don't allow fields, only methods.

Re: [fpc-pascal] Traits Proposal

Hi, The problem is that, we like OOP inheritance but when we extend classes we are forced into a single hierarchy. there is another way to extend classes without inheritance: type helpers Traits are like reverse type helpers. With the type helper you first declare the class and then the

Re: [fpc-pascal] Traits Proposal

> On Feb 17, 2021, at 9:59 AM, Adriaan van Os via fpc-pascal > wrote: > > 1. multiple inheritance is nice to have, but it has the big issue that the > inheritance tree becomes an inheritance graph and that makes overrules > ambiguent. > 2. interfaces don't have this issue with multiple

Re: [fpc-pascal] Traits Proposal

To streamline the discussion, let me recapitulate: 1. multiple inheritance is nice to have, but it has the big issue that the inheritance tree becomes an inheritance graph and that makes overrules ambiguent. 2. interfaces don't have this issue with multiple inheritance, because they just

Re: [fpc-pascal] Traits Proposal

> On Feb 17, 2021, at 6:10 AM, Sven Barth wrote: > > Simply because no one has come around to implement it yet. The class type > case is more complicated than the interface case. (Same would be true for > record and objects) > So, yes, we'll need to implement this first which would finally

Re: [fpc-pascal] Traits Proposal

> On Feb 17, 2021, at 6:17 AM, Sven Barth wrote: > > No. With wrapper function he means the thunks that are responsible for > adjusting the instance pointer of the interface to the instance pointer of > the class before jumping to the method of the class. Oh, so this is some extra code

Re: [fpc-pascal] Traits Proposal

Op 2021-02-17 om 00:02 schreef Benito van der Zander via fpc-pascal: And there often is a lot of unintentional deep copying. This is also why a property returning a record is fairly useless except for extremely small records like TPoint (and even that is not optimal no But a managed

Re: [fpc-pascal] Traits Proposal

Ryan Joseph via fpc-pascal schrieb am Mi., 17. Feb. 2021, 02:21: > > > > On Feb 16, 2021, at 3:35 PM, Benito van der Zander via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > But it is not calling the method, it is calling the wrapper function > > what you say wrapper function do

Re: [fpc-pascal] Traits Proposal

Ryan Joseph via fpc-pascal schrieb am Mi., 17. Feb. 2021, 02:15: > > > > On Feb 16, 2021, at 2:43 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > FPC currently does not yet support class types not to mention records > and objects which is what I had mentioned

Re: [fpc-pascal] Traits Proposal

> On Feb 16, 2021, at 3:35 PM, Benito van der Zander via fpc-pascal > wrote: > > But it is not calling the method, it is calling the wrapper function what you say wrapper function do you mean the ref counting functions when you pass around the interface? I guess for ref counting you're

Re: [fpc-pascal] Traits Proposal

> On Feb 16, 2021, at 2:43 PM, Sven Barth via fpc-pascal > wrote: > > FPC currently does not yet support class types not to mention records and > objects which is what I had mentioned earlier already. Yes I see this on https://freepascal.org/docs-html/ref/refse47.html. Why isn't this

Re: [fpc-pascal] Traits Proposal

Hi, And there often is a lot of unintentional deep copying. This is also why a property returning a record is fairly useless except for extremely small records like TPoint (and even that is not optimal no But a managed record to replace an interface, would only contain a single

Re: [fpc-pascal] Traits Proposal

Benito van der Zander via fpc-pascal schrieb am Di., 16. Feb. 2021, 23:35: > Interfaces are not slow because they are are interfaces! When you call a > interface method it has the same costs as a virtual method call! And the > cost for reference counting that interfaces have right now would be

Re: [fpc-pascal] Traits Proposal

Hi, If you need to create 1000 class instances each frame then you have a flaw in your logic in my opinion. I have more like a million class instances For my XPath stuff, and every returned value is put in a variant-like class. Selecting all nodes on an GB large XML, could even create

Re: [fpc-pascal] Traits Proposal

Am 16.02.2021 um 19:53 schrieb Ryan Joseph via fpc-pascal: On Feb 16, 2021, at 11:44 AM, Sven Barth wrote: I wasn't saying anything that contradicts this, only that the original mechanism of the delegation will be available even with the default modifier and this mechanism will in fact be

Re: [fpc-pascal] Traits Proposal

Op 2021-02-16 om 21:33 schreef Ryan Joseph via fpc-pascal: On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal wrote: And there often is a lot of unintentional deep copying. This is also why a property returning a record is fairly useless except for extremely small records

Re: [fpc-pascal] Traits Proposal

> On Feb 16, 2021, at 1:27 PM, Marco van de Voort via fpc-pascal > wrote: > > And there often is a lot of unintentional deep copying. This is also why a > property returning a record is fairly useless except for extremely small > records like TPoint (and even that is not optimal no deep

Re: [fpc-pascal] Traits Proposal

Op 2021-02-16 om 19:21 schreef Ryan Joseph via fpc-pascal: Interfaces are extremely slow. Virtual method calls are also slow. I have been using interfaces for reference counting, and have been thinking to replace it all with managed records because they are so slow (unfortunately records can

Re: [fpc-pascal] Traits Proposal

On 2/16/2021 10:48 AM, Sven Barth via fpc-pascal wrote: Ryan Joseph via fpc-pascal > schrieb am Di., 16. Feb. 2021, 19:21: > > There we have: > > * slower creation of the class, because each implemented interface adds another VMT

Re: [fpc-pascal] Traits Proposal

> On Feb 16, 2021, at 11:48 AM, Sven Barth wrote: > > If you need to create 1000 class instances each frame then you have a flaw in > your logic in my opinion. > You can reuse classes and reset fields but getting a new piece of memory could be faster. These things do happen and adding on

Re: [fpc-pascal] Traits Proposal

> On Feb 16, 2021, at 11:44 AM, Sven Barth wrote: > > I wasn't saying anything that contradicts this, only that the original > mechanism of the delegation will be available even with the default modifier > and this mechanism will in fact be necessary to access them through RTTI. > Can you

Re: [fpc-pascal] Traits Proposal

Ryan Joseph via fpc-pascal schrieb am Di., 16. Feb. 2021, 19:21: > > > > There we have: > > > > * slower creation of the class, because each implemented interface adds > another VMT reference to the class which needs to be initialized. > > How bad is this? We need to make a test case we can

Re: [fpc-pascal] Traits Proposal

Ryan Joseph via fpc-pascal schrieb am Di., 16. Feb. 2021, 19:22: > > > > On Feb 15, 2021, at 11:41 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Again, the point of the interface would be to control which methods and > properties of the delegated type would

Re: [fpc-pascal] Traits Proposal

> On Feb 16, 2021, at 6:51 AM, Benito van der Zander via fpc-pascal > wrote: > > Interfaces are extremely slow. Virtual method calls are also slow. I have > been using interfaces for reference counting, and have been thinking to > replace it all with managed records because they are so slow

Re: [fpc-pascal] Traits Proposal

> On Feb 15, 2021, at 11:41 PM, Sven Barth via fpc-pascal > wrote: > > Again, the point of the interface would be to control which methods and > properties of the delegated type would be available. Also it would allow for > seamless integration with the RTTI as it's possible to query the

Re: [fpc-pascal] Traits Proposal

There are no significant performance implications of interfaces. They're essentially a virtual method call, something that one is doing all day long with Object Pascal classes. Interfaces are extremely slow. Virtual method calls are also slow. I have been using interfaces for reference

Re: [fpc-pascal] Traits Proposal

Am 14.02.2021 um 19:22 schrieb Ryan Joseph via fpc-pascal: On Feb 14, 2021, at 11:14 AM, Sven Barth via fpc-pascal wrote: It's a runtime conversion, but normally you don't do the conversion for every method call, but instead cache the interface (or work solely with the interface), thus

Re: [fpc-pascal] Traits Proposal

Am 15.02.2021 um 18:08 schrieb Ryan Joseph via fpc-pascal: On Feb 15, 2021, at 9:08 AM, Marcos Douglas B. Santos via fpc-pascal wrote: As I understand, this is not a method hiding, but just to tell the compiler which method to implement the interface—the interface could have method names

Re: [fpc-pascal] Traits Proposal

Am 15.02.2021 um 16:52 schrieb Ryan Joseph via fpc-pascal: On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal wrote: Same names should be rejected. Providing a new implementation can be controlled using the interface alias: === code begin === type TMyClass =

Re: [fpc-pascal] Traits Proposal

Op 2021-02-15 om 18:08 schreef Ryan Joseph via fpc-pascal: As I understand, this is not a method hiding, but just to tell the compiler which method to implement the interface—the interface could have method names which are very very common to use and this syntax allows us to "rename" those

Re: [fpc-pascal] Traits Proposal

> On Feb 15, 2021, at 9:08 AM, Marcos Douglas B. Santos via fpc-pascal > wrote: > > As I understand, this is not a method hiding, but just to tell the > compiler which method to implement the interface—the interface could > have method names which are very very common to use and this syntax >

Re: [fpc-pascal] Traits Proposal

On Mon, Feb 15, 2021 at 12:52 PM Ryan Joseph via fpc-pascal wrote: > > > On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal > > wrote: > > > > Same names should be rejected. Providing a new implementation can be > > controlled using the interface alias: > > > > === code begin === > > > >

Re: [fpc-pascal] Traits Proposal

> On Feb 14, 2021, at 11:43 PM, Sven Barth via fpc-pascal > wrote: > > Same names should be rejected. Providing a new implementation can be > controlled using the interface alias: > > === code begin === > > type > TMyClass = class(TInterfacedObject, IMyIntf) > private > fMyRecord:

Re: [fpc-pascal] Traits Proposal

Am 14.02.2021 um 19:03 schrieb Ryan Joseph via fpc-pascal: What it leaves desired: 1) Making a dummy interface is annoying boiler plate but not a deal breaker. Again, I see this is part of Pascal's declarativeness. Also this way you can make sure that only those methods/properties that you

Re: [fpc-pascal] Traits Proposal

Op 2021-02-14 om 17:16 schreef Michael Van Canneyt via fpc-pascal: except it doesn't require an interface. The thing we seem to want here is a default property which works on records/objects so maybe we can just focus on that? The interface has so much boiler plate and I don't really see

Re: [fpc-pascal] Traits Proposal

Op 2021-02-14 om 13:30 schreef Michael Van Canneyt via fpc-pascal: I think the "performance implications" is more referring to memory management. Interfaces means an extra object per interface, so more objects on the heap with all the extra memory management that implies. (not interfaces

Re: [fpc-pascal] Traits Proposal

> On Feb 14, 2021, at 11:14 AM, Sven Barth via fpc-pascal > wrote: > > It's a runtime conversion, but normally you don't do the conversion for every > method call, but instead cache the interface (or work solely with the > interface), thus the performance impact through the conversion

Re: [fpc-pascal] Traits Proposal

Am 14.02.2021 um 19:07 schrieb Ryan Joseph via fpc-pascal: On Feb 14, 2021, at 9:55 AM, Sven Barth via fpc-pascal wrote: No, interfaces by *themselves* don't mean that. An interface instance is merely a shifted Self pointer that points to the static VMT of which the entries correct the

Re: [fpc-pascal] Traits Proposal

> On Feb 14, 2021, at 9:55 AM, Sven Barth via fpc-pascal > wrote: > > No, interfaces by *themselves* don't mean that. An interface instance is > merely a shifted Self pointer that points to the static VMT of which the > entries correct the Self pointer again upon the method call. This can

Re: [fpc-pascal] Traits Proposal

> On Feb 14, 2021, at 10:20 AM, Sven Barth via fpc-pascal > wrote: > > To be fair, that *is* how inheritance works for example if you try to use OOP > in C... (though it would be more like "sphere.parent.parent.Draw()") and that was bad. :) in PHP you're forced to use this-> instead of

Re: [fpc-pascal] Traits Proposal

On 14/02/2021 18:20, Sven Barth via fpc-pascal wrote:    TTest = class(TObject, ITest)    private fTest: TTestImpl;    public property Test: TTestImpl read fTest implements ITest; default;    end; Well there is a difference there. Interfaces are essentially inheritance. One can

Re: [fpc-pascal] Traits Proposal

Am 14.02.2021 um 02:45 schrieb Ryan Joseph via fpc-pascal: On Feb 13, 2021, at 12:38 PM, Sven Barth 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

Re: [fpc-pascal] Traits Proposal

On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote: Am 14.02.2021 um 13:30 schrieb Michael Van Canneyt via fpc-pascal: On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote: So whether it be this, or just an improvement on the Interfaces we already have, I'd definitely personally be in

Re: [fpc-pascal] Traits Proposal

Am 14.02.2021 um 13:30 schrieb Michael Van Canneyt via fpc-pascal: On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote: So whether it be this, or just an improvement on the Interfaces we already have, I'd definitely personally be in favor of something that "works like Interfaces except

Re: [fpc-pascal] Traits Proposal

> On Feb 14, 2021, at 9:16 AM, Michael Van Canneyt via fpc-pascal > wrote: > > I didn't propose using an interface; For me the > > property Test: TTestImpl read fTest implements TTestIimpl; > > Where TTestImpl is an object (tp style) or advanced record (delphi style) is > ample. That was

Re: [fpc-pascal] Traits Proposal

On Sun, 14 Feb 2021, Ryan Joseph via fpc-pascal wrote: On Feb 14, 2021, at 5:30 AM, Michael Van Canneyt via fpc-pascal wrote: Interfaces means an extra object per interface, so more objects on the heap with all the extra memory management that implies. You mean COM interfaces? I've

Re: [fpc-pascal] Traits Proposal

> On Feb 14, 2021, at 5:30 AM, Michael Van Canneyt via fpc-pascal > wrote: > > Interfaces means an extra object per interface, so more objects on the heap > with all the extra memory management that implies. You mean COM interfaces? I've only ever used CORBA style ones which I thought were

Re: [fpc-pascal] Traits Proposal

On Sun, 14 Feb 2021, Sven Barth via fpc-pascal wrote: So whether it be this, or just an improvement on the Interfaces we already have, I'd definitely personally be in favor of something that "works like Interfaces except minus the negative performance implications." There are no

Re: [fpc-pascal] Traits Proposal

Am 14.02.2021 um 01:09 schrieb Ben Grasset via fpc-pascal: This seems possibly a *little* too similar to the existing Interface type in Object Pascal, however, I *would* really like to see some kind of functionality that basically amounts to "has the same capabilities as Interfaces and works

Re: [fpc-pascal] Traits Proposal

> On Feb 13, 2021, at 5:09 PM, Ben Grasset via fpc-pascal > wrote: > > This seems possibly a *little* too similar to the existing Interface type in > Object Pascal, however, I *would* really like to see some kind of > functionality that basically amounts to "has the same capabilities as >

Re: [fpc-pascal] Traits Proposal

> On Feb 13, 2021, at 12:38 PM, Sven Barth 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

Re: [fpc-pascal] Traits Proposal

This seems possibly a *little* too similar to the existing Interface type in Object Pascal, however, I *would* really like to see some kind of functionality that basically amounts to "has the same capabilities as Interfaces and works on records and objects too, but does NOT require any kind of

Re: [fpc-pascal] Traits Proposal

W dniu 2021-02-13 o 20:38, Sven Barth via fpc-pascal pisze: 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

Re: [fpc-pascal] Traits Proposal

Am 10.02.2021 um 03:18 schrieb Ryan Joseph via fpc-pascal: We had talked about this some time ago and it's been rattling around in my brain so I wanted to write it down into a formal proposal where we can discuss it and hopefully agree upon a syntax. Everything is preliminary and tentative but

Re: [fpc-pascal] Traits Proposal

On 11/02/2021 04:13, Ryan Joseph via fpc-pascal wrote: On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal wrote: In that case IIRC, it was said traits are not allowed constructors. Why? Traits are meant to be a way to import fields/methods and is based off of "object" (so it's on the

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 9:05 PM, Martin Frb via fpc-pascal > wrote: > > Maybe Something like (aliasing / no need to copy implementation) > TDesignerList = trait(TEmployeList) > function FindDesigerByUnallocateWorkTime: TEmploye; aliases > FindByUnallocateWorkTime; // no body /just a name

Re: [fpc-pascal] Traits Proposal

On 11/02/2021 04:20, Ryan Joseph via fpc-pascal wrote: On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal wrote: I understand it is for conflict resolution only. But see my example => as soon as you need to repeat a trait with just a change in name, you always need conflict

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal > wrote: > > I understand it is for conflict resolution only. But see my example => as > soon as you need to repeat a trait with just a change in name, you always > need conflict resolution. Please post the code snippet again. I'm

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal > wrote: > > In that case IIRC, it was said traits are not allowed constructors. Why? Traits are meant to be a way to import fields/methods and is based off of "object" (so it's on the stack). This is also important for using

Re: [fpc-pascal] Traits Proposal

On 11/02/2021 03:07, Ryan Joseph via fpc-pascal wrote: We get the shared namespace So basically, we get the compiler to automatically create forwarder methods for us (or at least that behaviour). And that is all there is. right? In that case IIRC, it was said traits are not allowed

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 10:17 AM, Martin Frb via fpc-pascal > wrote: > > - One might have to think about how to declare what a trait can access? >Just allow anything in the code, and attempt to resolve when the trait is > embedded? IMHO maybe not? Sorry Martin you said a lot and I missed

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 2:42 PM, Ryan Joseph wrote: > > We should keep it as simple as possible imo. It's not as elegant as other ideas we may think of but I think it's good enough to let users write boilerplate methods to resolve naming conflicts. We don't need to introduce new syntax or

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 1:51 PM, Martin Frb via fpc-pascal > wrote: > > I don't have a pro/contra agenda on whether that feature should be part of > the fpc trait or not. > I just saw it, and thought I raise it. > These issues you are raising are more related to general type

Re: [fpc-pascal] Traits Proposal

On 10/02/2021 21:17, Ryan Joseph via fpc-pascal wrote: On Feb 10, 2021, at 12:40 PM, Martin Frb via fpc-pascal wrote: type TSomeTrait = trait public procedure DoTraitFoo; end; TSomeClass = class(TObject) private trait: TSomeTrait; // whatever syntax is used so that

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 12:40 PM, Martin Frb via fpc-pascal > wrote: > > type > TSomeTrait = trait > public > procedure DoTraitFoo; > end; > > TSomeClass = class(TObject) > private > trait: TSomeTrait; // whatever syntax is used so that the trait is added > public >

Re: [fpc-pascal] Traits Proposal

On 10/02/2021 20:17, Ryan Joseph via fpc-pascal wrote: On Feb 10, 2021, at 11:09 AM, Ryan Joseph wrote: type TSomeTrait = trait public parent: TObject; procedure DoThis; end; procedure TSomeTrait .DoThis; begin // ??? here is our issue. Is this good enough to call the

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 12:17 PM, Ryan Joseph wrote: > > Thinking about this more I don't think there's even a reason for it since > Object Pascal doesn't let you do stuff like this anyways. If you want to call > the super class you need to use "inherited" from within the class body. The >

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 11:09 AM, Ryan Joseph wrote: > > type > TSomeTrait = trait > public > parent: TObject; > procedure DoThis; > end; > > procedure TSomeTrait .DoThis; > begin >// ??? here is our issue. Is this good enough to call the > TBaseClass.DoThis? >

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 10:17 AM, Martin Frb via fpc-pascal > wrote: > > The example exposes another aspect: > >> trait SayWorld { >> public function sayHello() { >> parent::sayHello(); > > In this case the trait has access to the object/class into which it is > embedded.

Re: [fpc-pascal] Traits Proposal

On 10/02/2021 16:59, Ryan Joseph via fpc-pascal wrote: • PHP (trait): https://www.php.net/manual/en/language.oop5.traits.php The example exposes another aspect: |trait SayWorld { public function sayHello() { parent::sayHello();| |In this case the trait has access to the object/class

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 9:06 AM, Michael Van Canneyt > wrote: > > You said it yourself: internally it will just be an object. Just make it > formally so. > > I also think the argument of reusing existing objects deserves consideration. Is it strange that there are extra things in the object

Re: [fpc-pascal] Traits Proposal

On Wed, 10 Feb 2021, Ryan Joseph via fpc-pascal wrote: On Feb 10, 2021, at 8:41 AM, Michael Van Canneyt wrote: I heavily object to this; We have way too much keywords as it is already. So unless there really is no other way I don't think we should introduce even more. I guess the

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 8:41 AM, Michael Van Canneyt > wrote: > > I heavily object to this; We have way too much keywords as it is already. So > unless there really is no other way I don't think we should introduce > even more. I guess the first question is whether a "trait" is a new

Re: [fpc-pascal] Traits Proposal

On Wed, 10 Feb 2021, Ryan Joseph via fpc-pascal wrote: On Feb 10, 2021, at 12:32 AM, Michael Van Canneyt via fpc-pascal wrote: Instead of trait you might as well use simply "object", so basically we could simply state that instead of an interface, you can also specify an object in the

Re: [fpc-pascal] Traits Proposal

> On Feb 10, 2021, at 12:32 AM, Michael Van Canneyt via fpc-pascal > wrote: > > Instead of trait you might as well use simply "object", so basically we > could simply state that instead of an interface, you can also specify an > object > in the class definition: > > > TMyClass = class

Re: [fpc-pascal] Traits Proposal

Michael Van Canneyt via fpc-pascal wrote: On Tue, 9 Feb 2021, Ryan Joseph via fpc-pascal wrote: We had talked about this some time ago and it's been rattling around in my brain so I wanted to write it down into a formal proposal where we can discuss it and hopefully agree upon a syntax.

Re: [fpc-pascal] Traits Proposal

On Tue, 9 Feb 2021, Ryan Joseph via fpc-pascal wrote: We had talked about this some time ago and it's been rattling around in my brain so I wanted to write it down into a formal proposal where we can discuss it and hopefully agree upon a syntax. Everything is preliminary and tentative but