1. Re: we need official libs : Swap
Cuny, David wrote:
>> Um, I'm not sure I understand. Are you saying we
>> should weed the concept of sequence indexing out
>> of Euphoria?
>
>Obviously not. I am saying (and it appeared that you were agreeing) that
>code indexing heterogeneous (of different types) data is often less clear
>than code that uses 'simple' variables. The example was:
<snip examples--to avoid ambiguity further down 
>
>You had agreed that the code using mapping was less confusing, error prone
>and difficult to debug. You went on to say that:
>
>>> But that's just an inherent side effect of sequence (or array)
>>> indexing in general.
>
>Which is the point of mapping - you don't have to store function results in
>sequences, and avoid the problems of then indexing that sequence.
I see; sorry, the specific line of code you gave threw me off. I think I'm
going to have to restate your statements here, so bear with me... What you
*ultimately* mean is:
{x1, y1} = get_position (self, x1, y1)
is clearer, etc., than
pos1 = get_position (self, x1, y1)
x1 = pos1[X]
y1 = pos1[Y]
I agree with this, but to a lesser extent than your original example. It's
MUCH easier to understand and maintain the second of the above examples,
than it is the second of the below examples:
draw_line (x1, y1, x2, y2) -- possible due to either of the above
draw_line (pos1[X], pos1[Y], pos2[X], pos2[Y]) -- less desireable
It usually makes sense to go through the steps of storing the elements
in seperate variables (even without the convenience of multi-assignment)
while receiving a sequence. This is especially true if one plans to
reference those values more than once. So from what I gather, the place
where one would really NEED to eliminate the sequence indexing would be
in the first pair of examples.
And yet, I don't really see a need. Unless the code segment is so trivial
that I don't think the details could mess me (or anyone else) up, I always
split returned sequences into seperate variables. So all I would really gain
from this new construct would be the ability to change:
s = process_data ()
a = s[A]
b = s[B]
c = s[C]
x = s[X]
y = s[Y]
z = s[Z]
into
{a, b, c, x, y, z} = process_data ()
which, to me, isn't really that big a gain (especially considering that
there would be many times where it would be cumbersome to use, such as
when I only needed x and y.)
In fact, (sorry to make use of a point you brought up, but it's valid...)
I think I would prefer to actually break out the values myself anyway,
using constants as my sequence indexes. That way, if the order/length of
data ever changed, only my constants would change, no matter how many
times they were used in the code. So in truth, I might very well NEVER use
a multi-assignment construct.
That being the case, it's even *harder* for me to see the point of 'fixing'
the language to allow it. Slight convenience and slight clarity increase,
on rare occasions, isn't enough of a justification in my mind.
Rod
