We can deprecate it just like we do with some other features (HB_LEGACY_LEVEL2 f.e., or LEVEL3), which means it will be dropped in a future version.
Brgds, Viktor On 2009 Nov 27, at 10:14, bhays wrote: > Przemek and Mindaugas: > > Thanks for the clarification. I missed the finer point when Mindaugas > first discussed "ADS", but then the second paragraph said > "I propose to rename RDD from ADT ..." > as you noticed, I thought we were still talking about just "ADS". > > So, yes, I would agree ADSADT is better than also supporting "ADT". > It might be good to find out how many people might be impacted, > but if it's just a question of changing the rddSetDefault line, > and if an obvious error is generated after the change that makes > it clear what the programmer should fix if he missed the change, > then it sounds like a good fix. > > As for the additional idea of removing "ADS" and: >> so in fact you had over four years to update your code.... >> Was it my mistake that I left "ADS" RDD? > > I never really thought that being "left for backward compatibility" > implied a suggestion for changing code. > For me personally, just changing the rddSetDefault line is no problem. > BUT I wouldn't recommend breaking users' apps if the only reason is > to remove the backwards compatibility for cleanliness sake. > Though I go back that many years, thousands of new users may very > well have used that syntax up to present day, especially in light > of the lack of significant documentation for rddads. > Have new users been directed to examples or guidelines that suggest > the newer syntax and *not* using "ADS"? > > One more point: to "reduce" the ADS RDDs to *just* the specific rdds > MAY imply the temptation to remove the ability to just set the FileType > from one to the other (e.g. from ADT to DBF and back again) in the same > workarea. If this is where we're headed, it would break a LOT of > people's code and probably create a lot of grief for people who just > get a Harbour update, then suddenly find themselves having to debug and > fixup potentially large amounts of code. > I'm not arguing for clinging to bad design, but concern for our users' > sanity is a virtue. > > Thanks for all your work, > > -- > Brian Hays > > >> -----Original Message----- >> From: Przemysław Czerpak [mailto:dru...@acn.waw.pl] >> Sent: Thursday, November 26, 2009 8:16 PM >> To: Xharbour-Developers List; Harbour Project Main Developer List. >> Subject: Re: [xHarbour-developers] RDD: ADT -> ADSADT >> >> On Thu, 26 Nov 2009, Brian Hays wrote: >> >> Hi Brian, >> >>> The addition of specific "sub-rdds" of ADSCDX etc. came years later. >>> I, and I imagine a lot of other people who started using rddads >>> early on, never had a need to explicitly use those other rdds by >> name. >> >> Any one who has code like: >> >> proc copy_table( cSrc, cSrcRDD, cDst, cDstRDD ) >> use (cSrc) via (cSrcRDD) >> copy to (cDst) via (cDstRDD) >> return >> >> designed to work with different RDDs in Clipper, needs ADS* RDDs to >> port >> his code without introducing unnecessary and incompatible with other >> RDDs >> modifications which are necessary to make working code like: >> copy_table( "sales", "ADSCDX", "sales2", "ADSADT" ) >> >> In fact "ADS" RDD can be safely removed because the only one reason >> to keep it are user habbits but ADS* RDDs cannot be removed without >> reducing important functionality - working VIA clause in different >> command/functions which allows to easy switch between RDDs. >> >>> Are you suggesting that we should now have to re-write our apps by >>> converting ADS to ADSADT? But wait: IIRC (I'm not sure), >>> ADSCDX is the DEFAULT for ADS, so converting it to ADT doesn't >>> really make sense, does it? >>> If you're suggesting a change that would require people to change >>> code that's been growing for 9 years, there needs to be a stronger >>> reason to force the change than just compatibility with other rdds, >>> IMHO. >>> Or am I missing something? >> >> Mindaugas wants to change only "ADT" RDD to "ADSADT" and you are not >> using it so it's not a problem for you. >> Anyhow you wrote that it's 9 years code. >> In the past I left "ADS" RDD only for backward compatibility: >> >> 2005-09-02 20:10 UTC+0200 Przemyslaw Czerpak >> (druzus/at/priv.onet.pl) >> + register ADS as three separate RDDs: ADSNTX, ADSCDX, ADT >> (ADS RDD left for backward compatibility) - they do not >> need to set table type. >> >> so in fact you had over four years to update your code. >> This suggests that forcing some modification immediately is better >> because four years ago it was only 5 years code ;-) >> Was it my mistake that I left "ADS" RDD? >> >> best regards, >> Przemek >> >> ----------------------------------------------------------------------- >> ------- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> xHarbour-developers mailing list >> xharbour-develop...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xharbour-developers >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.426 / Virus Database: 270.14.67/2506 - Release Date: >> 11/26/09 09:10:00 > > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
