On Mon, 15 Feb 2010, Szak�ts Viktor wrote: 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. > 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. > 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. 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 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. BTW Maurilio you were asking about some compatibility problem with TTHREAD class. If you know xbase++ then please update this code. Not everything can be emulated i.e. Harbour (just like Clipper) does not use different messages to access instance variables and to execute methods so you cannot implement atEnd() method and have atEnd() variable but there are many other things which should be added to this class yet. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
