Alexander Klenin schrieb:
In the first step I'll enclose all semantical code into begin-end,
so that it can be easily hidden (folded) in the Lazarus IDE.
This is not needed -- you can use {$REGION} ... {$ENDREGION}
directives instead.
I'll need begin-end anyways, when the code becomes a subroutine.
If/when somebody implements http://bugs.freepascal.org/view.php?id=13974,
you will be even able to auto-fold irrelevant parts automatically.
That would be nice, indeed, but how should it know which if-else branch
is irrelevant?
Later these blocks shall be extended into
if cond then
new_proc
else
begin
[old code, also copied into new_proc()]
end;
Hm, did you consider a proper object-oriented implementation?
I know it is not easy, but since you are going for a great refactoring anyway...
Yes, of course, it can be done in further steps. My very first approach
used a semantics class, but after the performance discussion and other
problems I dropped it. Some parser routines already are methods, of e.g.
psub.TcgProcInfo.
For first results see the dodi/parser_rewrite branch.
Generally speaking, long-lived feature branches should be avoided in SVN,
since the merging is incredibly painful. So it would be advisable to merge
back as soon as possible, or even just work on trunk, using
the techniques you mentioned above to avoid breakage.
I'd appreciate if my work would find its way into the trunk soon. But
how to maintain the duplicate code (inlined and in procedures/methods)?
Include files were a technical solution, but only until the
procedure/method code deserves further modifications. And I wouldn't
like to see hundreds of parser include files...
DoDi
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
