I can't see why adding -lhbxpp poses a serious limitation for users. For me it's rather interesting to see that we maintain any feature in central SVN which bends basic functionality for the sake of ONE user. It's well known since years, that it's a non supported feature. Same with hbmk, I'm keeping it just for the sake of Lorenzo (yet). It simply blocks the path forward, and this is unacceptable IMO. The code is free, so if someone tries to keep strange (or non-strange) local features, it can and should be done locally. They need special build anyway, and it's not about "I won't update the SVN anymore".
Brgds, Viktor On 2010 Feb 25, at 09:30, Przemysław Czerpak wrote: > 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 _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
