[fpc-devel] Recent added support for Observer pattern in FCL
Back in 2010, in the thread about observer support in fcl, i asked if the actions would be customizable so i could, e.g., notify/observe if a child was added or removed in a tree structure. The answer was yes. Looking at the recent added support, it limit the actions (called operations) to 5 types TFPObservedOperation = (ooChanged,ooFree,ooAddItem,ooDeleteItem,ooCustom); I ask to change to a mechanism that could allow customizable operations (more than one) I'm asking that because i have implemented a similar mechanism that support operations like Load, ChildAdd, ChildDelete, ChildChange. I believe that more developers are in the same situation,i.e., using observer pattern to an action not handled by those 5 types. It would be helpful to use the native implementation otherwise i will have to keep(re-implement) the observer support over TPersistent. BTW: The names of the TFPObservedOperation are not consistent: ooChanged is in preterit while others not ooChanged does not has Item suffix it should be ooChange,ooAdd,ooDelete or ooChanged,ooAdded,ooDeleted or ooChangeItem,ooAddItem,ooDeleteItem or ooChangedItem,ooAddedItem,ooDeletedItem The changes: http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=22257 See the cited email: Michael Van Canneyt escreveu: On Thu, 20 May 2010, Florian Klaempfl wrote: I've no opinion if it's usefull to add or not, I use TPersistent+ too little but my concern is: if I create an observer for an instance, I'd expect to get notified about every change to the instance. But I cannot see how this will be achieved, no existing class is prepared for this? Not every change. What you get notified about is defined by the class that uses the observable interface. TStrings will notify you of additions/removals, and TList/TObjectList as well. It will send some kind of info (like index or address of the object) to know what and where the item was added or removed? Yes. Can the same Obsever observe (:-D) more than of one type of object? e.g. i want to observe a object list for adding or removals, but also want to know if one of the child objects changed. Yes. You can observe any object that will implement the IFPObservable interface. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
In our previous episode, Jonas Maebe said: > > Seriously, even if you forget compatibility, it is impossible to assess > > something like that without in-depth design (and preferably a test > > implementation). > > Could always look at Delphi XE3: > http://twitter.com/statuses/user_timeline/9146192.rss :) Assuming you mean the stringhelper remark, that is exactly what I wouldn't do. That looks like a compatibility workaround to me, instead of reengineering without compatibility. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
marcov wrote on Mon, 27 Aug 2012: Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation). Could always look at Delphi XE3: http://twitter.com/statuses/user_timeline/9146192.rss :) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27/08/12 09:43, Marco van de Voort wrote: Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation). Wouldn't something like Java's String and Character classes already be good in-depth reference implementation of this? Java is extremely successful, so we know their implementation is good too. The same can be said for Qt's QString class. I had a quick 30 minute investigation into the Java String class. I quite like the idea of an immutable string too. This will make multi-threaded data access super easy - no need to worry about threads modifying your string instance. In FPC terms, then String class can be a reference counted IInterface class, so we don't have to worry about freeing every string instance. I also like the fact that in the Java String class implementation, there is nothing left to "guess work" for the developer. Methods like .length(), .charAt(), .codePointAt() etc are pretty self explanatory, and if in doubt, the documentation clearly states what those method do, what they return and how surrogate pairs (Java uses UTF-16 internally) are handled. I must add that Java (and Qt QString) do include some compiler magic to make instantiation and concatenation slightly easier. But in both cases they clearly document how it could be used, and mention pitfalls if any. Qt's QString also has methods like .toUTF8(), .fromUTF8(), .fromRawData(), .toLatin1(), .fromLatin1() - again making it super easy to see what is going on and what will happen - no developer guessing required, or having to double check the string types to see what conversion are going to happen. Anyway, I did say "hypothetically" in my first message. :) Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27.08.2012 11:51, Michael Schnell wrote: On 08/24/2012 03:14 PM, Mark Morgan Lloyd wrote: Would there be any advantage in reimplementing strings as a tree of classes, If in future TObject is reference (as it might be in a future Delphi version, according to an Embarcadero blog) counting (and thus using .Free is not mandatory any more), it seems very appropriate to have String be a sibling of TObject. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Fully agree with you! Automatic reference counted object with set of overloaded methods and operators suitable for any legacy string types. Vote for this! regards, Anton ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 27/08/12 08:04, Mattias Gaertner wrote: http://xkcd.com/927/ :-) G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On 08/24/2012 03:14 PM, Mark Morgan Lloyd wrote: Would there be any advantage in reimplementing strings as a tree of classes, If in future TObject is reference (as it might be in a future Delphi version, according to an Embarcadero blog) counting (and thus using .Free is not mandatory any more), it seems very appropriate to have String be a sibling of TObject. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
In our previous episode, Graeme Geldenhuys said: > > I doubt it. You maybe could (and probably would) in a new language, and have > > one single stringtype. > > > > FPC is closer to 20 stringtypes or types with autoconversions. (First, while 20 sounds bad, you will keep at least ten-twelve anyway, with this way of counting (think types like char, pchar and array of char (open array dynamic and static), all in 1-byte and 2-byte versions, then literal), simply because _WE_ can standarize on one type, but the outside world won't) > Thinking hypothetical here... what if FPC 3.0 did just that... Rethink > the whole 20 string types mess, and implement only one string type for > 3.0 onwards. How would developers feel about that? More, why not go wild and explorative, and use Michael Schnell's idea to use an object per char? Since it would be your fork, you can do whatever you want with it :-) Seriously, even if you forget compatibility, it is impossible to assess something like that without in-depth design (and preferably a test implementation). > What would the advantages be to developers and FPC maintainers? What > would the disadvantages be (other than it will probably break existing > code - which the Unicode support will probably do too). Read the unicode pdf. There was some deep thinking on that before D2009 came out, and some of the problems are that you never will know what is in a polymorphic string type. Moreover, think that you will have to satisfy everybodies requirements, not just what you think you need. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
Rethink the whole 20 string types mess, and implement only one string type for 3.0 onwards. == No, No ! It'll 100% be slow & problematic UTF8. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
Mattias Gaertner wrote: FPC is closer to 20 stringtypes or types with autoconversions. Thinking hypothetical here... what if FPC 3.0 did just that... Rethink the whole 20 string types mess, and implement only one string type for 3.0 onwards. How would developers feel about that? What would the advantages be to developers and FPC maintainers? What would the disadvantages be (other than it will probably break existing code - which the Unicode support will probably do too). http://xkcd.com/927/ :-) Hence my original query about whether it could be reimplemented as a base class plus inheritance for specialisation, i.e. try to replace messy ad-hoc stuff using facilities which the underlying language has gained since its initial implementation. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On Sun, 26 Aug 2012 18:49:05 +0100 Graeme Geldenhuys wrote: > On 26/08/12 13:40, Marco van de Voort wrote: > > I doubt it. You maybe could (and probably would) in a new language, and have > > one single stringtype. > > > > FPC is closer to 20 stringtypes or types with autoconversions. > > > Thinking hypothetical here... what if FPC 3.0 did just that... Rethink > the whole 20 string types mess, and implement only one string type for > 3.0 onwards. How would developers feel about that? What would the > advantages be to developers and FPC maintainers? What would the > disadvantages be (other than it will probably break existing code - > which the Unicode support will probably do too). http://xkcd.com/927/ Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
