[fpc-devel] TFPHashList (Was: Alternative parsers)

[Marco van de Voort]

In our previous episode, Alexander Klenin said:
> >
> > Major work like that is already always combined with major refactoring and
> > rewriting, so that is unlikely, and they touch totally different systems
> > (frontend vs backend)
> 
> I am not sure I understood you point.
> Is not your whole argument that the refactoring is bad/not needed?

No, first  mine is conditional on  "as needed" (and I also wrote in the
message that the chance is low since they are different subsystems),

while yours was up front and unconditional.
 
Second, it might not be the same refactoring, since the "as needed"
refactoring might need to adress additional points that come up in the
implementation/design of the feature that actually needs the refactor.

Note that I'm purely reacting to your reasoning, and it has nothing to do
with my opinion on the shortstring/ansistring matter. (in which I might be
described as being in the ansistring camp, mainly because of the 255 limit
and the fact that I'm told that that is a reason to not have unit
qualifications in parameter mangling).

> > Point out the example of bugs. (ones that matter, not the stylistic ones)
> 
> This sub-thread was started by mentioning the series of errors
> my student made when trying to implement case of string.
> Most of them was due to the fact the code used pchars and records
> instead of strings and (hierarchy of) objects.

Yes. But that might be a result that FPC is oriented towards production, and
not towards education.

> Surely, a more qualified developer would probably have avoided these,
> but still I think this is a good demonstration of adverse side-effects
> of micro-optimizations.

It is why this is frowned on in educational oriented projects. But FPC is
not oriented oriented, its mission goal is being an usable, production
compiler. And speedy use is a main factor, and goes above quick entry of
students.