> > 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 don't know either, anyhow the functionality was there already so I didn't want to remove it now. > 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. Okay, I'll do these, it will be cleaner for sure. The "..." trick tip is nice. > > 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. The problem is that we need (at least we already had) GET() for Xbase++ compatibility. Exact same problems we have with TBrowse() and TBColumn(), which aren't Clipper public symbols. Since Xbase++ is less important, how about naming the XPP compatible (or so intended) extended classes xpp_GET(), xpp_TBrowse(), xpp_TBColum()? This way we could make GET/TBROWSE/TBCOLUM class symbols STATIC. How about this? Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
