Re: we need official libs : Swap
Pff ..
> (One might suggest that theoretically we should be able to close our eyes
to
> the implementation, but that's just not possible with this
construct--which
> says something by itself. There's no way of knowing how
>
> {s[i], s[j]} = my_func ()
>
> evaluates when i=j without knowing how it's implemented.)
Interesting. You can code confusingly with theoretical improvements.
I can even do it with any feature of euphoria already ... Should we start
removing all those features ?
I don't care how the above is handled. Illegal, legal ( s[i/j] becomes 2nd
element as if it was written out. )
What i do know is that I would often use:
{ status, value } = get ()
{x, y} = location ()
I can't come up with any situation where I would use your example though.
So, I really wouldn't care if it would be illegal. Consider the equilivent
now, and the weird side-effects:
object temp
temp = my_func ()
s[i] = temp[1]
s[j] = temp[2]
This code would assign temp[2] to s[i/j] when i and j are equal.
I can't come up with any situation where you would want to code it this way,
but if the situation exists, I would say any of the two approaches are
unclear. It would simply be a confusing algorithm irregardless of the syntax
used.
Thirdly, although, you may have been taught differently, as most. Just
because something is there and others use it, doesn't mean you have to use
it. I mean these two are equilivent, and I use both of them:
x = append (x, s)
x &= {s}
The first is more readable, when x is a normal variable.
When x is a weird complex slice, the second would be the right choice.
Example:
window[text_filed][line_number] &= { char }
Is better than:
window[text_filed][line_number] = append
(window[text_filed][line_number], char )
Then again, one could also do:
junk = window[text_filed][line_number]
window[text_filed][line_number] = append (junk, char)
I would even go as far to say, the second two approaches are ugly, unclear
and confusing. The first one is not as clean as it could be, but cleaner.
The third, is the most complex. Because you don't instinctly have an
understanding of what's going on, you have to analyze several statements and
how they relate. Something also very true with your so beloved syntax of
object junk
junk = location ()
s[i] = junk[1]
s[j] = junk[2]
Dare I say it, but even in this case, the code is interpreter faster and
more certain by me, human(tm), using:
{ s[i], s[j] } = junk
You are wondering how it is handled ... Precizely like I, in the beginning,
was wondering how this was handled:
s = {2,34, 3498, { 34, 34, 1234 } , 34 }
s = s * s + 3
I now know what this does, because I know the rules Euphoria is using. Are
they instinctly clear ? No. Are they effective ? Yes. Do I die learning this
rules ? No. Do I have to learn these rules ? No, you can use an alternative
approach to the problem without having to learn those rules:
s[1] = s[1] * s[1] + 3
s[2 ......... etc.
I'm glad I have the choice to choose for the most complex and confusing
approach above. It might even scare off newcomers (oh, no! like marketing
has got anything to do with this ?) ..
Sorry if this all sounds sarcastic .. it is .. upto some level. I feel the
perspective people have new features is like some have on foreign people ..
something new, something scary .. "I don't know it yet. It confused ME".
Yes, off course, did you understand every Euphoria program without even
reading the documentation ? Get real.
Most parts of Euphoria are quite confusing in the beginning. Surely not as
confusing as C or ASM, but nevertheless confusing. Most people here, already
_know_ euphoria .. and I, personally couldn't care less about the learning
curve. All I can tell you about my learning curve is, that I was confused
and suprised to see this feature wasn't even supported at all. Learning
curve, my friend, is hardly an argument, and certainly doesn't apply on your
interests, since you've already learned Euphoria.
If didn't make rules about languages such as English, we were still trying
to explain each other things using our hands and drawings .. very newcomer
friendly .. hardly effective. Some goes for programming languages...
Now, precizely when are we going to see this implemented ?
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
Check out the [Elevator]
http://www.xs4all.nl/~nieuwen
|
Not Categorized, Please Help
|
|
