On 13.09.2017 22:08, Sven Barth via fpc-devel wrote:
Anyway, I had looked at your patch last Friday, but after some thinking
I came to the conclusion that I definitely don't want the typehelpers
modeswitch to enable inheritance on record helpers in mode Delphi cause
that would be some unexpected
On 01.09.2017 18:38, Sven Barth via fpc-devel wrote:
What if I do the initial specialization in a unit that does not know
about the helper? It can't just do speculative specialization once
both the specialized generic and the generic helper are used in the
same unit. And even if the compiler
2017-09-01 18:30 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
> I'd prefer to keep that syntax for aspects or as alternative attribute
> syntax instead of wasting it for helpers that are defined to work based on
> the type
>
+1 :))) so we have nice topic to talk. I have
Am 01.09.2017 14:50 schrieb "Stefan Glienke" :
>
> > For generics the only way to support them is that you must explicitly
specialize a generic helper type. The compiler won't do any type inference
for you.
>
> IMO this makes them rather useless. Is that a technical limitation
Am 01.09.2017 14:41 schrieb "Maciej Izak" :
>
> 2017-09-01 14:30 GMT+02:00 Michael Van Canneyt :
>>>
>>>
>>> No, directives won't be abused for something like that.
>>
>>
>> I am glad I am not the only one who thins so :)
>
>
> I like experiments as you
> For generics the only way to support them is that you must explicitly
> specialize a generic helper type. The compiler won't do any type inference
> for you.
IMO this makes them rather useless. Is that a technical limitation or just
something you did not want to do?
I don't know much about
2017-09-01 14:30 GMT+02:00 Michael Van Canneyt :
>
>> No, directives won't be abused for something like that.
>>
>
> I am glad I am not the only one who thins so :)
I like experiments as you know. Thanks for critical words as always :P. But
this time I must agree too. :)
On Fri, 1 Sep 2017, Sven Barth via fpc-devel wrote:
Am 01.09.2017 12:15 schrieb "Maciej Izak" :
2017-09-01 11:41 GMT+02:00 Stefan Glienke :
{$EXPLICITHELPERS TH1, default for string}
s.foo; // TH1.foo
s.foo1;
s.foo2;
s.foo3;
end.
No,
Am 01.09.2017 12:15 schrieb "Maciej Izak" :
>
> 2017-09-01 11:41 GMT+02:00 Stefan Glienke :
>>
>> Again you will cause unnecessary headaches because now your helper has
the dependency of the builtin and the third party one.
>> How would third party one and
Am 01.09.2017 11:51 schrieb "Stefan Glienke" :
>
> What I am lobbying for in Delphi are interface helpers and helpers for
generic types in general.
>
> I just saw that FPC currently has the same limitation. That also on your
list?
>
Interface helpers are implemented in trunk
I consider that as terribly hard to maintain code. As soon as you move around
statements, refactor things everything gets messed up. No thanks.
> On 01 September 2017 at 12:15 Maciej Izak wrote:
>
>
> 2017-09-01 11:41 GMT+02:00 Stefan Glienke :
>
> >
On 01.09.2017 12:15, Maciej Izak wrote:
2017-09-01 11:41 GMT+02:00 Stefan Glienke >:
Again you will cause unnecessary headaches because now your helper
has the dependency of the builtin and the third party one.
How would third party
2017-09-01 11:41 GMT+02:00 Stefan Glienke :
> Again you will cause unnecessary headaches because now your helper has the
> dependency of the builtin and the third party one.
> How would third party one and third party two implement them? They both
> probably would extend the
On 01.09.2017 11:41, Stefan Glienke wrote:
Again you will cause unnecessary headaches because now your helper has the
dependency of the builtin and the third party one.
Not really, if you want to use both helpers (builtin and 3rd party) in
the same unit you have the dependencies already
What I am lobbying for in Delphi are interface helpers and helpers for generic
types in general.
I just saw that FPC currently has the same limitation. That also on your list?
> On 01 September 2017 at 11:07 Sven Barth wrote:
>
>
> Am 01.09.2017 08:47 schrieb
Again you will cause unnecessary headaches because now your helper has the
dependency of the builtin and the third party one.
How would third party one and third party two implement them? They both
probably would extend the builtin one. Which one can you use in your code then?
Yes, the one that
Am 01.09.2017 08:47 schrieb "Stefan Glienke" :
> Therefor I argue that the "only the last one in scope is applied"
restriction should be removed.
> If there are any clashes because two helpers introduce a any ambiguity
well then it is the compilers job to warn or error about
On 01.09.2017 8:47, Stefan Glienke wrote:
Inheritance seems like the obvious way but you just defer the "I
cannot extend the builtin helpers" problem.
If any third party code decides to do so you are at the same point
again because now do you inherit from the third party helper or from
the
Inheritance seems like the obvious way but you just defer the "I cannot extend
the builtin helpers" problem.
If any third party code decides to do so you are at the same point again
because now do you inherit from the third party helper or from the builtin one?
What if two third parties inherit
Am 31.08.2017 17:48 schrieb "Ondrej Pokorny" :
>
> On 31.08.2017 17:22, Sven Barth via fpc-devel wrote:
>>
>> > I remember a compiler bug in class destructor order call in Delphi:
On 31.08.2017 17:22, Sven Barth via fpc-devel wrote:
> I remember a compiler bug in class destructor order call in Delphi:
https://stackoverflow.com/questions/19332847/delphi-class-variable-going-out-of-scope-before-class-destructor-is-called
That should get solved once I reworked the unit
Am 31.08.2017 15:55 schrieb "Ondrej Pokorny" :
>
> On 31.08.2017 14:55, Sven Barth via fpc-devel wrote:
>>
>>
>> > Yeah, they might enable record helper inheritance for example :P
(Record helper inheritance was documented to work for about 7 years since
Delphi 2007 until XE6
On 31.08.2017 15:54, Ondrej Pokorny wrote:
By the way, FPC is affected by the very same bug:
https://mantis.freepascal.org/view.php?id=29334 .
Sorry, wrong link: https://mantis.freepascal.org/view.php?id=24256
Ondrej
___
fpc-devel maillist -
On 31.08.2017 14:55, Sven Barth via fpc-devel wrote:
> Yeah, they might enable record helper inheritance for example :P
(Record helper inheritance was documented to work for about 7 years
since Delphi 2007 until XE6
In our previous episode, Sven Barth via fpc-devel said:
> > Yeah, they might enable record helper inheritance for example :P (Record
> helper inheritance was documented to work for about 7 years since Delphi
> 2007 until XE6
>
Am 31.08.2017 12:07 schrieb "Ondrej Pokorny" :
>
> On 29.08.2017 22:30, Maciej Izak wrote:
>>
>>
>>>
>>> Btw. record helpers support inheritance in all modes but Delphi. It
doesn't make sense to disallow it for record helpers but allow it for type
helpers... Too overcomplicated
On 29.08.2017 22:30, Maciej Izak wrote:
Btw. record helpers support inheritance in all modes but Delphi.
It doesn't make sense to disallow it for record helpers but allow
it for type helpers... Too overcomplicated without any plus value :/
what if Delphi will decide to introduce
2017-08-29 22:09 GMT+02:00 Ondrej Pokorny :
> I, on the contrary, read:
>
> On 29.08.2017 18:54, Sven Barth via fpc-devel wrote:
> > (btw: a type helper for a primitive type can inherit from a record
> helper of the same type, internally they're all the same)
>
but in this
On 29.08.2017 22:06, Michael Van Canneyt wrote:
And actually, duplication of effort has a good side: in a way, the IDE
independently 'checks' the working of the compiler.
Unfortunately the reality is the other way round: the compiler checks
the working of CodeTools :)
Positive is that
On 29.08.2017 21:50, Maciej Izak wrote:
2017-08-29 20:24 GMT+02:00 Ondrej Pokorny >:
No - please not yet another undefined behavior :)
It's perfectly defined: disabled without typehelpers, enabled with
typehelpers.
but in the case of
On Tue, 29 Aug 2017, Maciej Izak wrote:
2017-08-29 17:51 GMT+02:00 Ondrej Pokorny :
On 29.08.2017 17:47, Anthony Walter wrote:
Out of curiosity, is there any strategy that is or can be employed to
ensure new language features and mode switches automatically work with
2017-08-29 17:51 GMT+02:00 Ondrej Pokorny :
> On 29.08.2017 17:47, Anthony Walter wrote:
>
> Out of curiosity, is there any strategy that is or can be employed to
> ensure new language features and mode switches automatically work with
> codetools and by extension the Lazarus
2017-08-29 20:24 GMT+02:00 Ondrej Pokorny :
> No - please not yet another undefined behavior :)
>
> It's perfectly defined: disabled without typehelpers, enabled with
> typehelpers.
>
but in the case of strictly defined rules we must to do as Sven said:
"Namely that it
On 29.08.2017 20:20, Maciej Izak wrote:
IMO inheritance for record helpers in Delphi mode has no really
meaning and may stay as undefined behavior
No - please not yet another undefined behavior :)
It's perfectly defined: disabled without typehelpers, enabled with
typehelpers.
Ondrej
2017-08-29 18:54 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
> Maybe it would indeed make more sense to adjust the meaning of the
> typehelpers modeswitch in mode Delphi... Namely that it enabled the "type
> helper" syntax including the inheritance. But the record
On 29.08.2017 18:54, Sven Barth via fpc-devel wrote:
Am 29.08.2017 17:39 schrieb "Ondrej Pokorny" >:
> So yes, your description of {$modeswitch typehelpers} makes sense
for 3.0.0 but not for trunk any more. So what is your intention -
3.0.0
Am 29.08.2017 17:39 schrieb "Ondrej Pokorny" :
> So yes, your description of {$modeswitch typehelpers} makes sense for
3.0.0 but not for trunk any more. So what is your intention - 3.0.0
behavior or trunk behavior?
Maybe it would indeed make more sense to adjust the meaning of
On 29.08.2017 17:47, Anthony Walter wrote:
Out of curiosity, is there any strategy that is or can be employed to
ensure new language features and mode switches automatically work with
codetools and by extension the Lazarus IDE?
Or is duplication of effort the only way to get codetools
Out of curiosity, is there any strategy that is or can be employed to
ensure new language features and mode switches automatically work with
codetools and by extension the Lazarus IDE?
Or is duplication of effort the only way to get codetools properly parsing
new language features?
There is a difference between FPC 3.0.0 and current trunk (without my
patch) regarding {$modeswitch typehelpers} and "TXYZHelper = type helper
for TXYZ".
In 3.0.0 it is obvious - it can be used only for primitive types.
In trunk you can use type helper for everything (with {$modeswitch
Am 29.08.2017 12:44 schrieb "Ondrej Pokorny" :
>
> On 29.08.2017 11:48, Sven Barth via fpc-devel wrote:
>>
>> The idea is okay as well, but I'd name it RecordHelperInheritance, cause
if we'd allow "type helper" in mode Delphi (as Maciej asks) then those
would support inheritance
On 29.08.2017 12:44, Ondrej Pokorny wrote:
{$modeswitch advancedrecords-} // it doesn't disable record helper for
TRec
Sorry, typo: "it disables record helper for TRec ".
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 29.08.2017 11:48, Sven Barth via fpc-devel wrote:
The idea is okay as well, but I'd name it RecordHelperInheritance,
cause if we'd allow "type helper" in mode Delphi (as Maciej asks) then
those would support inheritance by default as they aren't Delphi
compatible as a whole anyway.
Am 29.08.2017 10:37 schrieb "Ondrej Pokorny" :
>
> On 29.08.2017 8:47, Michael Van Canneyt wrote:
>>
>> On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote:
>>
>>> Suggested name is "NonDelphiExtensions".
>>
>>
>> Why not simply allow $RECORDHELPERS or so ?
>
>
> Hmm yes.
Am 29.08.2017 08:47 schrieb "Michael Van Canneyt" :
>
>
>
> On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote:
>
>> Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" :
>>>
>>>
>>> Hello!
>>>
>>> I find it unnecessary to disable record helper inheritance in
On 29.08.2017 10:43, Maciej Izak wrote:
I prefer to have also "type helper for" also in Dlephi mode instead of
"record helper for" for simple types. Different syntax for the same
thing is very annoying especially when someone need to work in many
modes. -,-
I don't care about the syntax that
2017-08-29 10:37 GMT+02:00 Ondrej Pokorny :
> Hmm yes. Reading https://www.freepascal.org/doc
> s-html/3.0.2/prog/progsu105.html you can define other non-delphi
> extensions for the Delphi mode (like NESTEDCOMMENTS).
>
> Maybe it would be more clear to name the modeswitch
On 29.08.2017 8:47, Michael Van Canneyt wrote:
On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote:
Suggested name is "NonDelphiExtensions".
Why not simply allow $RECORDHELPERS or so ?
Hmm yes. Reading
https://www.freepascal.org/docs-html/3.0.2/prog/progsu105.html you can
define other
On 29.08.2017 7:54, Sven Barth via fpc-devel wrote:
patches welcome. Suggested name is "NonDelphiExtensions"
Good to know, thanks. Luckily it wasn't that hard:
https://mantis.freepascal.org/view.php?id=32355
Ondrej
___
fpc-devel maillist -
On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote:
Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" :
Hello!
I find it unnecessary to disable record helper inheritance in Delphi
mode. Due to this artificial limitation I have to change unit mode from
Delphi to ObjFPC.
Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" :
>
> Hello!
>
> I find it unnecessary to disable record helper inheritance in Delphi
mode. Due to this artificial limitation I have to change unit mode from
Delphi to ObjFPC.
>
> Reasons:
> 1.) It's a limitation of a feature that
On Mon, 28 Aug 2017, Ondrej Pokorny wrote:
Hello!
I find it unnecessary to disable record helper inheritance in Delphi
mode. Due to thisĀ artificial limitation I have to change unit mode from
Delphi to ObjFPC.
Reasons:
1.) It's a limitation of a feature that FPC already has.
2.) I write
Ondrej,
I agree 100%. Many +1s. Thank you.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hello!
I find it unnecessary to disable record helper inheritance in Delphi
mode. Due to thisĀ artificial limitation I have to change unit mode from
Delphi to ObjFPC.
Reasons:
1.) It's a limitation of a feature that FPC already has.
2.) I write FPC-only code in Delphi mode. I don't care
54 matches
Mail list logo