Hi, >> My idea was to move all non-C52e function to >> "dialect" libs. Questions are: where to draw >> the line? (f.e. C53 may be better left in core), >> and how to name and where to place these "dialect" >> libs. > > IMO C53 has to be definitely in core. > I.e. CL52 RDD model is unfinished and disabling CL53 > compatible code is very serious limitation.
I agree. >> Probably it would be best to keep them in contrib >> area, and give them some distinctive lib prefix, >> f.e. 'hdxpp', 'hdxhb', 'hdfs', 'hdclip', 'hdfox'. > > It's not possible to give good support for above > extensions using only separated libraries. There are > things which has to be implemented as compiler or > preprocessor extensions. Some other things has to > be add to RDD code. I do not see any easy way to > separated DBF RDD and create 4 or 5 different RDDs > supporting only chosen subset of global functionality > without creating copy of existing code. > > I agree that it's good to keep most of functions in > separated libraries but we should not claim that its > the method of adding full compatibility layer for > other xbase dialects. It's not and never be. It's fine for me. So we don't declare "full" compatibility, but f.e. compatibility with some extended RTL features. To declare full compatibility, we would need 100% coverage of these extended features, which is not a realistic goal anyway, but at least we allow for the possibility. >> If we agree on the naming, placement and the fact >> that some .prg-level FlagShip, FoxPro stuff will >> move out from core. I'm ready to make the move. > > There is one very serious problem. > We do not have support for shared libraries in contrib > and some tools like HBRUN are linked only with core > libraries. For many people it's problem (they usually > ask about HBCT functionality which is default part of > Clipper for them) and we should try to resolve it first > (i.e. loading dynamically contrib shared libraries). > Now each function you moved from core to contrib is one > function less in HBRUN. This is a problem, but this it is a problem regardless of this specific decision as you also say. We'd need to use hbmk2 to build contribs, or develop .dll build for contribs using GNU Make system to solve this completely. > There are also extensions to existing functions. Now they > are enabled. When we move to separate libraries then we will > have to copy such functions replicating a lot of code just > to change few bytes or add some runtime emulation for current > compile time switches. > Both methods are possible only for functions which makes > some operations directly but for functions which depends > on some low level code like RDD it will not work some > extended functionality will still work. It means that As for RDDs, I'd leave it out from this, as we practically have no such problems at the moment, and RDDs are generally meant to interoperate, so there less change for such "rogue" extensions, we may find in other places. I'd leave it as it is. > only someone who check Harbour source code can guess > when he has to use copy of existing functions i.e. > XPP_TRANSFROM() because core TRANSFROM() does not give > the same results. And of course it will cause that > such functions cannot be used in index KEY or FOR > expressions when data is shared between programs compiled > by different languages. I haven't checked how big is such > problem, xbase++ seems to have quite big number of > extensions to Clipper in standard functions and we are > supporting only few of them but I was never xbase++ user > so I cannot help here much. As a general direction: We can't solve all the babel-tower effect caused by other Clipper implementations, and it's not even our goal. Our goal is to help resolve the situation as much as technically and sanely possible. This means we can give some place for compatibility functions, with a clear layout and instructions for those who want to use these non-CA-Clipper/non-Harbour features. BTW, if some of them is so important for us, we can pull it to core by using a fitting name for Harbour core (though usually we will give a better implementation). The real fun here is of course when existing functions are extended. This usually means the extension will collide with some other dialects. Luckily we don't have much of this issue in current core. For Xbase++ there is only 1-2 such places in core, one of them is TRANSFORM(). We can do a few things here: Delete the feature, include the feature in core unconditionally, or introduce <prefix>_TRANSFORM() alternate version. All of them has pros and cons, I like the third approach best. There is a fourth option: We can simply name it TRANSFORM() in xpp lib and let it override the core one, if linked that way. If we make it granular enough, it can work. Anyway, it'd be important to chose something, because current mess in this area is surely worse than anything which is clearly defined. And we delay the decision for many years now. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
