On Wed, 28 Nov 2012, Marco van de Voort wrote:
In our previous episode, michael.vancann...@wisa.be said:
Then Luiz is right on time with his proposal, with the frist release
candidate of the first release that contains this feature. If
production code already uses it, then the production code writers must
have taken a risk for change knowing that this was a not yet released
feature.
It's rather the opposite. This code was developed and has been in use since
years. I simply integrated the code in the classes unit, making the
production code simpler.
Yes, and by doing that you submit it to public scrutiny, risking other
opinions.
Sure.
Based on feedback, the interface was already changed slightly, but not in
a super invasive way as asked here.
Apart from that, I don't see the point in changing it to an interface.
At some point, there must be an object, and at some point, there is a
typecast,
You often can't reroot external components, but if they support tcomponent
What does "reroot external components" mean ?
(and thus Tinterfacedobject), you can add an interface in a child class.
The interfaces are CORBA, so there is no need for TInterfacedObject.
That the interface is CORBA was a conscious decision so reference counting
and all the overhead associated with it was avoided. As far as I know, this
rules out COM provided interfaces (if this is what you refer to by external
components). That is a tradeoff I find acceptable.
I can see the speed argument when notifying, but that can be changed by
an internal change, without API changes.
As Paul and Vincent correctly state, from the view of the FPC project, the
interface is not yet fixed.
Correct.
But I want to see some stronger reasons than the ones given before I change the
API.
Like I said:
The one about speed in notifyupdates is not a problem, I'll improve that,
implementation speed is important.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
