On Thu, 25 Feb 2010, Lorenzo Fiorini wrote: Hi,
> For me is extremely important, because it makes next Harbour useless for me. In this particular case I do not see any reason that we have to remove such functionality. For me -kl compiler switch is quite nice solution which should not be covered by HB_LEGACY_LEVEL3 macro and marked to removed in the future. Anyhow if we do not want to officially support it then I think that recent modifications should be reverted and old compile time macro restored. I can understand that we are removing some code/functionality when we have very serious reasons for it, i.e. extension has some bad side effects, it's hard to update/keep alive and consumes too much developer time or blocks some other much more important modifications. In such case we can only say sorry and try to explain the reasons of our decision. It's not good and to eliminate such situations all core modifications have to be really well thought. Anyhow in this case it's small local modifications which does not interact with any other code so it does not creates real problems. 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. Tonight I read XBASE++ documentation. They created interesting set of db*() functions. It looks like quite well thought solution. For a while I thought about creating something like for Harbour but when I imagined the mixed set of new HB_*() which I will have to create with original Clipper ones then I drop this idea. Each time I see: ISNUMBER() and HB_ISPOINTER() I think how we can explain above naming convention for users who never used Clipper and for sure do not plan to learn all it's functions and macros. Keeping the namespace clean is very important and for sure I'm the last person who will vote to remove HB_ prefix from most of core functions. Anyhow IMO over some reasonable limit adding HB_ prefix to each identifier which was not used in Clipper we begin to create Clipper museum instead of modern language. Fortunately we have SWITCH and FOR EACH statements instead of HB_SWITCH and HB_FOR EACH ;-) best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
