On Sat, Sep 20, 2014 at 8:02 AM, Chriss Kalogeropoulos < iz.iznog...@gmail.com> wrote:
> Hi all, > > 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. > This also adds overhead on the performance (and locking calls) which might > be important in some cases like embedded devices. > > 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. > Yes. Embarcadero thinks in productivity. See the new IDE of them, it is extremely productive. Unfortunately, who doesn't modernize, tied in old concepts, can lose your market/product/space/people to your competitors, IHMO. :-/ > It's the same bad decision they made with the zero based strings, at least > the used a switch for that. > > 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. > > In my opinion this is a very small gain compared to the huge change in the > language semantics that you propose. > > Chriss > Στις 20 Σεπ 2014 1:41 μ.μ., ο χρήστης "Hans-Peter Diettrich" < > drdiettri...@aol.com> έγραψε: > >> Fabrício Srdic schrieb: >> >>> Hello, >>> >>> In platforms with managed code (.NET, Java), objects are automatically >>> freed by the memory manager / garbage collector. >>> >>> Would not it be interesting to have a similar feature in FPC? >>> >> >> 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. >> >> 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. >>> >> >> 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. >> >> IMO it's sufficient to use Interfaces for all objects that should be >> subject to garbage collection. >> >> DoDi >> >> _______________________________________________ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel >> > > _______________________________________________ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > > -- Silvio Clécio My public projects - github.com/silvioprog
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel