On 22.04.2011 11:23, Florian Klämpfl wrote:
Am 22.04.2011 00:31, schrieb Michael Van Canneyt:
On Thu, 21 Apr 2011, Sven Barth wrote:
On 21.04.2011 21:45, Michael Van Canneyt wrote:
On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
You can propose whatever you want _but_ generics.
Motivation?
Threefold:
a) The compiler's handling of generics is still beta code in my opinion.
As far as I know, the original problem I reported when writing the docs
for them is still not solved.
May I ask out of curiosity which problem you mean?
There were several.
The first one seems solved (see docs, section on 'A word on scope', the
local thing), compiler now gives an error (a debatable solution IMHO,
but better than the crash at the time.).
Second problem:
The following compiles:
uses ucomplex;
type
Generic TMyClass<T> = Class(TObject)
Function Add(A,B : T) : T;
end;
Function TMyClass.Add(A,B : T) : T;
begin
Result:=A+B;
end;
Type
TMyIntegerClass = specialize TMyClass<Integer>;
TMyComplexClass = specialize TMyClass<Complex>;
end.
but the following does not:
---------------------------------------------------------
unit mya;
interface
type
Generic TMyClass<T> = Class(TObject)
Function Add(A,B : T) : T;
end;
Implementation
Function TMyClass.Add(A,B : T) : T;
begin
Result:=A+B;
end;
end.
---------------------------------------------------------
and program :
---------------------------------------------------------
program myb;
uses mya, ucomplex;
Type
TMyIntegerClass = specialize TMyClass<Integer>;
TMyComplexClass = specialize TMyClass<Complex>;
end.
---------------------------------------------------------
Results in:
home:>fpc -S2 myb.pp
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).
It should be possible now, I didn't test it though yet.
The question is: should we really restrict the overloads to operators
defined inside those structures only? What if the user wants to use a
class instead of a record? Or an object? And what if the operators are
only defined global like the Variant ones...
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
