I feel LuaBinary is slowly going to bridge over this dilemma (of Lua version incompatibilities). It's really simple, in fact, just allow N versions of Lua co-exist on the platform, and have particular packages (thinking fink, dpkg, apt-get here) to explicitly bind themselves to the specific (range) of Lua that they approve. That's it.
In practise, you'd get "lua50", "lua51" and so on, and a symbolic link called "lua" that points to "some" of these.
I'm going to be shipping Hamster and Lumikki as packages, and have been facing this in practise. Since the end users don't really want to know about Lua versions (or: what Lua is), they'll just "sudo fink install lumikki" and that's it.
-asko
ps. I don't see Apple having Lua built-in as a big issue, really. Since the language is so much smaller than Perl, it can be provided on-the-fly. For people who don't use 'fink', hmm... but they use command line? ;)
Please build in fink instead, that'd be Waaay Cool... (really, do it?)
Jens Alfke kirjoitti 17.1.2006 kello 21.46:
On 17 Jan '06, at 6:48 AM, Lisa Parratt wrote: Indeed they can't. If one combines a type override and an old, incompatible, library, then that's indeed a problem. However, being a consequence of their own actions, it's also *their problem*.
It could occur to someone trying to use library A and library B together, but not having written either library. It's hard to write that off as their problem. From their perspective it just makes Lua look flaky.
Seeing as it appears Lua has a nasty habit of subtlely breaking backwards compatibility as it's version number increases, I don't see how this would be a real problem anyway.
Exactly what I was going to say. Lua seems to take the approach that that backward compatibility can be sacrificed, since any program that uses it will embed its own copy of Lua; so that the developer is in control of which version of Lua to use, and how to customize it, and can iron out compatibility problems before release. This is reasonable, given that Lua's code size is tiny and it is used in a lot of embedded systems.
But it does have the consequence of making a shared system-wide Lua engine (e.g. /usr/bin/lua) problematic. Upgrading that engine could cause an unknown number of clients that use it to break, if there are incompatible changes between the two versions of Lua. That's not going to be acceptable to end users or to the developers of those clients. (Imagine the reaction of users, Adobe and Apple if an upgrade to the next release of OS X caused Lightroom to break.)
I bring this up because, some people at the Lua Workshop last year, when they learned I work at Apple, were curious whether Apple might ship Lua in OS X. It seems unlikely, for this reason. Binary compatibility is very, very important to us, and we don't want new versions of the OS to break applications. In the case of apps that are mission-critical to large numbers of users (Office, Photoshop, World Of Warcraft...), incompatibilities become show-stoppers that force us to add kludges to the OS to keep them running. Such are the rigors of working on an end-user-oriented operating system whose users don't build things from source.
--Jens
|
