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 s
> 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 r
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
resolution.
> 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 not
> 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 propertie
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 construct
> 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
> 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 con
> 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
safety/compatibi
On 2/9/2021 7:26 AM, Luis Henrique via fpc-pascal wrote:
I guess one can call it optional formatting specifiers. See documentation:
https://www.freepascal.org/docs-html/rtl/system/str.html
I think I was lazy and didn't look in the right place, thanks Michael and
Christo.
This is standard
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
> 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
>
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 TBaseC
> 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
> ex
> 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?
>TBaseClass(pare
> 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. (otherwi
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 in
> 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 w
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 first
> 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 construct
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 cl
> 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 (TPar
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. Ever
23 matches
Mail list logo
