[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: lua hacking wondering
- From: "Virgil Smith" <Virgil@...>
- Date: Fri, 25 Jun 2004 13:05:12 -0500
> It seems wrong to me to consider a language feature in the context of a
> specific application feature like "properties". Metamethods do not exist
> the purpose of allowing the programmer to implement a specific feature
> "properties" but rather to allow the execution of arbitrary code when an
> operation is performed on a table.
My apologies for being overly specific, and for using a term that might have
connotations that I am not aware of. I was just trying to phrase things in
a manner that might give better context to the discussion as it seemed that
neither side was making any headway in convincing the other(just my third
My use of the term "property" did imply an assumption that the behavior of
the metamethod would depend on what items in the table were being accessed
(i.e. what keys were used), and carried no other specific usage assumptions.
However, you are right even that assumption is restrictive because one's use
of the metamethods may not depend on what members were being accessed (eg. a
dirty flag, or "hit count").
-- Maybe in receiving some (very reasonable) criticism that generality is
generally preferable, I've found a supporter for my stance that tables
should have gc metamethods. :-)
-- BTW: Thanks again to the Lua authors for making such a wonderful tool
generally available!!! Engineers and software developers will fixate on
endless details that they want to "improve", but that does not mean that we
don't admire the whole (or that we should forget to say so almost as much as
we go on about the details that we would change).
--- More context/history -----
> Hmm, the above statements reminded me of something.
> Perhaps neither camp is 100% right or 100% wrong. In fact maybe they are
> both exactly 50% right and 50% wrong.
> A __gettable metamethod is not useful to implementing "properties". After
> all if you already have a value for the property then there is no need to
> generate the value via a handler function AND whatever value is stored "in
> the property location" is not really the property's value anyway because
> might not be what is returned from the function. __index on the other
> allows both property "get" handlers AND lazy evaluation / caching schemes.
It seems wrong to me to consider a language feature in the context of a
specific application feature like "properties". Metamethods do not exist for
the purpose of allowing the programmer to implement a specific feature like
"properties" but rather to allow the execution of arbitrary code when an
operation is performed on a table. I'm just saying that it seems more
logical to me that the basic operations of getting and setting a value in
table should be chosen instead of the specialized operations of getting and
setting non-existing values. It just seems natural to me that, since the
where a non-existing value is read or written to is more specific than
reading and writing any value, I should have to write extra code fore the
first case and not the second.