Re: parameter table

[Miles Bader <miles@...>]

spir <denis.spir@free.fr> writes:
>> * much, much, less efficient
>
> Would you like to expand on this? Do you mean machine time? If yes,
> what should be such costly?

Various reasons:  as Linker mentioned, it generates lots of garbage and
so keeps the GC busy; also constructing a table is slower than not doing
so, and accessing elements of a table is slower than accessing arguments.

That's not to say this technique should _never_ be used -- I use it
sometimes, as it can be helpful when the argument list is highly
variable etc.  But I don't think it's suitable for "primitive" functions
that are expected to have low overhead, and which might be called a lot;
that also suggests that for consistency reasons, you shouldn't use it
for primitive functions even if they _aren't_ called a lot...

I think it's common to use this technique for "constructors" of somewhat
complex objects, and heavyweight operations that have lots of options.

One compromise I sometimes use is to make a function accept _either_ a
table containing named arguments, or unnamed arguments passed normal;
roughly like:

   function foo (x, y z)
     if (type (x) == 'table')
       y = x.y
       z = x.z
       x = x.x    -- do x last, as it overwrites the table variable
     end

     ... use x, y, and z ...
   end

That allows the caller to use whichever style is appropriate for his
use, and doesn't have too much overhead when a table isn't used, and
there's only a slight bit of code bloat for the unpacking code.

-Miles

-- 
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.