Hi Pete,
On 2010 Mar 13, at 11:03, pete_westg wrote:
> According documentation a proper use of the Adel() function, is:
> ADEL(<aTarget>, <nPosition>) --> aTarget
> where <nPosition> is the <aTarget> array element being deleted.
> However, function ADEL() does interesting, -yet unexpected at least for me,
> things when it's invoked with a "slightly fuzzy" way shown in the sample
> below:
>
> 8<---------------------------------------------------------------------------------
> #define CRLF HB_OSNewLine()
> PROCEDURE MAIN()
> LOCAL aArray := {"one", "two", "three", "four", "five"}
>
> ? "TestProg: " + HB_ARGV()+ " [testing adel() function]"
> ?
> "============================================================================"
> ?
> ? "--- Our array before adel()'s touch.. --> "
> AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + " ")} )
> ?
> ? "CASE_1 : ADEL(aArray, .T. .OR. .F.) --> "
> ADEL(aArray, .T. .OR. .F.) // to adel() or to not adel()?
> AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + " ")} )
> ?
> ? "CASE_2 : ADEL(aArray, 'Guess what element you'll nullify* now?') --> "
> ADEL(aArray, "Guess what element you'll nullify now?") // RTFM
> AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + " ")} )
> ?
> ? "CASE_3 : ADEL(aArray, 2^66) --> "
> ADEL(aArray, 2^66) // can arrays grow up so much ??
> AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + " ")} )
> ?
> ? "CASE_4 : ADEL(aArray) --> "
> ADEL(aArray) // do you mean, delete entire array?
> AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + " ")} )
> ?
> ? "CASE_4b : ADEL(ADEL(aArray)) --> "
> ?? ADEL(ADEL(aArray)) // now that you've learned the art of adeleting...
> ?
> AEVAL( aArray, {|ele| QQOUT(HB_ValToExp(ele) + " ")} )
> ?
> Wait
> RETURN
> --------------------------------------------------------------------------------->8
>
>
> In cases 1 & 2 one would expect the runtime mechanism to throw an error
> because of the erroneous value types passed.
> In case 3 a "boundary error" might be more appropriate/alarming.
> And in Case 4 either:
> - an entire array deletion could be more connotative expected or
> - a runtime error due to lack of the 2nd mandatory arg.
>
> Having the Adel() in all the above case to delete the first array element is
> quite unreasonable, primarily because such an action is undocumented. To be
> fair this is not a Harbour only "feature". Clipper behaves exactly the same
> here!
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.
> And while talking about adel() i think the name ADEL is rather
> misleading, since the function does NOT actually delete elements,
> but rather nullifies them, and you have to use asize()[*] to achieve
> what you probably wanted to do. Perhaps ANUL() would be a more precise name
> but i think it's a little late now to rename it <g>.
ADEL() does delete the element, it just doesn't resize
the array, so you will always get a NIL at the end of the
array. It's not the same as 'array[ n ] := NIL'. For me
ANUL() (or rather ANIL()) suggest that it will replace
whole array with NIL values, of course this is personal
opinion.
> __________________________________________________________________
> [*] I am aware of HB_ADEL() function, that accepts a 3rd parameter (boolean)
> by which you can eventually "adjust" the array size without the need of
> calling asize(). This is a good thing. The "bad" things are that HB_adel()
> stands in the shade of adel() (due to lack of documentation) while the above
> remarks about ADEL() apply also for HB_ADEL too.
Anyone is welcome to document it and post the result to
this list. You can find the format here:
http://lists.harbour-project.org/pipermail/harbour/2010-February/032883.html
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
