<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
</head>
<body>
<p style="margin: 0;">
<span>
<span></span>
</span>
</p>
<p style="margin: 0px;"> </p>
<div style="margin: 5px 0px 5px 0px;">
<br/>
Juha Manninen <juha.manninen62@gmail.com> hat am 4. Oktober 2011 um 12:01 geschrieben:
<br/>
<br/>
<blockquote style="margin-left: 0px; padding-left: 10px; border-left: 1px solid blue;" type="cite">
<div>Hi</div>
<div>There is lots of duplicate code and data definitions between Lazarus TProject and TLazPackage (and their ancestors).</div>
</blockquote>
</div>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">True. </p>
<p style="margin: 0px;">On the other hand there are a lot of differences.</p>
<p style="margin: 0px;"> </p>
<div style="margin: 5px 0px 5px 0px;">
<blockquote style="margin-left: 0px; padding-left: 10px; border-left: 1px solid blue;" type="cite">
<div>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.</div>
</blockquote>
</div>
<div style="margin: 5px 0px 5px 0px;">
<blockquote style="margin-left: 0px; padding-left: 10px; border-left: 1px solid blue;" type="cite">
<div>[...]</div>
<br/>
<div>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.</div>
</blockquote>
</div>
<p style="margin: 0px;">Huh? We encountered lots of problems. See the devel list archives. </p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;"> </p>
<div style="margin: 5px 0px 5px 0px;">
<blockquote style="margin-left: 0px; padding-left: 10px; border-left: 1px solid blue;" type="cite">
<div>[]</div>
<br/>
<div>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.</div>
</blockquote>
</div>
<div style="margin: 5px 0px 5px 0px;">
<blockquote style="margin-left: 0px; padding-left: 10px; border-left: 1px solid blue;" type="cite">
<div>[...]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.</div>
<div>[...]</div>
<div>Or, explain me why it is a good thing to have all those type-casts in Lazarus core-units (connecting to Designer etc.).</div>
</blockquote>
</div>
<p> </p>
<p>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. </p>
<p style="margin: 0px;">So, the typecasts are ugly, but they have an advantage. </p>
<p style="margin: 0px;">Of course it would be nice to reduce the amount of typecasts. </p>
<p style="margin: 0px;">Many typecasts are caused by deep class hierarchies. </p>
<p style="margin: 0px;">Reasons for deep class hierarchies are</p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">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. </p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">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. </p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">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.</p>
<p> </p>
<p>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. </p>
<p style="margin: 0px;"> </p>
<p style="margin: 0px;">That being said:</p>
<p style="margin: 0px;">What duplicated method do you want to combine into one? </p>
<p style="margin: 0px;"> </p>
<p>Mattias</p>
<p> </p>
</body>
</html>