[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Odd behaviour with multiple return values and varargs
- From: David Kastrup <dak@...>
- Date: Thu, 13 Sep 2007 15:52:43 +0200
"Tom Miles" <Tom@creative-assembly.co.uk> writes:
>> Huh? We are not talking about "unexpected values", but "an
>> unexpected number of values" in a hypothetical non-Lua language
>> that then consequently thwarts the list/value relationship.
>> I am saying that this non-Lua language is not a good idea, and Tom
>> Miles demands that I should write code as if I had to deal with
>> this non-Lua language, and now you call my code "at fault" for not
>> working under this hypothetical non-Lua language?
> Sorry if I've offended you, but I'm not *demanding* anything. I'm
> also not talking about a hypothetical non-lua language, I'm trying
> to understand a justification for something that I see as counter
> intuitive within the language am I trying to use.
>> Why would I know that? Why should I need to know?
> I would have thought if you were calling a function you would want
> to know what it does!
If the syntactical relation of code can't be guessed just from reading
it, that's a bad idea.
>> I am sure we can get even more absurd if we really try, but I
>> don't think it worth doing.
>> >> Anyway, there is no reasonably elegant way to rewrite something like
>> >> a, i = f(a+1,i), f(i,a)
> The same argument can be used for what I am trying to do, only I *have*
> to use temporary variables. What I was trying to do is:
> function Position()
> return x,y
> function Dimensions()
> return w,h
> function push_clip(x,y,w,h)
> -- Do stuff
> push_clip(Position(), Dimensions())
See how bad the idea is? Hide away the definition of Position and
Dimensions, and you have _no_ clue whatsoever what arguments can be
affected from "Dimensions". Worse: a bug in Position will clobber the
relation between w, h, and Dimensions, leading to symptoms in an area
completely unrelated to the actual bug.