On Thu, 06 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor, Mindaugas and others,
> What's natural for the array operator is not necessarily
> natural for a function call IMO. array operator has some
> properties we all know and expect for hashes too, just
> for arrays, but such thing don't exist for functions
> in general. This could be a differentiating feature between
> these two syntaxes, right now they are just duplicate syntax.
Probably some RT errors from function call should be eliminated
for flexible usage. I never though about this problem so far
and when I was adding hashes to harbour I simply replicated
most of RT errors which exists in xHarbour.
> 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.
You've just accepted autoadd in assign because you have quite nice
example of these feature used for i18n translation tables and so
far you haven't created any code which can benefit from autoadd
in access and you still think about hash items like like about some
type of static storage.
This feature is usable when hash is used as backed to collect some
results.
F.e. I want to collect information about quantity of articles sold:
hReport := { => }
hb_hDefault( hReport, 0 )
hb_hSetAutoAdd( hReport, .t. )
dbGoTop()
while !eof()
hReport[ FIELD->ARTICLE ] += FIELD->QUANTITY
dbSkip()
enddo
for each v in hReport
? v:__enumIndex(), v:__enumKey(), v
next
It's possible to use complex items as default value too and this
complex item is _cloned_ when used as each new hash item value.
F.e. I want to create sales report with article code, quantity and
value grouped by articule code.
hReport := { => }
hb_hDefault( hReport, { 0, 0 } )
dbGoTop()
while !eof()
aRec := hReport[ FIELD->ARTICLE ]
aRec[ 1 ] += FIELD->QUANTITY
aRec[ 1 ] += FIELD->QUANTITY * FIELD->PRICE
dbSkip()
enddo
for each aRec in hReport
? aRec:__enumIndex(), aRec:__enumKey(), aRec[1], aRec[2]
next
> For me autoadd on assign is normal, the rest is just another
> way to make language semantics difficult to follow/ambiguous
> and programs almost impossible to read.
In the usage like for i18n string translation or as some type of
strage for known elements then yes.
But it's not the only one situations when hashes are usable.
When hash item is used for translations like in i18n then it's
usable to have the feature which alows to return key when key
does not exists in the hash array. F.e. In the 1-st report above
I may want to group some type of articles together and rest
present individually. With this feature it's enough to change
the line with:
hReport[ FIELD->ARTICLE ] += FIELD->QUANTITY
to:
hReport[ hGroups[ FIELD->ARTICLE ] ] += FIELD->QUANTITY
but I can also use:
hReport[ hb_hKey( hGroups, FIELD->ARTICLE ) ] += FIELD->QUANTITY
Instead of adding new attribute to hashes.
> 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.
It cannot because NIL is also valid hash item value so it will
not be usable in all cases. But of course it does not mean that
we cannot remove RT error from hb_hGet() and document it as expected
behavior. If someone prefers functions call instead of faster h[key]
then probably he has some special reasons for this. One of such reason
can be missing RT error.
> I think that's not the question, but rather if we want to
> keep the RTE in hb_HGet() at all.
Exactly.
> xhb compatibility is not a concern BTW, because it uses
> different function names anyway.
Because you asked to translate most of them. At the beginning
this implementation was using xHarbour compatible API. Anyhow
I do not think we have to be strictly compatible with RTE in
such functions.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
