1. Re: we need official libs : Swap
Hello,
Roderick Jackson wrote:
>Hmmm, I've run into some situations where I could have used this shorthand.
>
>But I'm actually rather glad it's not allowed. Your second example is, at
>first glance (and at second glance to anyone just learning the language,)
>much
>clearer than the first. And while every now and then I groan at having to
>declare a "holding" variable, this is another example of preventing abuse
>of
>the idea; much MORE confusion is possible by allowing it than by not
>allowing
>it.
I agree, it wouldn't be newbie-friendly.
>I'd hate to get someone's code and try to figure out what
>
> d = {1,2,
> my_function(b[{a,b,c}[h]])[other_func
> ({x,y,z})+({a,b,c}*{x,y,z})[h]]
>
>evaluated to. I'd much rather see it all forced out into some semblance of
>order:
>
> e = {a,b,c}
> f = e * {x,y,z}
> g = other_func ({x,y,z}) + f[h]
> k = my_function(b[e[h]])
> d = {1,2,k[g]}
Actually I agree with you for the most part but
I'd still like to see some sort of compromise.
Like maybe only allowing one level of this kind
of nesting per statement:
value = gets (0)[2] -- Okay
obj = func1 (x)[func2 (y)[i]] -- Error
>Obviously, this example is ridiculously complex, but it does illustrate
>the principle: requiring one of the grouping delimiters ([], out of {},[],
>and ()) to be used only with variables limits potential nesting.
>And believe me, there WOULD be folks who would attempt the above, just
>because
>they wouldn't have to create those extra variables, and could compress
>multiple
>expressions into one.
Yeah, and I'd probably be one of them. ;p
Lewis Townsend
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
