<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 26, 2013 at 7:06 AM, Fabrício Srdic <span dir="ltr"><<a href="mailto:fabricio.srdic@gmail.com" target="_blank">fabricio.srdic@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>I agree with the importance of backward compatibility, but I disagree when it becomes a reason to stop the implementation of improvements in the tool.<br>
</div></div></blockquote></div><br>Well, no. You shouldn't say "improvement". Because "improvement" has positive context, already.<br></div><div class="gmail_extra">Instead, you should use the word "change" which is more neutral. <br>
<br></div><div class="gmail_extra">So let me paraphrase you: "I agree with the importance of backward compatibility, but I disagree 
when it becomes a reason to stop the implementation of changes in 
the tool."</div><div class="gmail_extra">Doesn't sounds so bright, right? Because it's unknown if a change is good, if it helps or if it is beneficial.<br><br></div><div class="gmail_extra">So whenever a change comes in it is typically being reviewed by following categories:<br>
</div><div class="gmail_extra">* why is the change needed? (Delphi compatibility)<br><br></div><div class="gmail_extra">* what's the benefit of the change?  - the most important question here - is what the change gives to developers, that they couldn't do earlier? <br>
</div><div class="gmail_extra">* what's the disadvantage  of the change? - there's always at least one disadvantage present - the language itself gets more and more complicated. (the minimalistic approach is typically followed, as it makes the language as a tool more "lightweight" and easier to master and learn)<br>
<br></div><div class="gmail_extra">Any change passes that review (not just namespaces). <br></div><div class="gmail_extra">a change with the benefit:<br></div><div class="gmail_extra"></div><div class="gmail_extra">1) "a pascal developer is not be to XXX at all with out this change" - are typically accepted without much discussion (i.e. support of ObjC/JVM/LLVM targets)<br>
</div><div class="gmail_extra"></div><div class="gmail_extra">2) "a pascal developer can do XXX, but the change YYY should make it better, but might be FPC specific" - typically inspire some productive discussions. (i.e. generics, I'd add Unicode rtl here as well) and change typically comes into the compiler;<br>
</div><div class="gmail_extra"></div><div class="gmail_extra">3) "a pascal developer can do XXX, but the change makes it look like YYY, which is delphi compatible" (i.e. class-helpers, sealed classes)  - are typically ignite a lot of discussions and flamewars between conservative and modernists developers.  However, the change is typically being added to the compiler (under a certain mode or modeswitch).<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the end, it is up to a pascal developer to either keep using XXXs or switch the code YYYs.<br></div><div class="gmail_extra">And a pascal developer can be sure that there're far more other developers that do understand XXX than the ones who understand and use a YYY. Thus getting help (and maintenance) with XXX-based code, is more likely to happen.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">thanks,<br>Dmitry<br></div></div>