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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
