<br><br><div class="gmail_quote">2012/10/24 Graeme Geldenhuys <span dir="ltr"><<a href="mailto:graeme@geldenhuys.co.uk" target="_blank">graeme@geldenhuys.co.uk</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012-10-24 07:52, <a href="mailto:michael.vancanneyt@wisa.be">michael.vancanneyt@wisa.be</a> wrote:<br>
> However, given the total lack of documentation, it is hard to say.<br>
<br>
</div>+1<br>
<br>
I had a look too, the Embarcadero website isn't much help.<br>
<br></blockquote><div><br>First some <span id="result_box" class="short_text" lang="en"><span class="hps">considerations:<br><br>- Initially i questioned the fpc obsever support, now i see as a good implementation<br><br>
- I think Delphi compatility important<br><br>- We don't have much info about the Delphi implementation since is not properly documented (i would bet it was introduced to support the Live Bindings)<br><br></span></span><br>
<span id="result_box" class="short_text" lang="en"><span class="hps">When i asked, i did not have any preference of any interface, the only option that i would have objections was 3 (two implementations) since would have overlapping features with possible overhead (two observer lists per component?) at base classes<br>
<br>Given that fpc one is good enough, and Delphi one is at minimal obscure, i would consider break the "Delphi compatibility/feature parity" and stay with fpc one. Of course, if the Delphi one shows somehow to be technically better it's also a option to stay with it. But never the two.<br>
<br>Regarding Delphi compatibility, currently fpc already lacks much features in areas like attributes, anounimous methods, generics, interfaces, unicode and some will never land at fpc.<br><br>This can be (or not) a start point to depart from playing "Delphi catch up" at all cost and port only the features that matches the fpc direction (whatever it is)<br>
<br>Luiz<br></span></span></div></div>