Re: Extending assert () functionality

[Rebel Neurofog <rebelneurofog@...>]

> Please, reread my last post. I wasn't arguing about raw speed, but about
> weight/speed ratio, where (maybe confusingly, I admit) "weight" means "code
> size".

The patch doesn't force you to use function instead string,
so the choice is up to developer.
Here's the example how weight may be decreased by using functions:

function open_db ()
   local internal_name = "handle 'plum'"
   local internal_handle = something ()

   local self = {}

   local function make_error_message ()
      return 'Encountered error while processing
"'..iternal_handle..'": '..internal_handle.get_last_error ()
   end

   function self.get_a (arg1)
      return assert (internal_handle.get_something ("asdfasdf", arg1),
make_error_message)
   end
   function self.get_b (arg1, arg2)
      return assert (internal_handle.get_something2 ("sdlkfj", arg1,
arg2), make_error_message)
   end
   function self.do_a ()
      assert (internal_handle.do_1 (), make_error_message)
   end
   function self.do_b ()
      assert (internal_handle.do_2 (), make_error_message)
   end

   return self
end

> Lua authors have repeatedly stated on this list that, although Lua speed is
> important, Lua code size is important too.

As you can see, we've got 5 complexly interconnected variables here:
1) assertion success case execution speed
2) assertion failure case execution speed
3) Lua source code size
4) Lua VM code size (PUC or JIT)
5) Machine code size of 'assert ()'

> You seem concerned only about speed, which is rightful, but Lua is used, for
> example, also by people working on embedded systems, who perhaps may have a
> different view on what's important. Since you are proposing to change
> something used by everybody, IMHO, my (mild) objection is relevant.

Actually, yes:) Speed is what I usually prefer due to specifics of my projects.