I do not object to fixing HB_C52_STRICT functionality, as long as the 
extended functionality is NOT affected and remains the default.

Another choice is an optional new library which could be built from existing 
RTL sources, compiled with HB_C52_STRICT into a new alternate RTLCL52.lib 
and such lib could be linked instead of RTL.lib (by those interested), 
withOUT removing all extended features. IOW only Clipper RTL functions would 
be reduced to strict compatability.

Ron

--------------------------------------------------
From: "Eduardo Fernandes" <modals...@yahoo.com.br>
Sent: Saturday, November 07, 2009 7:17 AM
To: "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>; 
"Ron Pinkas" <ron.pin...@xharbour.com>
Subject: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.

>
> I don't be able to compile xharbour using HB_C52_STRICT. I got an error on 
> achoice.prg and hbclass.ch by HB_SHORTNAMES is disable. After enable 
> HB_SHORTNAMES with HB_C52_STRICT enabled, then other error occurs. It 
> seems HB_C52_STRICT is broken.
>
> Eduardo
>
> --- Em sáb, 7/11/09, Ron Pinkas <ron.pin...@xharbour.com> escreveu:
>
>> De: Ron Pinkas <ron.pin...@xharbour.com>
>> Assunto: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.
>> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>, "Xharbour-Developers 
>> List" <xharbour-developers@lists.sourceforge.net>
>> Data: Sábado, 7 de Novembro de 2009, 11:29
>> This feature is already disabled if
>> you compile xHarbour with HB_C52_STRICT. Your proposal can
>> NOT be implemented withOUT breaking existing code, because
>> these String Functions must accept CHAR type to support
>> existing code. The feature is documented in xdiff.txt.
>>
>> --------------------------------------------------
>> From: "Eduardo Fernandes" <modals...@yahoo.com.br>
>> Sent: Saturday, November 07, 2009 1:56 AM
>> To: "Xharbour-Developers List" 
>> <xharbour-developers@lists.sourceforge.net>;
>> "Ron Pinkas" <ron.pin...@xharbour.com>
>> Subject: Re: [xHarbour-developers] Proposal for
>> HB_IS_NUMERIC.
>>
>> > Ron,
>> >
>> > I don't want remove this feature or break existing
>> code. I would like this feature doesn't change the expected
>> return values on any string functions.
>> >
>> > The question is: There is a way to separate this
>> feature without remove it or break existing code, and at
>> same time, maintain Clipper compatibility ?
>> >
>> > Maybe a #define HB_EXT_NUMERIC on hbapi.h.
>> >
>> > #ifdef HB_EXT_NUMERIC
>> > #define HB_IS_NUMERIC( p )    (
>> HB_IS_NUMBER( p ) || HB_IS_DATE(p) || ( HB_IS_STRING(p)
>> && (p)->item.asString.length == 1 ) )
>> > #else
>> > #define HB_IS_NUMERIC( p )    (
>> HB_IS_NUMBER( p ) || HB_IS_DATE(p) )
>> > #endif
>> >
>> >
>> > 1) Where this feature is documented ?
>> > 2) If I adopt this, what the impact into xharbour core
>> ?
>> >
>> > regards,
>> > Eduardo
>> >
>> > --- Em sex, 6/11/09, Ron Pinkas <ron.pin...@xharbour.com>
>> escreveu:
>> >
>> >> De: Ron Pinkas <ron.pin...@xharbour.com>
>> >> Assunto: Re: [xHarbour-developers] Proposal for
>> HB_IS_NUMERIC.
>> >> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>,
>> "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>
>> >> Data: Sexta-feira, 6 de Novembro de 2009, 9:25
>> >> Eduardo,
>> >>
>> >> What makes no sense to a programmer can be IGNORED
>> by THAT
>> >> programmer. Using a char value as numeric makes
>> LOTs of
>> >> sense to many, especially those that programs with
>> other
>> >> languages. Either way this is a documented feature
>> which has
>> >> been available for many years. Therefore we can't
>> simply
>> >> remove it and break existing code.
>> >>
>> >> Ron
>> >>
>> >> F.E. simple encoding
>> >>
>> >> sString   := "Hello"
>> >> sCoded := ""
>> >>
>> >> FOR EACH cChar IN sString
>> >>   sCoded += Str( cChar, 3 )
>> >> NEXT
>> >>
>> >> Ron
>> >>
>> >>
>> --------------------------------------------------
>> >> From: "Eduardo Fernandes" <modals...@yahoo.com.br>
>> >> Sent: Thursday, November 05, 2009 5:56 PM
>> >> To: "Xharbour-Developers List" 
>> >> <xharbour-developers@lists.sourceforge.net>;
>> >> "Ron Pinkas" <ron.pin...@xharbour.com>
>> >> Subject: Re: [xHarbour-developers] Proposal for
>> >> HB_IS_NUMERIC.
>> >>
>> >> > Ron,
>> >> >
>> >> > I'm curious about what intention on
>> application with
>> >> these results:
>> >> >
>> >> > str('a',10,2) -> '
>>    97.00'
>> >> > strzero('b',10) -> '0000000098'
>> >> > padl("9","*",10) -> 42 spaces + "9"
>> >> > padr("9","*",10) -> "9" + 42 spaces
>> >> > padc("9","*",10) -> 20 spaces + "9" + 21
>> spaces
>> >> >
>> >> > IMO, this can cause damage on the expected
>> results,
>> >> mainly from Clipper legacy applications.
>> >> >
>> >> > I still think more prudent to separate this
>> *feature*
>> >> in HB_IS_NUMERIC_EXT and use it only on specific
>> issues.
>> >> >
>> >> > Please, consider it.
>> >> >
>> >> > Eduardo
>> >> >
>> >> > --- Em qui, 5/11/09, Ron Pinkas <ron.pin...@xharbour.com>
>> >> escreveu:
>> >> >
>> >> >> De: Ron Pinkas <ron.pin...@xharbour.com>
>> >> >> Assunto: Re: [xHarbour-developers]
>> Proposal for
>> >> HB_IS_NUMERIC.
>> >> >> Para: "Eduardo Fernandes" <modals...@yahoo.com.br>,
>> >> "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>
>> >> >> Data: Quinta-feira, 5 de Novembro de
>> 2009, 17:48
>> >> >> Eduardo,
>> >> >>
>> >> >> > So, we could review all string
>> functions like
>> >> str(),
>> >> >> strzero(), pad(), etc, that call
>> HB_IS_NUMERIC(),
>> >> >> HB_IT_NUMERIC or ISNUM() to maintain, at
>> least,
>> >> expected
>> >> >> results or run time error, if any
>> argument is
>> >> inverted or
>> >> >> with any data type changed.
>> >> >> >
>> >> >> > f.e.:
>> >> >> >
>> >> >> > ? str("a",10,2)
>> >> >> > ? strzero("b",10)
>> >> >> > ? padl("9","*",10)
>> >> >> > ? padr("9","*",10)
>> >> >> > ? padc("9","*",10)
>> >> >>
>> >> >> Please note that it is absolutely VALID
>> CODE to
>> >> pass a
>> >> >> single char as a NUMERIC value. I have
>> lot's of
>> >> such code
>> >> >> intentionally. It would therefore be
>> wrong to
>> >> break a
>> >> >> documented feature which has been working
>> for
>> >> years.
>> >> >>
>> >> >> Ron
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> ____________________________________________________________________________________
>> >> > Veja quais são os assuntos do momento no
>> Yahoo!
>> >> +Buscados
>> >> > http://br.maisbuscados.yahoo.com
>> >> >
>> >>
>> >
>> >
>> >
>> >
>> ____________________________________________________________________________________
>> > Veja quais são os assuntos do momento no Yahoo!
>> +Buscados
>> > http://br.maisbuscados.yahoo.com
>> >
>>
>
>
> 
> ____________________________________________________________________________________
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
> 

------------------------------------------------------------------------------
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

Reply via email to