Original in Russian: http://18delphi.blogspot.ru/2013/10/interlockedincrementinterlockeddecrement.html
Wide use of interfaces “in general” and InterlockedIncrement/InterlockedDecrement in particular leads to a significant fall in productivity.
If you will – I have some unsuccess stories verified by measurements of AQTime.
By the way, if I were one of “ARC authors” I would take my stories into consideration.
P.S. Once (there were no mixins) we gave in to “mass hysteria of interfaces” and confused “interface compatibility” with “behavioral compatibility”. It resembles dealing with the “C++ templates”, “abstract classes” and “multiple inheritance”. There is a fine line between them. By NO MEANS always we need THE “interface compatibility”, far more often we need the “behavioral compatibility”.
P.P.S. I am amazed at ONLY ONE aspect – maintaining of appropriate productivity in Objective-C on selector (name) calling ALL methods. It EVEN works on MOBILE devices, EVEN with 3g.
Thing is, retain/release/autorelease THERE are so much unlike InterlockedIncrement/Interlockeddecrement. However, it works.
If you will – I have some unsuccess stories verified by measurements of AQTime.
By the way, if I were one of “ARC authors” I would take my stories into consideration.
P.S. Once (there were no mixins) we gave in to “mass hysteria of interfaces” and confused “interface compatibility” with “behavioral compatibility”. It resembles dealing with the “C++ templates”, “abstract classes” and “multiple inheritance”. There is a fine line between them. By NO MEANS always we need THE “interface compatibility”, far more often we need the “behavioral compatibility”.
P.P.S. I am amazed at ONLY ONE aspect – maintaining of appropriate productivity in Objective-C on selector (name) calling ALL methods. It EVEN works on MOBILE devices, EVEN with 3g.
Thing is, retain/release/autorelease THERE are so much unlike InterlockedIncrement/Interlockeddecrement. However, it works.
Комментариев нет:
Отправить комментарий