Re: [xHarbour-developers] Strange compiler behavior using dot

2009-11-27 Thread Enrico Maria Giordano

-Messaggio Originale- 
Da: Luiz Rafael Culik Guimaraes l...@xharbour.com.br
A: Enrico Maria Giordano e.m.giord...@emagsoftware.it; xHarbour 
Developers Mailing List xharbour-developers@lists.sourceforge.net
Data invio: venerdì 27 novembre 2009 0.35
Oggetto: Re: [xHarbour-developers] Strange compiler behavior using dot


 Enrico

 not for xharbour, since . is the name space operator

Ok, thank you.

EMG

--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic 


--
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-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers


Re: [xHarbour-developers] RDD: ADT - ADSADT

2009-11-27 Thread bhays
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-developers@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: