Hi,
>> 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.
As a rule in Harbour we chose to "clone" original Clipper
behavior, unless it's clear bug or MS-DOS specific
portability issue. In case of ADEL() and lots of other
original Clipper functions, many aspects of behavior can be
questioned, disputed, and surely it could be made better,
but there are two problems: 1) these areas are very subjective
2) It breaks Clipper compatibility. We value compatibility
the most in Harbour, as this is the only way to ensure that
code written for Clipper will also work with Harbour. So
we don't touch, modify or extend basic features as a ground
rule.
> 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 := {}
In case of HB_ADEL() the only real constraint is
to stay compatible with previous Harbour versions.
What you say can be technically implemented, I'd only
argue with HB_ADEL(<a>)->{}, which is a synonym to
ASIZE(<a>,0), so IMO unnecessary and better to raise RTE.
> --------------------------------------------------------------
>
> 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.
Of course, but note that the best solution for most of similar
problems is strongly typed parameter checking. Without it,
even if we modify HB_ADEL() there will remain thousands of
other such places for similar typos, so we're not really
solving the real problem here IMO.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
