|
|
|
|
Hi ,
I am sure that this was already discussed, but I can not find any
conclusion.
Is planned support for multiple class(objet, record) helpers in a way,
that all class helpers can be used in parallel not only one?
My use case is:
In unit A I have declared base class.
In unit B I have declared helper for class defined in unit A which adds
some extended functionality (new methods) to class A
In unit C I have declared helper for class defined in unit A which adds
some extended functionality (new methods) to class A
In program P1 once I need only functionality defined in A, B so I use A,B
In program P2 I need functionality defined in A,B,C so I want use A,B,C
but It does not work as only one class helper can be active.
If such feature will not be implemented, is there any other way how to
solve this problem (how to add functionalities to one class by adding
more units to final program)?
If such featurn can be implemented is there already feature request in
bug tracker?
Thanks
-Laco.
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
Dňa 23.4.2018 o 13:52 Maciej Izak
napísal(a):
Thank you.
Can you give small example for my use case ? I can not understand
from above mentioned examples.
So I need to have:
unit A;
type
TClassA = class
public
procedure Method1;
end;
unit B;
type
TClassAHelper1 = class helper for TClassA
public
procedure MethodB1;
procedure MethodB2;
end;
unit C;
type
TClassAHelper2 = class helper for TClassA
public
procedure MethodC1;
procedure MethodC2;
end;
and in program:
use A,B,C;
var instanceA: TClassA;
...
instanceA := TClassA.Create;
instanceA.Method1;
instanceA.MethodB1; // defined in unit B
instanceA.MethodC1; // defined in unit C
...
L.
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
Hi ,
I am sure that this was already discussed, but I can not find any
conclusion.
Is planned support for multiple class(objet, record) helpers in a way,
that all class helpers can be used in parallel not only one?
Yes, it is planned. Main problem currently (aside from time) is to define when a method hides the method of another helper, especially when inheritance (both for the helper and the extended type) is involved.
Regards, Sven _______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
In reply to this post by Free Pascal - General mailing list
On Mon, 23 Apr 2018 12:13:01 +0000
Sven Barth via fpc-pascal < [hidden email]> wrote:
> LacaK < [hidden email]> schrieb am Mo., 23. Apr. 2018, 13:34:
>
> > Hi ,
> >
> > I am sure that this was already discussed, but I can not find any
> > conclusion.
> >
> > Is planned support for multiple class(objet, record) helpers in a way,
> > that all class helpers can be used in parallel not only one?
> >
>
> Yes, it is planned. Main problem currently (aside from time) is to define
> when a method hides the method of another helper, especially when
> inheritance (both for the helper and the extended type) is involved.
How will this be activated?
A modeswitch?
Will it be default enabled in mode objfpc and disabled in mode delphi?
Mattias
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
In our previous episode, Maciej Izak said:
>
> full potential of class/record/type helpers is not used :), and by bad
> choice can be loses for ever. IMO The best direction for type helpers
> (which can solve all problems) is usage "with" for example:
>
> var
> x: TObjectA with THelper1, THelper2;
>
> AFAIK should be possible to create new sub kind of helpers : aspects with
> new syntax and functionalities. IIRC Sven did not want to use "with" just
> for "type helpers" because it is reserved for more amazing feature like
> "aspects", but when type helper has the same root as aspect (aspect as sub
> kind of helper) then "with" can be used for both : "type helpers" and "type
> aspects"
IMHO having to change every reference/declaration kind of the defeats the
purpose of helpers a bit.
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
On Mon, 23 Apr 2018, Marco van de Voort wrote:
> In our previous episode, Maciej Izak said:
>>
>> full potential of class/record/type helpers is not used :), and by bad
>> choice can be loses for ever. IMO The best direction for type helpers
>> (which can solve all problems) is usage "with" for example:
>>
>> var
>> x: TObjectA with THelper1, THelper2;
>>
>> AFAIK should be possible to create new sub kind of helpers : aspects with
>> new syntax and functionalities. IIRC Sven did not want to use "with" just
>> for "type helpers" because it is reserved for more amazing feature like
>> "aspects", but when type helper has the same root as aspect (aspect as sub
>> kind of helper) then "with" can be used for both : "type helpers" and "type
>> aspects"
>
> IMHO having to change every reference/declaration kind of the defeats the
> purpose of helpers a bit.
True if you don't want to use a local variable, but I think the idea has merit
in the sense that you can be very explicit about what type helpers you want
in case of doubt. If it is an optional syntax, I don't see why not.
Michael.
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
In reply to this post by Free Pascal - General mailing list
Is planned support for multiple class(objet, record)
helpers in a way,
that all class helpers can be used in parallel not only
one?
Yes, it is planned. Main problem currently
(aside from time) is to define when a method hides the method
of another helper, especially when inheritance (both for the
helper and the extended type) is involved.
Later in uses clause wins ... as for other cases where in different
units are used same names
But probably problem is deeper , what I am not aware of ;-)
-Laco.
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
In reply to this post by Free Pascal - General mailing list
> On Apr 23, 2018, at 7:13 PM, Sven Barth via fpc-pascal < [hidden email]> wrote:
>
> Yes, it is planned. Main problem currently (aside from time) is to define when a method hides the method of another helper, especially when inheritance (both for the helper and the extended type) is involved.
>
Probably the best feature of Objective-C (and now Swift) is categories/extensions which are basically class helpers but with no limits on scope like in FPC. I never had problems with naming conflicts and I use them very often to split up large classes and extend library classes. Maybe looking at how “extensions” are implemented in Swift is a good idea? ( https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Extensions.html)
Btw why in the world did Delphi limit the scope like they did? It’s such a sad shortcoming of a great feature that everyone loves who works in the aforementioned languages. In fact I barely ever use them in FPC because I know if I rely on them too much I could get trapped in a situation where I have a scope conflict and there’s nothing I can do!
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
> On Apr 23, 2018, at 8:22 PM, LacaK < [hidden email]> wrote:
>
> Later in uses clause wins ... as for other cases where in different units are used same names
> But probably problem is deeper , what I am not aware of ;-)
Swift just gives a compiler error if there is a redefinition of method in the current scope. Very simple and works just fine. Why not do what Swift/Objective-C does given this is a proven implementation? At least as a starting point if nothing else.
extension MyObject {
func foo() {
}
}
extension MyObject {
func foo() { // redefinition error
}
}
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
Is planned support for multiple class(objet, record)
helpers in a way,
that all class helpers can be used in parallel not only
one?
Yes, it is planned. Main problem currently
(aside from time) is to define when a method hides the method
of another helper, especially when inheritance (both for the
helper and the extended type) is involved.
Later in uses clause wins ... as for other cases where in different
units are used same names
But probably problem is deeper , what I am not aware of ;-)
-Laco.
As I said the problem arises when inheritance enters the field as the rules are a bit different there.
Regards, Sven _______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
> On Apr 24, 2018, at 12:57 AM, Sven Barth via fpc-pascal < [hidden email]> wrote:
>
> As I said the problem arises when inheritance enters the field as the rules are a bit different there.
>
Why should helper methods be allowed to redefine existing methods anyways? As I mentioned Swift/ObjC don’t even allow this and just use a simple compiler error when a redefinition occurs. If that’s what’s holding up the feature I would say just go with Swift/ObjC’s implementation which is already proven in the real world to work.
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
> On Apr 24, 2018, at 12:57 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> As I said the problem arises when inheritance enters the field as the rules are a bit different there.
>
Why should helper methods be allowed to redefine existing methods anyways? As I mentioned Swift/ObjC don’t even allow this and just use a simple compiler error when a redefinition occurs. If that’s what’s holding up the feature I would say just go with Swift/ObjC’s implementation which is already proven in the real world to work.
Because that is how helper currently work. Extending it with a new feature will not change that.
Regards, Sven _______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
> On Apr 24, 2018, at 12:48 PM, Sven Barth via fpc-pascal < [hidden email]> wrote:
>
> Because that is how helper currently work. Extending it with a new feature will not change that.
>
I made an example to see how this would look. What’s the problem with “last in wins” like seen below? Seems pretty straightforward to me.
type
TClassA = class
procedure DoThis; virtual;
end;
type
TClassB = class (TClassA)
procedure DoThis; override;
end;
type
TClassHelper_A1 = class helper for TClassA
procedure DoThis; // overloads TClassA.DoThis
end;
type
TClassHelper_A2 = class helper for TClassA
procedure DoThis; // overloads TClassHelper_A1.DoThis
end;
type
TClassHelper_B1 = class helper for TClassB
procedure DoThis; // overloads TClassB.DoThis
end;
var
classA: TClassA;
classB: TClassB;
begin
classA.DoThis; // calls TClassHelper_A2.DoThis
classB.DoThis; // calls TClassHelper_B1.DoThis
Regards,
Ryan Joseph
_______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
|
> On Apr 24, 2018, at 12:48 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Because that is how helper currently work. Extending it with a new feature will not change that.
>
I made an example to see how this would look. What’s the problem with “last in wins” like seen below? Seems pretty straightforward to me.
It already works that way (or at least it's supposed to, I haven't tested it right now).
Regards, Sven _______________________________________________
fpc-pascal maillist - [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
|
|
Locked
