[fpc-devel] Need advice for refactoring

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sat Jul 17 12:41:32 CEST 2010


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




More information about the fpc-devel mailing list