[fpc-pascal] FPImage and GetDataLineStart

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Fri Apr 22 13:47:57 CEST 2011

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

> In our previous episode, michael.vancanneyt at wisa.be said:
>>> 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,
> What do you mean, C++,C#, Java ?

No, they are "old" languages too. I was more thinking in terms of 
PHP, Ruby, Python, Javascript (and its variations). I haven't come 
accross generics for these languages. Yet they are widely adopted.

>> 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.
> It eases some cases where that strictness hurts. There are multiple
> solutions for such cases, e.g. in the database world, people went for
> variants.

I have a database with over 7000 fields, another with 3000, for neither
variants are used. Maybe I misunderstand your statement.

> Generics are typically for cases where the types are
> parameterizable.
>> 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.
> They are as subjective as a one person mandated ban on generics. Even long
> term.

Exactly, which is why the discussion was leading nowhere :-)

>> 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,
> I see no workable solution at this moment. So I'll wait what you have to
> offer, and see if it matches my own. Otherwise I'll see if I can create some
> parallel bae library, but that has to wait till generics on FPC are more
> mature.

Fair enough.

Meanwhile you can help by supplying me with a test image file that takes too 
long to load. I recall you said something about seconds. Since all the ones
I use load in acceptible times, I'd like to see one where things go badly wrong.


More information about the fpc-pascal mailing list