Am 22.04.2011 11:32, schrieb Sven Barth: > 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?
No. But during spezialication only the symbols are available: - which were available during definition of the generic - the symbols of the type parameter arguments > What if the user wants to use a > class instead of a record? Or an object? Those should be allowed to contain operators as well. > And what if the operators are > only defined global like the Variant ones... > Variant might be a problem. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
