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 agree, it was a bit bumpy road, we could have save
some wasted time.
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.
Yes, although this will create a mixed resolution for Xbase++
compatibility, as some functions are XPP prefixed, some others
aren't and some others are PP mapped. To make it universal I think
we should create xpp.ch as you say and at the same time prefix all
XPP functions with 'xpp_'. xpp.ch would then map/remap functions
to Harbour or xpp_ equivalents and vice versa.
Before we do this however, I think we should move all XPP compatible
functionality to a separate library. I was proposing 'source/dialect/
xpp'
for this. This has one advantage over contrib: hbmk2 can know
about it and compatibility can be much better controlled this way.
Such move can have some side-effect, like STOD() which is now an
Xbase++ compatibility function, will move to dialect lib.
In fact even xhb lib is a dialect lib.
Now all the above leads a bit more futher than it'd be good to
move before release, so to have a lighter start I'll add a contrib/xpp
dir and also add an xpp.ch header, which will then be installed to
'include'.
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.
I agree. Array access of objects is pretty 'bad thing', it wasn't
even intended by design probably, rather just a side-effect of
object implementation in C5x.
As for having same variable and method names it's okay with me
if it give some benefits, although generally IMO it makes code
more ambiguous, since the name won't anymore define the action,
which means the context must always be inspected to know what to
expect.
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.
Sure thing.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
