Hi, > In general I think that we have to seriously rethink few things. > IMO unconditional using HB_* prefix and moving all functions which > haven't existed in Clipper to different contrib libraries begins > to be "art of the art" and in real life serious problem for users. > There are functions commonly used in different xbase dialects like > PVALUE() and now we shall have PVALUE() implementation inside > XHB, HBFSHIP, HBCLIP (BTW it's missing and some of functions covered > by XPP or FSHIP macros also belongs to CLIP), HBXPP and maybe few > others in the future. I tried but cannot imagine how it can help > users.
I proposed the idea of "dialects" about 3 years ago on this very list. Now, this could have made the solution a little more convenient for users, because it is in core, and this allows somewhat finer tuning of such non-Clipper features (f.e. we could have -dialect option in hbmk2). It also needs more work and more precise coordination when it comes to names and things. I saw zero feedback or reaction to the idea. Current solution solves the problem without introducing any such new concept into Harbour, IOW it's a plain standard solution. It may offer a _little bit_ less, than dedicated "dialect" solution, but it's also significantly simpler, which may even be a good thing for both devs and users. Anyhow it still allows to create dialect specific extensions in compiler, by using -k switches and so far I couldn't see any evidence that any f.e. Xbase++ functions cannot be solved in current layout. (worst case, we create an internal function in core, which is called by dialect lib). IOW: Current system doesn't add any technical limit on what functions can be added. As for PVALUE(): Can be added in separate source file to all of the dialect libs it applies as simple one-liner wrapper to HB_PVALUE(), and that's it. Or, we can simply document that it's implemented in one of them (f.e. the one that originally introduced this function, maybe it was FlagShip, maybe Xbase++). None of above is terrible for users. I think it's good to know which extensions an app source code actually uses. Without this solution, we would have to revisit the whole set of problem with _each and every_ extension to be added, discuss and argue (hopefully in advance), make a decision and possibly make corrections afterwards, and this is not good for anybody, it's slow, error prone. Now all "dialect" APIs can just be freely developed using some very simple rules. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
