[fpc-devel] Packages, Generics

[Willibald Krenn]

Marco van de Voort schrieb:
>> Played around with Delphi today, and it seems that class vars are 
>> somewhat broken on generic types. They work as expected (share common 
>> class value amongst all sameclass<sametype> instances) only in a unit 
>> scope, it seems. Which is a pitty.
> 
> To be honest, that is already more than I expected.

Well, half working is still broken. :-\
Better not supported than half working, if you ask me.

BTW: I've read somewhere on the internet (don't know whether that's 
true) that C# supports static fields in a proper way: Even if there is 
only one code-path for all object-related types, static fields are 
different for each different instantiated type. Hence Stack<TObject> 
would have different static fields than any object based on 
Stack<derivedFromObject>.


>  
>> since the '+' operator is not defined on T.
> 
> Generic versions of Delphi have operator overloading? Or did I miss
> something here? 
> 

Sorry, my bad. Compiler says not applicable.


>> Delphi lets you constrain your type parameters.  That said, I don't really
>> understand why constraints like :integer, :TObject are not allowed. 
> 
> Does C# actually allow that? I thought it only supported interfaces?

Well, you can use 'struct' (record in delphi), class, new (IIRC 
constructor in delphi), some base class, or some interface name, or some 
other generic parameter as constraint. Pretty much the same as in Delphi.


> Personally I only am interested in the constraint for object types. Many
> generic container types operating on objects only improve typing, and thus
> are runtime empty.  
> 
> Mapping them onto eachother makes .exe's and memory footprint smaller, and
> more importantly, might have an effect on caches.

And would need only one implementation in a package. ;-)
That said, there'd be still the need for different RTTI entries for 
different instantiations...

> The opposite constraint (that excludes inheritable types) could maybe be
> useful for optimizations.
> 
>> rtti checks etc. even with generic classes and packages.
> 
> You'll have to explain that in more detail. I fail to see the connection.

I don't know whether it is still the case but there was a time the 'is' 
operator relied on RTTI. So as soon as you have two different RTTI 
entries for, e.g., TMyList<integer> (which could happen if you compile 
with packages) the operator needs some 'repair'. I don't know how 
Delphi handles this today and whether to repair it is a good idea.

This, btw, was one of the downsides that made MDI-Child-Form-plugins via 
dlls back in D5/6 days quite difficult: even if the object was, say, a 
form, the 'is' operator failed. I'd need to look into the FPC sources to 
see how FPC handles this situation.


> 
> Moreover, this is turning into a generics feature and wishlist discussion,
> while it was about packages.

Well, it's related. Since generics have to be supported by packages, 
it's necessary to discuss the approaches. What must not happen is that a 
program behaves differently when compiled with packages because of the 
way things are done.

> Java and .NET also is a JIT who can delay certain things till runtime, when
> all loaded parts form a single program over which the JIT has more or less a
> complete overview. IMHO interesting for ideas, but not for implementation.

True, a JIT has additional runtime knowledge an will only construct the 
types that are really necessary.

> Delphi has constraints, but they don't reach your goals. So maybe it is time
> to stop the comparison game, and describe how you think such features should
> work.

Well, actually Delphi generics come really close. AFAICT generics in 
Delphi work the way I described them in one of my first emails about the 
subject: Within the generic type you can only do operations on the 
generic value that you know (from the constraint) are allowed. So you 
can compile (syntax check) the generic type separately from the code 
that uses it. This would in turn be beneficial for packages, as, e.g., 
for object types you could use one common code path. When using 
primitive types, code needs to end up in the dcp, yes, but perhaps there 
is a way so that RTTI is shared? (And class vars are working.)

That said, if there is no sane way for class vars working on generic 
types, I'd rather give them up (for these types).


Cheers,
  Willi