[fpc-pascal] FPImage and GetDataLineStart

[michael.vancanneyt at wisa.be]

On Fri, 22 Apr 2011, Marco van de Voort wrote:

> In our previous episode, Michael Van Canneyt said:
>>>
>>> However when implemented using generics you can also directly use the
>>> specialized type, and have fairly quick direct access.
>>
>> You don't need generics for that. Any form of an array of bytes will do,
>> since that's what it amounts to in the end anyway.
>
> But it has to figure out runtime which to use, or you need to duplicate a
> class for each storage type and deal with delegation overhead.
>
> I've complete understanding for the fact that generics are too early, but
> IMHO it is the long term solution. Anything else would be madness, or minor
> damage control at best.

Most of the more "recent" or "new" languages I know do not have generics, 
which puts a question mark beside the 'long term' and 'madness'. 
One could argue that generics itself is "damage control", on a language level, 
for the "old languages" to alleviate the restrictions of strict typing.

Generics in FPC are a typing aid, borrowed from C++, no more, no less. 
This is an old discussion, which I will not repeat.

So please stop using nice sounding one-liners like 'madness' and "long-term
solutions", "damage control". They are highly subjective and therefore of 
no value, as they only put your beliefs against mine.

>>>> The thing will be to parametrize the needed storage formats, and then implement
>>>> the reader support for them.
>>>
>>> How will you implement reader support for many memory layouts?
>>
>> I am not that definite in my design. But I'm willing to listen to ideas.
>> (barring the ones relying on the use of generics)
>
> Last night, we started a fund raiser on IRC to buy you a more recent Delphi
> version :_-)

Please dispense with the dialectic tricks.

fcl-image is meanwhile more long-lived than many other FPC components out there. 
Yes, it has a speed issue. I am aware of that since a long time and am 
willing to work on it. I did the bulk of the design and maintenance in 
the past, I'll handle this as well.

So you can cooperate with me and propose solutions that I'm willing to implement
and spend time on, or continue this sterile discussion about something which you 
know I will not accept anyway.

Michael.