Hm, I find this extremely unnatural and even dangerous. In fact
I didn't understand the whole fuss about "autoadd" when lengthy
discussion were going on. Now I know what it was all about.
For me it'd be the last thing I want that my hash table
automatically extends with new members _on access_. Maybe this
is normal for other languages, I don't know.
Sometimes this autoadd is very useful:
DBEVAL({|| hHash[ FIELD->CODE ] += FIELD->AMOUNT })
Good example, thanks for it. BTW I don't want to dig
deeper in this issue, as the point is i18n, I assume
hashing is good and useful as it it, even if I find
some points confusing at first.
Moreover you need a distinct function just to check the
existence of a key. Ideally hb_HGet( h, k ) != NIL could do
this, and with the third parameter, this would be even better,
doing what you and probably most developers would expect.
No! HB_HGET( h, k ) == NIL, if hash HAS key k associated to value NIL.
Okay, this point is also cleared then.
I think that's not the question, but rather if we want to
keep the RTE in hb_HGet() at all.
I want to keep RTE.
And for the above reason it's even necessary.
xhb compatibility is not a concern BTW, because it uses
different function names anyway.
I do not know any xhb compatibility issues about hashes. It was
written by Przemek from scratch, and all xhb compatibility (like
hHash:method support) is in xhb.lib.
I see, but some stuff got into it - obviously
not the above -, and I hope those can still be
cleaned (all discussed in other thread).
For sure, Harbour's hash implementation details looks very messy
to me. Management of some xhb heritage is a real burden :(
(see also hb_AIns()/hb_ADel(), logging, .ini files, ...)
Yes, I remember all discussion about Clipper functions extension.
Finally, I do not use HB_AINS()/HB_ADEL(), but use AINSS(), ADELS()
which always adjust size of array (the last letter "S" of function
name is abbrv. of "Size") and does not need the third
parameter .T./.F. .
But not everything is xhb heritage. For example, yesterday my friend
asked: do we have a function like RAT() with parameter nStartFrom. I
do not know if xharbour has such extension, but it is much easier to
do string parsing by passing nStartFrom instead of using LEFT() and
modifying the string by cutting-off at the last separator in each
loop. Harbour could not have such function by accepted "Clipper
compatibility rules", or it will by one more Clipper function clone-
extension like HB_RAT().
Yes, a very important difference IMO. The question most of
the time isn't about the feature itself, but the way it's
implemented.
I pretty much like that I exactly know which function calls
are coming from Harbour at a spot, and this doesn't slow me
down a bit, and I can use just as much extensions as xhb, if
I'd like to.
BTW, we could add HB_RAT(), we already have HB_AT().
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
