I'd like to thank Ryan & Sven for extending the helpers to be able to handle multiple helpers.

Now I can remove my (obtrusive) helper inheritance

    THelper2 = class helper(THelper1) for TMyObject

very good!

This feature deserves a bold announcement. Now we are only missing Lazarus IDE codetools support for it :)

Again - big thanks.

Ondrej

You’re welcome. I’m looking forward to fixing up some old code myself. :)

Regards,
Ryan Joseph

I want to argue that the way this is implemented is asking for easily introducing defects into existing code by extending/modifying helpers causing methods to creep into scope. If multiple helpers should be considered they should be treated equally and not by order treating equally named methods as overloads similar to how C# extension methods work.

I want to argue that the way this is implemented is asking for easily introducing defects into existing code by extending/modifying helpers causing methods to creep into scope.

How can a disabled-by-default modeswitch "defects into existing code"?

Mattias

When I wrote "existing code" I was referring to the future when people turn this on for their code and then helpers get changed and not "today existing code".

Stefan Glienke wrote

When I wrote "existing code" I was referring to the future when people turn this on for their code and then helpers get changed and not "today existing code".

The problem is the same with old style Delphi-like helpers. Multihelpers didn't change much in this regard.

Ondrej

+1
This is the same as having two functions, with the same signature, in two different units.
Your program will use the first that was found.

regards,
Marcos Douglas

In fact it will use the last one that was found and fwiw this is imo bad and error prone behavior - I guess everyone has had that happen at least once that with some version change or update of some code some clash happened - especially when a routine with the same name but different parameters was introduced somewhere.

I had the impression you are aiming for the best possible solution for a new feature so I brought this up - if you are happy with a "better than before" then please go for it.

Sorry I sent the first message to privately but I’m posting this to the list.

I see what you mean now (in the example below you can just add “overload” to fix it of course).

It sounds like you want something like "C# style function overloading” as a general feature of the language instead of the “overload” keyword and order of precedence rules that Pascal currently uses. The same problems you’re concerned about could happen with plain functions in different units so I don’t consider this a strictly helper related issue.

Personally I don’t like that approach because it means if an existing unit has a helper (or function) with the same signature the compiler will simply not allow you to overload it. Maybe you could argue for an additional function modifier that says “overload if not ambiguous” so you can be sure adding a new method doesn’t cover some existing method in the same scope.

{$mode objfpc}
{$modeswitch multihelpers}
program test;
type
  THelper1 = class helper for TObject
    procedure DoThis;
  end;
type
  THelper2 = class helper for TObject
    procedure DoThis(msg: string);
  end;
procedure THelper1.DoThis;
begin
  writeln('DoThis');
end;
procedure THelper2.DoThis(msg: string);
begin
  writeln('DoThis:', msg);
end;
var
  obj: TObject;
begin
  obj := TObject.Create;
  obj.DoThis;	// <======== ERROR: Wrong number of parameters specified for call to "DoThis"
end.

Regards,
Ryan Joseph

Stefan Glienke schrieb am Mo., 13. Mai 2019, 14:54:

It's in line with how helpers behave already:

Assume you have a class A with a method Foo that you call in your code.

You now add a unit with a helper for A that also has a method Foo. Then the helper's method will be called.

If you now add a second unit with a helper for A with a method Foo then the method of that helper is called.

This behavior is the same no matter if the new modeswitch is used or not. The only difference is if you add a second unit with a helper that does *not* contain a method Foo:

Without the modeswitch the Foo of the original class will be used.

With the modeswitch the Foo of the first helper will be used.

Yes, multiple helpers per type can bite you, but so can a single helper. Helper types are a feature that should be used with care and that best have some IDE support.

Regards,
Sven