Hi Lorenzo,
Why gtwvw moved to hbgtwvw and back to gtwvw?
Because Przemek raised the problem with lib names under DJGPP, where 8.3 names has to be used because it's DOS, and 'lib' is prepended by DJGPP, hence only 5 chars remain to identify a given lib. If we were using 'hb' prefix too for RDDs and GTs, we would simple create identical filenames under these situations. This new rule came up after the contribs were already renamed, that's why I had to adjust these to comply. I don't love this restriction, but if we say we support DJGPP, we need to take care of that. hbcpage and hbcplr where also compromises taken because of this rule (plus some consideration for easier text searching, that's why I dropped 'hbc').
Because gt libs are "drivers" exactly like dbfcdx. What I mean is that rtl lib is never referenced in the code while dbfcdx need a REQUEST and a RddSetDefault so DBFCDX name will never die and adding rddcdx will not make things more clear.
I'm still not sure what you mean. REQUEST DBFCDX _does_ remain, as DBFCDX here refers to a symbol inside the lib, not the name of lib. While using DBFCDX for the lib name might save 1 minute of initial setup for every new developer coming to Harbour, it has the drawback that it's colliding with CA-Cl*pper's similarly named lib. Aside from that, I feel that giving 'rdd' prefix to all RDDs is much cleaner than naming them almost randomly (ADSRDD, BMCDX, DBF*, etc), because it's apparent at first glimpse which Harbour RDDs are available in list of libs (when sorted by name of course). Lastly, - and I can just repeat myself - an "RDD lib" may contain several RDD names inside, which, many times are not equal to the lib name anyway: rddads: ADS rddcdx: DBFCDX, SIXCDX rddfpt: DBFFPT, DBFBLOB So we're not creating a new set of problem with these new names. Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
