On 22.04.2011 12:18, Florian Klämpfl wrote:
Am 22.04.2011 12:06, schrieb michael.vancann...@wisa.be:
On Fri, 22 Apr 2011, Florian Klämpfl wrote:
mya.pp(16,12) Error: Operator is not overloaded: "complex" + "complex"
myb.pp(9,14) Fatal: There were 1 errors compiling module, stopping
Which is strange to say the least, as the per the definition/intent of
generics, the code in mya should not know anything about the types that
will be used when specializing. (in this case complex).
As per the intent of generics the second program above should compile
just as well.
But then different rules will apply for operators and procedure calls:
- procedure calls must be resolvable at define time
- Operators must be resolvable at specialization time.
No principal problem (we can define it so), but strange at least.
It is correct that the second doesn't compile. To make the second
compile, the overloaded operators for the complex type must be defined
inside complex (which was/is? not possible).
1. The + is not defined 'inside' integer either. Why should it be
required for a record ?
Internal types are special.
What kind of strange reasoning is that ? Are we going to redesign
operators for records ?
For pascal like generics it might be necessary to rethink some design
considerations, yes.
(I suspect this is why it is possible to add type restrictions in the
Delphi/.Net implementations)
2. If I have my own overloaded version of '+' for a record, the above
means that it
cannot ever be used for generics, while it will be used for all my
other code.
Say I define a type, and decide not to put the operators inside the record,
for whatever reason. I am happily unaware of generics. Along comes an
afficiniado of generics, and wants to use my type in generics, but hits
the above problem. He is stuck.
No. He can define a record helper operator. The question is simple: do
we want generics behave like macros or more like .Net generics. Some
hybrid approach is imo wrong.
Before I forget it: Why do you think that a hybrid approach is wrong?
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
