Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> On Apr 25, 2022, at 8:27 PM, Hairy Pixels wrote: > >> For some reason I don't get all mails by Ryan, so I reply here: >> >> Helpers currently can't be generic and even if they could be (which I do >> plan to add) it would require an explicit specialization of the helper to be >> used because the compiler will not be tasked with searching for potential >> generic helpers and then implicitly specializing a whole helper type with >> all its methods to maybe use it for an implicit specialization (and it needs >> to specialize the helper first to decide whether it even remotely contains >> suitable methods). >> > > You could do a search for method names and parameters to see if a generic > helper was a candidate before specialization. That would reduce the possible > space for needless specializations right? For non-object types this would be > even less intrusive since it would only be competing with other helper > methods. Note: CC’ing Sven in case he’s not getting these. First off see my reply above about implicit. Question is why can’t you filter out possible helpers by doing a pre-pass check for matching names? It’s certainly going to add some compile time overhead but it can be put behind a mode switch in the case it’s worthwhile (the compile time may be negligible in many cases). There’s also some optimizations I could think of so I wouldn’t give up on implicit specialization just yet. I had a look at some old notes I had on the idea of generic helpers since we talked about this some years back (for generic arrays) and here's what I found. 2) Right now helpers only support single types but they would need to be extended to support “array of T”, “set of T”,which by, why aren’t those supported as it is? I can’t seem to think of any reason they should be disallowed. The alternative is using an auxiliary generic type which kind of confounds things because then you’re extending a new type instead of the underlying array of set type. 3) If there was a generic helper for a generic class it may be too verbose to use the normal inline specialization syntax ie: generic THelper = class helper for specialize TMyClass So I wonder if the shorthand: generic THelper = class helper for TMyClass Could be used, providing the type to be extended has a matching generic parameter list. At the very least the “specialize” sounds wrong when reading it. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
On Sat, 30 Apr 2022 18:17:25 +0700 Hairy Pixels via fpc-pascal wrote: >[...] > So I wonder if the shorthand: > > generic THelper = class helper for TMyClass AFAIK it is planned for mode objfpc to support distinguishing types via template count as in mode delphi: type TMyClass = class end; generic TMyClass = class end; generic TMyClass = class end; So you would need something similar for helpers: THelper = class helper for TMyClass end; generic THelper = class helper for specialize TMyClass end; generic THelper = class helper for specialize TMyClass end; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> On Apr 30, 2022, at 7:02 PM, Mattias Gaertner via fpc-pascal > wrote: > > AFAIK it is planned for mode objfpc to support distinguishing types via > template count as in mode delphi: > > type > TMyClass = class > end; > generic TMyClass = class > end; > generic TMyClass = class > end; > > So you would need something similar for helpers: > > THelper = class helper for TMyClass > end; > generic THelper = class helper for specialize TMyClass > end; > generic THelper = class helper for specialize TMyClass > end; Now that would be a duplicate identifier error but that may be changed for Delphi compatibility? That indeed would break any possible shorthands. Maybe at least the specialize could be omitted because of the grammar which is so annoying. :) To the extent I have a todo list I’ve had plans to make a mode switch for “generic keywords” so you could disable them in Object Pascal mode (Svens idea). That would fix the specialize problem but honestly I kind of like the generic keyword as it’s a prefix and makes the type more clear. It’s the specialize keyword I have a problem with. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
Hi, Em sáb., 30 de abr. de 2022 às 09:13, Mattias Gaertner via fpc-pascal escreveu: > > AFAIK it is planned for mode objfpc to support distinguishing types via > template count as in mode delphi: > > type > TMyClass = class > end; > generic TMyClass = class > end; > generic TMyClass = class > end; This seems very likely to generate confusion, doesn`t it? Best regards, Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> On Apr 30, 2022, at 6:17 PM, Hairy Pixels wrote: > > 2) Right now helpers only support single types but they would need to be > extended to support “array of T”, “set of T”,which by, why aren’t those > supported as it is? I can’t seem to think of any reason they should be > disallowed. The alternative is using an auxiliary generic type which kind of > confounds things because then you’re extending a new type instead of the > underlying array of set type. Looking at this problem this morning and I wanted to give an example of what I was talking about. type generic TArray = array of T; generic TMyHelper = type helper for specialize TArray end; TIntHelper = specialize TMyHelper; The problem is TIntHelper is going to extend the type TArray instead of “array of Integer” (not to mention the boiler plate) so extra steps would have to be taking to make sure “array of T” type can find the helpers for TArray. Not sure what the best solution is but here are the ones I can think of: 1) allow the helpers to use “array/set of T” syntax. 2) register helpers for both types. 3) perform an extra step to search helpers for “array of T” or “set of T” types. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
