[fpc-pascal] FPImage and GetDataLineStart

[Sven Barth]

On 22.04.2011 12:36, Sven Barth wrote:
> On 22.04.2011 12:18, Florian Klämpfl wrote:
>> Am 22.04.2011 12:06, schrieb michael.vancanneyt at 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.
>
> Oh dear... I have completely forgotton about operators in record helpers
> in my implementation...
>
> Nevertheless I don't think this would help in the current situation.
> Let's assume he uses a 3rd party record that does not contain operators
> (only global ones) and he uses a 3rd party generic type. Let's further
> assume that the user can't or does not want to modify those two types.
> Then he can't use a record helper during the specialization, because
> that helper isn't available in that time like the global operators
> defined along side the record aren't.
>
> I must admit though that I have a really bad feeling about my above
> assumption when I think about my lookup code... so when I enable
> operators in record helpers it might even work currently by accident O.o

Ok... it does not work that way currently... (puh) [I tested using a 
normal function instead of an operator]

Regards,
Sven