<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 20, 2014 at 8:02 AM, Chriss Kalogeropoulos <span dir="ltr"><<a href="mailto:iz.iznogood@gmail.com" target="_blank">iz.iznogood@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">Hi all,</p>
<p dir="ltr">Why would anyone want something like that? Both languages have interfaces that can be used for auto reference counting and they also provide us with a very powerful abstraction mechanism.<br>
This also adds overhead on the performance (and locking calls) which might be important in some cases like embedded devices.</p>
<p dir="ltr">The fact that embarcadero added this feature unconditionally is a huge mistake IMHO unless they needed it for some compatibility reasons with java for android or iOS or just marketing, I don't know. If someone knows any other reason please post it on the list.</p></blockquote><div><div>Yes. Embarcadero thinks in productivity. See the new IDE of them, it is extremely productive.</div><div><br></div><div>Unfortunately, who doesn't modernize, tied in old concepts, can lose your market/product/space/people to your competitors, IHMO. :-/</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir="ltr">It's the same bad decision they made with the zero based strings, at least the used a switch for that.</p>
<p dir="ltr">The only gain I can see from that is that with objects someone can use reference counting and still benefit from some aggressive optimisation like inlining which is not possible for interfaces. The same with simple properties that they need getter and setter methods in interfaces that cannot be optimized but in objects it might be possible or they can access the data member directly.</p>
<p dir="ltr">In my opinion this is a very small gain compared to the huge change in the language semantics that you propose.</p>
<p dir="ltr">Chriss<br>
</p>
<div class="gmail_quote">Στις 20 Σεπ 2014 1:41 μ.μ., ο χρήστης "Hans-Peter Diettrich" <<a href="mailto:DrDiettrich1@aol.com" target="_blank">DrDiettrich1@aol.com</a>> έγραψε:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Fabrício Srdic schrieb:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
In platforms with managed code (.NET, Java), objects are automatically freed by the memory manager / garbage collector.<br>
<br>
Would not it be interesting to have a similar feature in FPC?<br>
</blockquote>
<br></span><span class="">
AFAIK some Delphi XE made TObject itself managed, by reference counting. It would be easy to introduce the same feature in FPC, so that no special base class would be required. Like with extended RTTI a decision should be made, whether managed objects should be enabled or disabled by default. Afterwards automatic management can be turned on or off for every single class or object individually.<br>
<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For example, through a root class where its objects are counted by reference, like the TInterfacedObjects. Thus, the programmer would be free from having to manually release objects.<br>
</blockquote>
<br></span>
In practice it turned out that the automatic destruction of objects still requires assistance of the coder, in many cases, in all languages with garbage collection. I.e. a destructor (or finalizer) still is required to prepare an object for subsequent destruction.<br>
<br>
IMO it's sufficient to use Interfaces for all objects that should be subject to garbage collection.<br>
<br>
DoDi<span class=""><br>
<br>
______________________________<u></u>_________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/" target="_blank">http://lists.freepascal.org/</a><u></u>cgi-bin/mailman/listinfo/fpc-<u></u>devel<br>
</span></blockquote></div>
<br>_______________________________________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Silvio Clécio<br>My public projects - <a href="http://github.com/silvioprog" target="_blank">github.com/silvioprog</a>
</div></div>