to Ron and Patrick: about single char strings as num value
Patrice
Until now, I have been able to deal with every extension I encontered
because either the extend was logical (long file name support), or there was an
alternative syntax which stick to original behavior, or it was possible to
disable the feature, or it was something new with a new syntax.
The feature of allowing A= 1+ "A" is just a typing facility to the
programmer to save keys and avoid typing A= 1+ asc("A").
What a benefit ! and at cost of breaking the language behavior.
Set Flaming mode on
IMOO, using a single char string as a numeric value is a bad thing in a
loozy typed language like xHarbour.
In a strongly typed language like C, this usage is OK because:
- it is strongly typed.
- the compiler ensure that you pass the right type of parameters to a function.
- string is not a first class citizen.
- every native type of data is numeric in nature, so casting is mainly to deal
with diff sizes of numeric data.
In a loozy language like Xharbour, it is just a typing facility for the
programmer at cost of breaking the language behavior.
Set Flaming mode off
This kind of feature would be OK for me if you were using a special type
of data (char type) with an extended syntax to remove confusion with strings and
not break the normal behavior.
At least the possibility to disable the feature would be OK for me.
Patrice
Ron Pinkas
This feature is not at all about saving typing. If you would have taken the
time to review the sample you would have learned that this provide very
efficient support for encoding/decoding compressing/uncompressing and many
other arithmetic based text processing.
IAE, this feature has been used for the last 8 years, and it will not be
removed.
If you absolutely wish to disable this feature then you can link a modified
version of:
hb_itemGetN*()
Simply replacing:
case HB_IT_STRING:
if( pItem->item.asString.length == 1 )
{
return ( ... ) ( BYTE ) pItem->item.asString.value[0];
}
With:
case HB_IT_STRING:
hb_errRT_BASE( EG_ARG, 1603, NULL, "Non numeric", 1, pItem );
Ron
"Patrice" <fa...@home.fr> wrote in message
news:87s2p5h12rgi7du5q...@4ax.com...
Budyanto Dj.
If it is that easy, maybe it is better to provide an option to disable
this feature?
Some users do not like this feature at all, and they have no (practical)
way to disable this feature. Some others are not aware of such feature
and got an unpleasant surprise in his application.
What's so bad in providing a way to disable it?
regards,
budyanto
dlzc
On Mar 5, 5:56 pm, "Budyanto Dj." <budyantonore...@csacomputer.com>
wrote:
> Hi Ron,
>
> If it is that easy, maybe it is better to provide
> an option to disable this feature?
>
> Some users do not like this feature at all, and
> they have no (practical) way to disable this
> feature. Some others are not aware of such feature
> and got an unpleasant surprise in his application.
>
> What's so bad in providing a way to disable it?
Don't you realize that it is not up to the xharbour group to decide
what Harbour has in it? "hb_itemGetN*() " is not sourced with
xharbour. We didn't put it in, it is (I believe) extensively used in
the core of the language, and will be no less problematic than whether
or not inkey returns extended key codes (for example).
If you want a strongly typed language, xBase is not the choice you
should be making. Power comes not from making more ways to develop
errors. "2" =/= 2 is the true value that was returned. This is
correct. The error was placing a character in a variable the
programmer *guessed* was a numeric later, and did not bother to apply
Hungarian notation to help clarify it.
Just my two cents, and I don't expect anyone to be impressed by them.
David A. Smith
dlzc
On Mar 5, 6:36 pm, dlzc <dl...@cox.net> wrote:
...
> Don't you realize that it is not up to the xharbour
> group to decide what Harbour has in it?
> "hb_itemGetN*() " is not sourced with xharbour.
I have been straightened out via email. "hb_*" means squat,
apparently. Doesn't mean it is sourced at Harbour, not even sure
"hb_*" says anything meaningful.
Sorry about my assumptions, and any confusion they might raise.
David A. Smith
Budyanto Dj.
I don't want to argue about whether this feature is good or bad, for
this will lead to an endless discussion :-).
I simply said that if we have a choice to use or to not use this
feature, it will be better. And Ron seems to have an "easy" fix to
achieve that.
For the case of extended key codes, we do have an option to not use it
by undefining HB_EXT_INKEY when building xHarbour.
We cannot do the same with the feature in question here.
regards,
bdj
dlzc wrote:
> [snipped]
modalsist
hbsetup.ch
---------------
#ifdef HB_EXTENSION
#define HB_EXT_INKEY /* Enable extended Inkey codes */
#define HB_EXT_NUMERIC /* Enable extended numeric type */
#endif
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
regards,
Eduardo
On 6 mar, 03:55, "Budyanto Dj." <budyantonore...@csacomputer.com>
wrote:
Ron Pinkas
> If it is that easy, maybe it is better to provide an option to disable
> this feature?
Personally I'm against all those settings that make it impossible to
establish a clear language standard. AS-IS xHarbour already has too many
build options (most where inherited from Harbour), and I'd personally like
to remove all such obstacles to a clear standard, when ever possible. Yet, I
do NOT object to disabling any such extension under the control of
HB_C52_STRICT. You are welcome to contribute that option if you are
interested.
Ron
dlzc
On Mar 5, 11:55 pm, "Budyanto Dj." <budyantonore...@csacomputer.com>
wrote:
> David,
>
> I don't want to argue about whether this feature is
> good or bad, for this will lead to an endless discussion :-).
They are only opinions, which were sought.
> I simply said that if we have a choice to use or to
> not use this feature, it will be better. And Ron
> seems to have an "easy" fix to achieve that.
>
> For the case of extended key codes, we do have an
> option to not use it by undefining HB_EXT_INKEY
> when building xHarbour.
>
> We cannot do the same with the feature in question here.
My only gripe is in yet another undocumented / poorly-documented
"splice" to this "grandmother's quilt" of a language.
David A. Smith
Budyanto Dj.
It looks elegant, I hope the OP can use this approach.
Too bad it can't make it to the CVS.
regards,
budyanto