Przemyslaw Czerpak-2 wrote: > >> You request workareas from the zero workspace by alias which IMO is a >> weakness in the design. Rather than having alias naming collisions, the >> zero workspace FIFO's the workareas such that duplicate aliases are >> retrieved in the order they were submitted. > > Here I do not agree because it gives very nice API for sharing databases > between threads... >
My goal in this thread is not agreement or disagreement. FWIW, I could care less about sharing workareas (or using GLOBALS/PRIVATES) between threads as it is a facility I would never use. And you are right, I disagree with the alias name and FIFO design, but it is the current implementation of Xbase++. My goal is to maximize the source code compatibility of the two compilers. If an Xbase++ api can be adopted or emulated in Harbour with compatibility and you agree with the api, then by all means make compatibility. Those apis that don't make sense or you don't want to implement can be addressed by using the preprocessor to issue a warning or error so that issues with source code ported from Xbase++ can be quickly identified and resolved. Obviously, the worst thing to do would be to adopt the api naming with an alternate behavour. I am know wondering if it would be a good idea to add a optional DIALECT statement/define/pragma at the top .PRG source code to indicate flavor to the compiler in much the same way you add a <!DOCTYPE to the top of an HTML document to indicate its flavor. Just a thought. Przemyslaw Czerpak-2 wrote: > > I guess xbase++ can have more WorkSpace*() functions. Before I'll begin > to add them I would like to see the list. > WorkSpaceList() and WorkSpaceEval() is the entire list. In fact WorkSpaceEval() is nothing more than aeval(WorkSpaceList(),codeblock). DB_ZEROSPACE and DB_WORKSPACE are the only documented constants with values of 2 and 1 respectively. DB_WORKSPACE is the default. So long as the primitives exist to emulate these functions, I think that implementing the Xbase++ compatibility functions (while trivial) is best left to the parties that are interested in porting code from Xbase++. Hopefully they would do this in an Xbase++ compatibility library that is shared as part of the Harbour project. I essentially had to do this same thing when porting from Clipper to Xbase++ which I shared on the Xbase++ NG. No sense burning your time implementing things unless they are valuable to the Harbour community as a whole. Przemyslaw Czerpak-2 wrote: > >> The associated code block is attached to the workarea that was explicity >> dbRelease()d to the zero workspace. It is not shared with child >> workareas. >> AFAIK, the code block can only be set by the dbRelease() and is >> permanently >> associated until replaced via another dbRelease(). > > Rather pair: dbRequest() and dbRelease() :-) > The codeblock is just a workarea attribute set at dbRelease(). I find no other documented way to write the value, but the value can be read at any time using dbJob() which takes no parameters and returns the value of the current workarea. I am not even sure if or why the value is limited to codeblock type since it is never documented to be evaled. Regards, Rodd Graham -- View this message in context: http://www.nabble.com/A-few-questions-about-MT-tp19555409p19698574.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
