On Thu, 25 Sep 2008, Pritpal Bedi wrote: Hi Pritpal,
> Pritpal, > why should I as a Xbase++ developer help a competitor to advance its > product??? > And why do you ask for our help in the Xbase++ generic newsgroup? In my > eyes this is trolling. This has nothing to do with Xbase++. > Maybe you should visit the thread started by Massimo in the soapbox > newsgroup. This will help you to understand how Xbase++ developers think > about this. > Maybe in future times I and others should start some interesting threads > in the Harbour groups about the great new enhancements within Xbase++? > Lets see how other harbour developers react to this! I'm not surprised with such answer. xbase++ is commercial project so it's rather expected. BTW I like that they clearly said what they think about it. Personally I like some xbase++ ideas you presented here but I'm not interested in any implementation details. Also so far I haven't seen anything what I is new for me and what I wasn't plan to implement though with different names or with some a little bit different conditions. And I do not have any knowledge about xbase++ so I do not agree that you said that we are following xbase++ model. Some of their solutions are natural and probably anyone who think about it longer will end with sth similar. F.e. I was thinking about moving workareas between threads. When you send information about dbRelease()/dbRequest() I found it as nice API for such solution and I added it quite fast. But the internal implementation is for sure different then the one in xbase++. We do not have any zero zone but simple array item which holds areas. It's the result of my original idea when I wanted to add code to move workarea into variable which can be moved between threads and then attached to thread local WA list. I decided to use xbase++ compatible .prg interface only for one reason. In the example you sent is nicely visible that it will work with only one thread two and also with some modifications with many worker threads which are waiting for jobs from other threads. It was a little bit like in LINDA and I already found it nice :-) I do not need any think more. The only one think which can be usable is making some tests of real xbase++ behavior if you expect I'll create some compatible .prg level interface. F.e. what happens with relations and lock in dbRealese(). I have to take some arbitrary decisions like removing all relations (and I cannot change it because it will break WA separation) and removing all locks what I can change if you will find it as necessary for xBase++ compatibility though I do not like this idea very much. As you can read in other thread I also do not like documented xBase++ PUBLIC behavior and I'm finding current Harbour solution as better and I would like to keep it. In xbase++ documentation you sent I do not find anything about dangerous situations and possible bad side effects. Only small information that programmer should eliminate some situations (f.e. simultaneous write access) with some trivial examples. I can only guess that they do not want to write about real low level problems because it's commercial project and they do not want to lost customers informing that application may cause GPF. But I think that real xBase++ user well know what can happen in some cases and many times saw GPF. Even such small thing will be problem in serious conversation in public forum. And the final thing. All code I'm creating for [x]Harbour it based on my own ideas and low level implementations. I do not want to create even potential owner rights problems. Closer cooperation with commercial clipper compatible compiler authors may cause sth like that so I'm not interesting in it. I hope that I also clearly presented my point of view. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
