On Wed, 04 Feb 2009, Szak�ts Viktor wrote:
> The problem is that Xbase++ has a public symbol named GET(), while plain
> Clipper doesn't. If XPP compatibility is turned on, we
> should provide GET(), if it isn't, we shouldn't.
For me much more important is basic Clipper compatibility and here
we touch sth what may break pure CL5.2 code which does not even use
any external OOP system.
The problem with repeating xbasee++ class function names is much
bigger and apeears in other places. I'm not xbase++ user so I cannot
say how it exactly works. For me the realtions between class and
class function names are not clear. I also do not know how it effects
static classes or even if xbase++ supports them.
Looking at examples send here seems that xbase++ supports Class(y)
like class objects and class functions returns such objects which
needs :new() method to create given class instance.
Maybe xbase++ users can say sth more.
> I intentionally didn't replace Get():New() with GetNew(), to not
> add an unnecessary layer of function call here. [ if there is no
> other choice we can do this. ]
This does not cause any noticeable speed overhead.
Using HbGet():new() also bound current implementation of Get[:]New()
with upper level code what is not good idea and makes customization
by user much harder. Instead of overloading single public function
known also from Clipper user have to replicate Harbour class model
in his code.
To reduce speed overhead (if you think it's such important) you can
use '...' as parameters. It reduce number of PCODEs which have to be
evaluated:
FUNCTION GetNew( ... )
RETURN HBGet():New( ... )
or if you think that speed is critical here then you can also write
GetNew() in C and it will be even faster a little bit then hbGet():new()
but all these modifications will not make any noticeable speed difference
in final code which have to make few other much more expensive things.
> Can't we somehow override the value returned by :classname?
We can but such hacks introduce many other problems, f.e. with
serializations or for object inspectors. In core code the class
is register as "ABC" but user see it as "XYZ".
In such case I'd prefer to return to old code. The problem with
public GET() function seems to be minimal in comparison to the
ones created by forcing HB* prefix here.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour