Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)

[Sean Conner <sean@...>]

It was thus said that the Great Ross Bencina once stated:
> 
> I'm going to attempt an answer, from my perspective:
> 
> Use case #1: application development language

  [ snip ]

> Use case #2: user extension language

  [ snip ]

> For use case #1 above (developing) it probably doesn't matter, people 
> can do what they like, but for use case #2 (user extension) I really 
> don't want to wear the "object system and language library designer" hat 
> and be held accountable by my users of how such basic facilities work -- 
> I'm more than happy to do it the "standard base way".
> 
> Does that make sense?

  Not really.  I don't see any real difference between #1 and #2, so I'm not
even sure what you are asking.  Also, I'm not a big proponent of object
oriented programming, and I find what Lua provides just fine for my own
needs (I stay as far away from C++ as possible), so I don't quite understand
this whole obsession over objects.  From what I can see, Lua support of
"objects" is fine.

  At work, I use Lua to test our software.  And for one platform (Solaris)
I've had to create what I call "The Kitchen Sink Lua"---it's basically a
custom Lua standalone interpreter that has all the modules we need to run
(both in C and Lua) built into a single executable.  And yes, stuff that
would normally go into /usr/local/lib/lua/5.1 or /usr/local/share/lua/5.1
have been compiled statically into this "Kitchen Sink Lua" (primarily
because it's difficult to get the required shared objects/Lua files
installed on the deployment systems).

  So for my use case, it's important to be able to statically compile
modules into the program.  It's less important to have a "base library" or
"base object system" because what Lua provides is enough (or rather, I have
to supply quite a bit, but it's all custom coding anyway).  

  -spc