[Lazarus] Circular references and code quality

[Mattias Gaertner]

Juha Manninen <juha.manninen62 at gmail.com> hat am 4. Oktober 2011 um 12:01
geschrieben:


> 
> Hi
> There is lots of duplicate code and data definitions between Lazarus TProject
> and TLazPackage (and their ancestors).
 
True. 
On the other hand there are a lot of differences.
  


> 
> I tried to improve the situation by creating a common base class for them. It
> is not possible because it ends up with a circular reference hell.


> 
> [...]
> 
> Thus I found it strange that even Lazarus developers claimed they never
> encountered such problems. Yet, they have clearly worked hard to avoid
> circular references.
Huh? We encountered lots of problems. See the devel list archives. 
 
 


> 
> []
> 
> I just feel strongly that the language will remain a niche, not interesting
> for most people, because of this one single problem. Pretty much all other
> features are good.


> 
> [...]please show me how to reuse code between Lazarus Project and Package thus
> avoiding the duplicate code, without copying most Lazarus code into one unit.
> [...]
> Or, explain me why it is a good thing to have all those type-casts in Lazarus
> core-units (connecting to Designer etc.).
 
OP has one big feature: type safety. In a language like javascript you don't
need typecasts, but the drawback is that it is much more complicated to find a
bug and to extend existing code, because you don't know what a change effects.
It's one of the reasons why you can write one order of magnitude bigger projects
in OP than in javascript. 
So, the typecasts are ugly, but they have an advantage.  
Of course it would be nice to reduce the amount of typecasts.  
Many typecasts are caused by deep class hierarchies. 
Reasons for deep class hierarchies are
 
1. big classes were split into smaller ones. Logically it makes no sense, but
the class and unit would be too big, so the class was split. The 'too big'
depends mostly on the used tools aka IDE. In other words: It's nicer to work
with ten 3000 lines units than with one big 30.000 lines unit. 
 
2. classes were split instead of using parameterization. Instead of adding a
parameter to many methods, an abstract class and multiple descendants are
defined. This almost always duplicates code, but the code itself has far less
if-then-else blocks. OTOH it can create more if-then-else outside the split
classes. 
 
3. information hiding. A class is split into the public part and the private
part. Because the public part is used by third parties it must be carved in
stone and therefore you must be very careful what to put there.
 
4. logical abstraction. In a big project like the IDE you have multiple
definitions of 'public'. The debugger windows needs to access almost all
properties/methods of the debugger, but the source editor should only access
some of them. A developer working on the source editor should not need to
understand the full debugger. That means some units should work tightly together
and others less. There is no concept for this in OP, except splitting the
class. 
 
That being said:
What duplicated method do you want to combine into one? 
 
Mattias
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20111004/b24c23c1/attachment-0003.html>