στις 13/03/2010 12:52, O/H Viktor Szakáts έγραψε:
And here you answered the question. ADEL() is a Clipper
compatibility function, so it's expected to behave exactly
the same way as in Clipper, regardless of what we think
about some of that behavior.
Hi Viktor,
Thanks you for your reply. I don't like to be pedantic but,
as I understand it, the term "compatibility" is the case where the
compatible object keeps the same *documented* behavior and produce the
same *expected* results like the original. Preserving or rather
"cloning" undocumented questionable/problematic "features", just for the
sake of compatibility, is a bit surrealistic, which is ok on a
philosophical/aesthetic level but from a pure programming view,
perhaps needs more consideration.
I agree that adel() does some kind of delete in the meaning that deletes
the contents of an element but not the element itself, however, let me
just to point out that in the case of a multidimensional array this
"delete" translates to "make it broken".
Anyway, enough with ADEL(). The question is if we can do something with
HB_ADEL(). I don't know if it is proper to propose now modifications but
here it is:
-------------------------------
HB_ADEL(aArray, [<wrong type value>]) --> mismatch argument RTE
HB_ADEL(aArray, [<nPosition out of index>]) --> boundary RTE
HB_ADEL(aArray) --> {} // an empty array, equal to aArray := {}
--------------------------------------------------------------
Of course all of the above could be easily implemented locally,
in prg or preprocessor level, but since i have faced the problem
in a real code situation, I thought that it might be useful
to notify my experience here.
Please, (and i hope i don't peculate your time) consider the code:
-------------
// IF nFile := ascan(a, {|x| UPPER(x[F_NAME]) == "HBDIR.EXE"}) > 0
IF ( nFile := HB_ASCAN( a, {|x| UPPER(x[F_NAME]) == "HBDIR.EXE"},,,.T. )
) > 0
HB_Adel(a, nFile, .t. )
ENDIF
-------------------------------------
It took me some time to realize what was wrong (in the now commented
line above). The problem, as you can easily see, was the (unforgivable)
lack of parentheses that had as result nFile var to take a boolean value
(.T. in the particular case), which subsequently was giving to HB_ADEL()
the "freedom" to do its magic by deleting the first array element
instead of "HBDIR.EXE" element. Of course I would have saved my time
(and my nerves) if HB_ADEL() had, from the very first run, warned me
about the erroneous type value of nFile.
best regards,
---
Pete
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
