On Tue, 02 Feb 2010, Maurilio Longo wrote:
Hi,
> I'm trying to rebuild a project of mine with harbour (it was developed with
> xharbour) but I'm facing a problem, it seems that an object I'm accessing with
> a "with object xxx" does not work inside macro compiler.
> Example:
> with object MyObject
> &( "{|| x := :MyMethod() }" )
> end
> It gives a syntax error &
Yes, it is. It's intentional.
> This is code which has been working for years, so maybe I'm overlooking
> something, but before I start digging deeper I'd like to know better about
> this issue.
It works only with xHarbour. I can make it working with Harbour too
but in fact it will seriously limit farther extension.
To be precise I should even block current code which allows to use
such syntax in clodeblocks because it's possible to create GPF.
In next commit I'll add only protection for such GPF (it will work
like in xHarbour) and we can try to talk about the future of WITH OBJECT.
Here is the code which illustrates the problem:
proc main()
local cb
with object .F.
with object 0
cb := {|| :className }
? eval( cb ) // NUMERIC
end
? eval( cb ) // LOGICAL
end
? eval( cb ) // GPF or NIL after incomming commit.
return
As you can see codeblock is created inside 'with object 0' statement but
can be used outside this statement when the given object does not longer
exist so it does not confirm WITH OBJECT specification and has to be fixed.
We have two choices:
1) detach WITH OBJECT variable lust like local variables
and add code which will resolve references in each :<msg> code.
It will cause some small speed overhead but it will work
2) forbid using :<msg> in nested code blocks at compile time.
If we want to add support for macrocompiler then we can chose only
method one.
But method one except some small speed overhead has yet another drawback.
It needs to keep current code which uses additional HVM stack register
(lWithObject) to store offset of WITH OBJECT value. Such implementation
needs additional code to update lWithObject register at the beginning and
end of WITH OBJECT statement (additional speed overhead which can be
eliminated and reduces this feature to only single WITH OBJECT variable
and this is sth what I would like to eliminate in the future.
WITH OBJECT statement make only one thing. Semantically it introduces
temporary variables. Instead of:
LOCAL _tmp
[...]
_tmp := errorNew()
_tmp:cargo := "ABC"
? _tmp:cargo
_tmp := NIL
you can write:
WITH OBJECT errorNew()
:cargo := "ABC"
? :cargo
ENDWITH
In xHarbour implementation WITH OBJECT is visible for macrocompiler so
semantically it works like with _tmp declared as PRIVATE instead of LOCAL
variable.
As long as we operate only on local variables then we can easy extend
such functionality adding support for new variables and we can make
very extensive optimization at compile time calculating all HVM stack
offsets and eliminating lWithObject HVM stack register. If we add support
for accessing this value from macrocompiler then we lost such possibilities
so if you need such extenssion then you have to give me good reason to
implement it.
BTW Personally I'd even prefer to replace current WITH OBJECT by new
syntax, i.e.
WITH VAR <varname> [ := <value> ]
[...]
ENDWITH
because support for current
:<msg>
syntax breaks Clipper compatibility and it's necessary to introduce
hacks to PP code so some Clipper compatible code cannot be compiled by
Harbour and xHarbour. I.e. this code:
proc main
local xVar, get
@ 0, 0 SAY xVar PICTURE get:pict
return
cannot be compiled by xHarbour at all. It can be compiled by Harbour but
only due to hack which checks for leading spaces before ':' so this code:
proc main
local xVar, get
@ 0, 0 SAY xVar PICTURE get : pict
return
will not work too. Just simply like IN, HAS and LIKE xHarbour extensions
also WITH OBJECT breaks valid Clipper syntax in PP but in this case we
adopted xHarbour syntax for code compatibility and I'm still not sure it
was good idea.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
