Stefan Glienke schrieb am Mo., 13. Mai 2019, 14:54:
> 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
Sorry I sent the first message to privately but I’m posting this to the list.
> On May 13, 2019, at 9:44 AM, Stefan Glienke wrote:
>
> Now the author of THelper2 decides that it would be cool if to add a
> DoThis(msg: string); method.
> Now what happens to anyone calling DoThis from THelper1?
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
On Mon, May 13, 2019 at 7:09 AM Ondrej Pokorny wrote:
>
> On 13.05.2019 11:59, 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
On 13.05.2019 11:59, 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
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".
> On 13 May 2019 at 11:45 Mattias Gaertner mailto:nc-gaert...@netcologne.de > wrote:
>
>
> On Mon, 13 May 2019 11:33:36 +0200
On Mon, 13 May 2019 11:33:36 +0200 (CEST)
Stefan Glienke wrote:
> 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
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
> On May 12, 2019, at 4:03 AM, Ondrej Pokorny wrote:
>
> 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
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
10 matches
Mail list logo
