On Fri, 05 Jun 2009, Szak�ts Viktor wrote: Hi,
> For me coffee.prg works prefectly. Nice demo, and thanks to > Przemek for making it work with Harbour as is. It works exactly like in xbase++ after: 2009-06-05 06:10 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) before it was difference in unlocking sync method by <oSignal>:wait() and Pritpal was right reporting it. The main problem when we are adding some XPP compatible extensions is knowledge about exact xbase++ behavior. Neither XPP documentation nor XPP user messages describing some features are precise enough and very often gives wrong information. Sometimes the difference is really huge and like in this case the real xbase++ solution is nothing more then simple local function call which does not need deep core code modification I had to made. We have to remember that before we try to add any new xbase++ compatible extension it's necessary to make extensive tests with real binaries compiled by this language to verify xbase++ documentation and xbase++ user knowledge. > I had to add these liness to the top of coffee.prg: > --- > #xtranslate dispoutat(<x,...>) => hb_dispoutat(<x>) > #xtranslate sleep(<x>) => xpp_sleep(<x>) > #include "hbclass.ch" > --- > and build with: > hbmk2 coffee.prg -mt Maybe we should add xpp.ch with such definitions just like now we have hbcompat.ch? Then it will be enough to use -u+xpp.ch as harbour or hbmk2 switch to compile some xbase++ source code. Anyhow we still do not have real class objects support like in Class(y) and XPP seems to follow class(y) syntax and have them so some code many needs manual updating. Just like some Clipper+Class(y) code ported to Harbour. In XPP there are also some other differences, f.e. methods and instance variables can use the same names. Here Harbour is Clipper and Class(y) compatible and XPP is extended. The object in XPP is not an array, at least it cannot be accessed using [] operator and IMHO it's quite good idea because it introduce some encapsulation which allows to eliminate some code used to validate object structure at runtime. Maybe we should also think about adding such extensions to Harbour. Anyhow they will have to be optional because they will interact with some existing Clipper code which may use some tricks based on low level OOP implementation in Clippper, f.e. instead of: o:var := 123.45 some can use: o:_var( 123.45 ) etc. One of the most strongest thing in Harbour is very high compatibility with Clipper (much better then in all other Clipper compatible languages like xbase++, CLIP, FlagShip, ...) and we should keep it as long as possible. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
