[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: little questions
- From: Thomas Lauer <thomas.lauer@...>
- Date: Fri, 13 Nov 2009 10:33:47 +0000
steve donovan <steve.j.donovan@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 5:52 PM, spir <denis.spir@free.fr> wrote:
> > * Stdlib operations on strings and files can be written obj:op().
> > But this does not seem to work for tables. Am I right? Is there
> > a reason for this? Is it possible to make the syntax uniform by
> > assigning stdlib funcs defined on "table" to the type "table"?
>
> It's possible that every new table gets a metatable pointing to
> 'table', so list:concat() etc. The Lua fork Idle does this. But (as
> has been pointed out before) it leads to confusion, because very often
> we define our own metatables.
It's not that easy. First, Idle only ever creates a metatable and
initialises __index for tables created via an explicit call to
table.new(). Tables created via t={} are plain tables w/o a metatable.
So there's a choice to start with.
Second, the idea that doing this leads per se to confusion is IMHO
debatable. It all boils down to a design question: a majority, perhaps
75%, of the tables I use in my programs are "normal" tables (and I
suspect for most Idle users this percentage is even higher). Having
these tables behave out-of-the-box as spir described is clearly an
advantage if most user-created tables don't need their own metatable
mechanisms.
Summary: someone who creates table t via t=table.new() and not via t={}
*and* then wants to do some metatable magic with t is supposed to know
what he or she is doing. I fail to see why this would lead to confusion:
you can't have your cake and eat it.
--
cheers thomasl
web: http://thomaslauer.com/start