[fpc-pascal] FPImage and GetDataLineStart

[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? 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