[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua 5.2 - emulation of old setfenv
- From: HyperHacker <hyperhacker@...>
- Date: Thu, 6 Jan 2011 07:37:31 -0700
On Thu, Jan 6, 2011 at 07:01, Thomas Harning Jr. <harningt@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 2:21 AM, HyperHacker <hyperhacker@gmail.com> wrote:
>> On Thu, Jan 6, 2011 at 00:17, Dirk Laurie <dpl@sun.ac.za> wrote:
>>> On Thu, Jan 06, 2011 at 07:56:58AM +0200, Miles Bader wrote:
>>>> Lorenzo Donati <lorenzodonatibz@interfree.it> writes:
>>>> First step: what's the best way to detect one is running in 5.2?
>>>>
>>>> I can do:
>>>>
>>>> local lua_52 = string.match(_VERSION, " 5[.]2$")
>>>>
>>>> but my impression is that such version-string matching is often thought
>>>> of as being not-so-good (e.g., the above will fail in 5.3 or 6.0, even
>>>> though they're likely to be more like 5.2 than 5.1).
>>>
>>> local lua_version = tonumber(string.match(_VERSION,'%d*%.%d*'))
>>>
>>> will allow the test
>>>
>>> if lua_version >= tonumber('5.2') then -- etc
>>>
>>> Dirk
>>>
>>>
>>>
>>
>> I had been wondering why aside from _VERSION there isn't some variable
>> with the numeric version number for this purpose.
> Perhaps a major/minor variable would be good to have... converting 5.2
> to a number will work until they come out with version 5.10 (depending
> on how they do versions...)... fell into that hole when working with
> LPeg and doing version management.
>
> Perhaps the best way to work with versions is to do feature detection
> by the presence/non-presence of functions/variables. The danger in
> this is if a function's "signature" or behavior changes, though it
> seems this has been rare for the core Lua functionality.
>
> --
> Thomas Harning Jr.
>
>
Mhm, one solution would be to use integers: 5.1 => 501, 5.10 => 510.
In fact this is a major reason that I use binary-encoded dates for
version numbers...
I don't think having major and minor fields would help much, as when
you do that, for some unfathomable reason it becomes a common
anti-pattern to check only the minor version, so your program fails on
6.0 because 0 < 1. I believe this was a problem Microsoft encountered
when wanting to bump the Windows version to 6.0 as well.
--
Sent from my toaster.