On Fri, 05 Jun 2009, Mindaugas Kavaliauskas wrote:
Hi,
> Clipper compatibility could be reached, even if we decide to drop []
> support for objects. o[1], o[2], ... could be emulated using [] operator
> overload even for an object with a different internal structure from
> Clipper.
I was thinking about code which may use some undocumented Clipper class
functions to create pseudo classes directly manipulating on arrays.
You can even find some _very_ basic class implementation for Clipper
written only as .prg code. Now such code also works in Harbour because
we are fully Clipper compatible. I haven't tried to analyze if we can
add emulation layer for such "manual" objects.
> In Clipper and Harbour HB_IT_ARRAY == HB_IT_OBJECT, so it will change ABI
> in some cases.
Yes, but it will also help in some cases though it will interact with
3-rd party code.
>> OOP implementation in Clipper, f.e. instead of:
>> o:var := 123.45
>> some can use:
>> o:_var( 123.45 )
>> etc.
>
> I see a different topic than "object as array" here. It's agreement on
> naming of assign methods. If we want to change this we will need add more
> pcodes to denote assignment. If assignment has a special pcode, perhaps
> object variable access should have a separate pcode also, i.e. o:var and
> o:var() should/can be a different things.
Yes, we will need different PCODES for o:var(), o:var and, o:var := <val>
We can also try to introduce 'context' byte to existing MESSAGE or SEND
PCODE which will inform VM about suggested by source code action (access,
assign or method call) but it will not be obligatory so if the preffered
action cannot be done VM will chose Clipper compatible action. It can be
even implemented without RT overhead. Just simply existing messages will
be aliases to Clipper compatible form when class is created. It can be
even control in .prg code.
> BTW, in Clipper we were forced to use &("o:_var(123.45)") in macros,
> because &("o:var := 123.45") gives Syntax error.
Yes, it is and it's the reason why it's not such seldom situation.
> P.S. Przemyslaw have You looked at GPF in extended HashObject() sample I've
> sent a few days ago? It not that I'd like to make you hurry, I just get
> lost a little in class implementation and was not able to fix this GPF.
I'll look at it and answer in a while.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
