[fpc-devel] Alternative parsers

[Florian Klaempfl]

Am 19.10.2010 14:38, schrieb Alexander Klenin:
> On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl <florian at freepascal.org> wrote:
>> Am 19.10.2010 13:54, schrieb Alexander Klenin:
>>> from fixing case and reformatting of Math unit
>>
>> This does not help anybody ;)
> See, you have already rejected it ;-)
> The initial motivation was that current unit have lower-case
> procedure names, which is not Delphi-compatible
> and messes up code completion.

Ok, this is a point. I'am pretty sure that a patch which fixes casing of
exported symbols will be accepted and I'am the first one who will apply
it. However, this is no argument to do reformatting. Casing yes, but
reformatting?

> 
>>> to finishing/extending Paul's work on for..in loop.
>> Does it still miss stuff? Actually, I never used it :)
> 
> It does not "miss" stuff, but could be extended.
> I meant http://wiki.freepascal.org/for-in_loop#Proposed_extensions
> 
>> So you looked yourself into the refactored code so you can judge it as
>> good? Did you send an email with your comment why it is good?
> 
> Actually, I tried to, although svn made it extremely difficult
> and I am not aware of git/hg mirror of branches.

Ask Graeme. But I felt reviewing with tortoisesvn pretty easy while
tortoisegit even doesn't allow me to diff pulled changes quickly in the
pull window.

> The changes are very promising (although IFDEF's are a mess,
> but as I understand they are planned for removal).
> I did not test and have not enough understanding of FPC internals
> to spot any breakage by code inspection, but the readability
> and modularization improvements are quite obvious to me.
> 
>> Where did you comment on the critism I made?
> I have really restrained myself from commenting on them
> because I it is hard to do in a polite manner.

Politeness is not important as long as the arguments are reasonable ;)

> Since you insist, I will try:
> 
>> - people knowing the old code for 15 years having to dig into new code
> Do you even understand how backwards this sounds?
> Using the outdatedness of code as an excuse not to refactor it
> is usually reserved for big corporations, not modern open-source projects :-)

Who says the code is outdated? I said only that people doing the work on
FPC have to dig into new code for no gain. And at least I'am not willing
to fix such new code if I see no gain.

> 
>> - slower
> Or maybe faster? Did you benchmark it?
> Of did you see a specific location of code which will cause slowdown?

Dislocation of code causes less efficient cache usage. Added calls,
added class instance accesses.

> 
>> - code spread over multiple locations
> Which is called modularization aka OO, and is IMO the main point of the branch

Only if it serves a purpose. There is no use on modularization or OO for
itself. In German you call something like this over-engineered.

> 
>> - lost svn blame history
> use git

I cannot see how git solves this for code being moved around and being
reindented, not to mention upper/lower casing changes.

> 
>> - last but not least, you coding style does not follow the compiler code
> style
> Which may be trivially fixed (btw, compiler code style is really ...
> um... exotic).
> 

This is out of discussion yet, the compiler uses its coding style and it
should be consistent as far as possible.