suggestion: __typeof()

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

suggestion: __typeof()

Asko Kauppi

I'd suggest adding a "__typeof()" metamethod to Lua, similar to __tostring() but used by the 'type()' built-in function.

The reason? It could be used with userdata, to provide more information of the entity than just "userdata" does. For example, it could provide "enum/SDL_INIT", telling that the entity is an enumaration of logical type SDL_INIT.

The main benefit would be better error messages, and better type-wise expandability of Lua in general.

Please consider,
-asko


Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Luiz Henrique de Figueiredo
> I'd suggest adding a "__typeof()" metamethod to Lua, similar to  
> __tostring() but used by the 'type()' built-in function.
> 
> The reason?  It could be used with userdata, to provide more  
> information of the entity than just "userdata" does. For example, it  
> could provide "enum/SDL_INIT", telling that the entity is an  
> enumaration of logical type SDL_INIT.
> 
> The main benefit would be better error messages, and better type-wise  
> expandability of Lua in general.

We've been there I think. This is a bad idea because it will break all
programs that rely on type returning a fixed set of values. You could
make type return 2 values, one raw and one cooked, but it seems to me
that it is simpler to have a separate function, say mytype.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

eugeny gladkih-2
Luiz Henrique de Figueiredo <[hidden email]> writes:

>> I'd suggest adding a "__typeof()" metamethod to Lua, similar to  
>> __tostring() but used by the 'type()' built-in function.
>> 
>> The reason?  It could be used with userdata, to provide more  
>> information of the entity than just "userdata" does. For example, it  
>> could provide "enum/SDL_INIT", telling that the entity is an  
>> enumaration of logical type SDL_INIT.
>> 
>> The main benefit would be better error messages, and better type-wise  
>> expandability of Lua in general.
>
> We've been there I think. This is a bad idea because it will
> break all

why will it break?! all existing programs know nothing about
such method, they don't implement it. so, nothing'll happen at all.

> programs that rely on type returning a fixed set of values. You could
> make type return 2 values, one raw and one cooked, but it seems to me
> that it is simpler to have a separate function, say mytype.

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Luiz Henrique de Figueiredo
> why will it break?! all existing programs know nothing about
> such method, they don't implement it. so, nothing'll happen at all.

I meant, all programs that do this or something equivalent:
	if type(x)=="userdata" then ...

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Lisa Parratt
Luiz Henrique de Figueiredo wrote:
I meant, all programs that do this or something equivalent:
	if type(x)=="userdata" then ...

--lhf

One would imagine that if someone overrode the result of type, then they'd *want* that to fail.

Asko: As with most limitations on metamethods, I'd advise patching it in yourself. I've had to do this because I wanted to do real metaprogramming, and after a few tweaks, it works great. I've made objects that appear to be true numbers to any Lua code, but are in fact tables containing proxy objects. I've not profiled things, but I think it's only slightly slower than stock Lua. It's an easy price to pay for flexibility, though.

--
Lisa
http://www.thecommune.org.uk/~lisa/

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Luiz Henrique de Figueiredo
> One would imagine that if someone overrode the result of type, then 
> they'd *want* that to fail.

Except that the code that uses "type" might be a third-party library
that knows nothing about the new "type". --lhf

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Lisa Parratt
Luiz Henrique de Figueiredo wrote:
Except that the code that uses "type" might be a third-party library
that knows nothing about the new "type". --lhf

So because someone might cut their fingers off, we shouldn't use knives? Just because someone might burn themselves, we shouldn't cook food?

Just because a facility has consequences that may be problematical is no reason to utterly dismiss the facility.

--
Lisa
http://www.thecommune.org.uk/~lisa/

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Alex Queiroz
Hallo,

On 17/01/06, Lisa Parratt <[hidden email]> wrote:
>
> So because someone might cut their fingers off, we shouldn't use knives?
> Just because someone might burn themselves, we shouldn't cook food?
>

     Please stop trying to be Lao-Tze.

> Just because a facility has consequences that may be problematical is no
> reason to utterly dismiss the facility.
>

     Luiz is talking about all the old code that would break with this
new type function. Unfortunately people can't see the future yet, so
as to avoid burning themselves.

--
-alex
http://www.ventonegro.org/


Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Lisa Parratt
Alex Queiroz wrote:
     Luiz is talking about all the old code that would break with this
new type function. Unfortunately people can't see the future yet, so
as to avoid burning themselves.

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*.

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.

--
Lisa
http://www.thecommune.org.uk/~lisa/

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Dolan, Ryanne Thomas (UMR-Student)
In reply to this post by Alex Queiroz
Old code would not break.

Have the __typeof metamethod return two values.  The first is "userdata" and the second whatever specific type you like.  That way old code doesn't break, and new code could check first whether the variable is userdata and then what specific type of userdata.

On Tue, 2006-01-17 at 12:25 -0200, Alex Queiroz wrote:
Hallo,

On 17/01/06, Lisa Parratt <[hidden email]> wrote:
>
> So because someone might cut their fingers off, we shouldn't use knives?
> Just because someone might burn themselves, we shouldn't cook food?
>

     Please stop trying to be Lao-Tze.

> Just because a facility has consequences that may be problematical is no
> reason to utterly dismiss the facility.
>

     Luiz is talking about all the old code that would break with this
new type function. Unfortunately people can't see the future yet, so
as to avoid burning themselves.

--
-alex
http://www.ventonegro.org/

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

eugeny gladkih-2
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo <[hidden email]> writes:

>> why will it break?! all existing programs know nothing about
>> such method, they don't implement it. so, nothing'll happen at all.
>
> I meant, all programs that do this or something equivalent:
> 	if type(x)=="userdata" then ...
>

new packaging meta-stuff will break far more "old" libraries, I guees.

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Vyacheslav Kalitkin
In reply to this post by Asko Kauppi
The reason?  It could be used with userdata, to provide more
information of the entity than just "userdata" does. For example, it
could provide "enum/SDL_INIT", telling that the entity is an
enumaration of logical type SDL_INIT.

I always create "class" property for my userdata objects to return class
name.

Instead I suggest to add a "__next" methamethod to userdata,
for iterate userdata with next() functions.

Today with "__len" I can iterate my userdata as
for i=1,#ud do ...ud[i]... end

But I hope you can add way to iterate userdata with
next(), pairs() and ipairs() functions.

for example
meta = { G={}}
meta.__index=meta.G
meta.__next=meta.G (or function what returned keys array or iterator function)
setmetatable(ud,meta)
for k,v in pairs(ud) do ... end

Best regards,
Vyacheslav Kalitkin


Reply | Threaded
Open this post in threaded view
|

Re: compatibility [was: suggestion: __typeof()]

Jens Alfke
In reply to this post by Lisa Parratt

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
Reply | Threaded
Open this post in threaded view
|

Re: compatibility [was: suggestion: __typeof()]

Asko Kauppi

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

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Asko Kauppi
In reply to this post by Lisa Parratt

I will surely be patching it in myself, if only to see whether lhf is right. :)

More often than not, the Lua authors have in fact been the "wize old guys" knowing better, in the end. But I do persist, that having type- aware enums is simply a killer feature for some bindings, such as SDL and maybe the kinds like Gtk+.

The only difference of not having this ability, shall be different behaviour of type() whether a module is loaded via stock Lua, or LuaX (or stock Lua, and LuaX module). :) Gosh, I don't really know, where this road takes me, but it will be fun!

-asko


Lisa Parratt kirjoitti 17.1.2006 kello 12.18:

Luiz Henrique de Figueiredo wrote:
I meant, all programs that do this or something equivalent:
	if type(x)=="userdata" then ...
--lhf

One would imagine that if someone overrode the result of type, then they'd *want* that to fail.

Asko: As with most limitations on metamethods, I'd advise patching it in yourself. I've had to do this because I wanted to do real metaprogramming, and after a few tweaks, it works great. I've made objects that appear to be true numbers to any Lua code, but are in fact tables containing proxy objects. I've not profiled things, but I think it's only slightly slower than stock Lua. It's an easy price to pay for flexibility, though.

--
Lisa
http://www.thecommune.org.uk/~lisa/


Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Asko Kauppi
In reply to this post by Alex Queiroz

Hmm.. the old code will break only _if_ the new type() is there _and_ some userdata implements the __typeof metamethod.

I think this makes the chances rather slim, also the calling code would implicitly expect Lua never-ever to get any more types than it now has, which is bad presumption anyhow.

-asko


Alex Queiroz kirjoitti 17.1.2006 kello 16.25:

Hallo,

On 17/01/06, Lisa Parratt <[hidden email]> wrote:

So because someone might cut their fingers off, we shouldn't use knives?
Just because someone might burn themselves, we shouldn't cook food?


     Please stop trying to be Lao-Tze.

Just because a facility has consequences that may be problematical is no
reason to utterly dismiss the facility.


     Luiz is talking about all the old code that would break with this
new type function. Unfortunately people can't see the future yet, so
as to avoid burning themselves.

--
-alex
http://www.ventonegro.org/


Reply | Threaded
Open this post in threaded view
|

RE: suggestion: __typeof()

Dolan, Ryanne Thomas (UMR-Student)
I still say there is no issue.  Maybe I wasn't being clear:

T = {};
M = {};
M.__typeof = function () return "userdata", "MyType" end;
setmetatable (T, M);

--old code:
if type (T) == "userdata" then
    print "Old code still works";
end;

--new code:
t, s = type (T)
if t == "userdata" and s == "MyType" then
    print "new code can take advantage of extra info";
end;

See?  The new behavior of type () should be as follows:  If there is a __typeof metamethod, then call it and return the results.  Otherwise, use default behavior (return "table", "userdata", etc).  The metamethod can just return two values to avoid breaking older code that expects only "userdata" or "table".

Now, of course if I define a __typeof metamethod that only returns one value, then it can potentially break older code.  But it should be up to the programmers whether to include backwards compatibility in their scripts.  The language should not be held back just because an improvement might allow a poor programmer to break older, poorer code.  Coming up with some patch is a way worse alternative.

-----Original Message-----
From: [hidden email] on behalf of Asko Kauppi
Sent: Tue 1/17/2006 2:45 PM
To: Lua list
Subject: Re: suggestion: __typeof()
 

Hmm.. the old code will break only _if_ the new type() is there _and_  
some userdata implements the __typeof metamethod.

I think this makes the chances rather slim, also the calling code  
would implicitly expect Lua never-ever to get any more types than it  
now has, which is bad presumption anyhow.

-asko


Alex Queiroz kirjoitti 17.1.2006 kello 16.25:

> Hallo,
>
> On 17/01/06, Lisa Parratt <[hidden email]> wrote:
>>
>> So because someone might cut their fingers off, we shouldn't use  
>> knives?
>> Just because someone might burn themselves, we shouldn't cook food?
>>
>
>      Please stop trying to be Lao-Tze.
>
>> Just because a facility has consequences that may be problematical  
>> is no
>> reason to utterly dismiss the facility.
>>
>
>      Luiz is talking about all the old code that would break with this
> new type function. Unfortunately people can't see the future yet, so
> as to avoid burning themselves.
>
> --
> -alex
> http://www.ventonegro.org/



<<winmail.dat>>

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

eugeny gladkih-2
"Dolan, Ryanne Thomas (UMR-Student)" <[hidden email]> writes:

> I still say there is no issue.  Maybe I wasn't being clear:
>
> T = {};
> M = {};
> M.__typeof = function () return "userdata", "MyType" end;
> setmetatable (T, M);
>
> --old code:
> if type (T) == "userdata" then
>     print "Old code still works";
> end;
>
> --new code:
> t, s = type (T)
> if t == "userdata" and s == "MyType" then
>     print "new code can take advantage of extra info";
> end;

why not? it seems to be very elegant solution!

>
> See?  The new behavior of type () should be as follows:  If there is a __typeof metamethod, then call it and return the results.  Otherwise, use default behavior (return "table", "userdata", etc).  The metamethod can just return two values to avoid breaking older code that expects only "userdata" or "table".
>
> Now, of course if I define a __typeof metamethod that only returns one value, then it can potentially break older code.  But it should be up to the programmers whether to include backwards compatibility in their scripts.  The language should not be held back just because an improvement might allow a poor programmer to break older, poorer code.  Coming up with some patch is a way worse alternative.
>
> -----Original Message-----
> From: [hidden email] on behalf of Asko Kauppi
> Sent: Tue 1/17/2006 2:45 PM
> To: Lua list
> Subject: Re: suggestion: __typeof()
>  
>
> Hmm.. the old code will break only _if_ the new type() is there _and_  
> some userdata implements the __typeof metamethod.
>
> I think this makes the chances rather slim, also the calling code  
> would implicitly expect Lua never-ever to get any more types than it  
> now has, which is bad presumption anyhow.
>
> -asko
>
>
> Alex Queiroz kirjoitti 17.1.2006 kello 16.25:
>
>> Hallo,
>>
>> On 17/01/06, Lisa Parratt <[hidden email]> wrote:
>>>
>>> So because someone might cut their fingers off, we shouldn't use  
>>> knives?
>>> Just because someone might burn themselves, we shouldn't cook food?
>>>
>>
>>      Please stop trying to be Lao-Tze.
>>
>>> Just because a facility has consequences that may be problematical  
>>> is no
>>> reason to utterly dismiss the facility.
>>>
>>
>>      Luiz is talking about all the old code that would break with this
>> new type function. Unfortunately people can't see the future yet, so
>> as to avoid burning themselves.
>>
>> --
>> -alex
>> http://www.ventonegro.org/
>
>
>
>

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com

Reply | Threaded
Open this post in threaded view
|

RE: suggestion: __typeof()

Michael Richter
In reply to this post by Dolan, Ryanne Thomas (UMR-Student)
On Tue, 2006-17-01 at 15:59 -0600, Dolan, Ryanne Thomas (UMR-Student) wrote:
Now, of course if I define a __typeof metamethod that only returns one value, then it can potentially break older code.  But it should be up to the programmers whether to include backwards compatibility in their scripts.  The language should not be held back just because an improvement might allow a poor programmer to break older, poorer code.  Coming up with some patch is a way worse alternative.

There is an obvious solution to this: wrap the metamethod inside the interpreter.  The metamethod returns as many values as it likes -- one to one hundred -- and the engine calling the metamethod tacks on a "userdata" to the beginning of it.  Problem solved.

I'm always a fan of enforcing polite coding behaviour in the language.  ;)

--
Michael T. Richter
Email: [hidden email], [hidden email]
MSN: [hidden email], [hidden email]; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: [hidden email]

Attachment: signature.asc
Description: This is a digitally signed message part

Reply | Threaded
Open this post in threaded view
|

Re: suggestion: __typeof()

Lisa Parratt
Michael T. Richter wrote:
There is an obvious solution to this: wrap the metamethod inside the interpreter. The metamethod returns as many values as it likes -- one to one hundred -- and the engine calling the metamethod tacks on a "userdata" to the beginning of it. Problem solved.

I'm always a fan of enforcing polite coding behaviour in the language.  ;)

This is great for many uses, but totally kills the utility of the function for proxy objects.

What if my userdata is a proxy for an external vector, and therefore wants to present itself to Lua code as a table? With a simple __typeof metamethod, it can simply return "table". With your proposed "forced politeness", it's back to patching out idiot proofing before someone who understands and accepts the consequences of their actions can use Lua to it's full.

--
Lisa
http://www.thecommune.org.uk/~lisa/

12