lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Without taking a position on whether or not the __typeof metamethod feature should be added (I like the idea but I can't say much about what code it may or may not break), with regard to its return values, I think that Lua is more about providing flexibility and choice to their users, and less about enforcing polite coding behaviour. I remember reading in PiL (I think) something along the lines of, if you don't want to do this or this in your code, then simply don't do it. In this respect I think forcing the first return value of __typeof to be "userdata" by hardcoding it into the lua core, is limiting and takes away that choice from the user. Besides it's an extra condiion for the user to remember and deal with, which hurts the language's simplicity and uniformity. Just my two cents on the subject.


From: "Michael T. Richter" <ttmrichter@gmail.com>
Reply-To: Lua list <lua@bazar2.conectiva.com.br>
To: Lua list <lua@bazar2.conectiva.com.br>
Subject: Re: suggestion: __typeof()
Date: Wed, 18 Jan 2006 21:10:02 +0800

On Wed, 2006-18-01 at 11:19 +0000, Lisa Parratt wrote:

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

Wouldn't a table holding your userdata do the same thing?  Return type
"table" I mean?

--
Michael T. Richter
Email: ttmrichter@gmail.com, mtr1966@hotpop.com
MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM:
michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber:
mtr1966@jabber.cn


<< signature.asc >>