lua-users home
lua-l archive

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


> Deprecations however should be tied to values, not to variables.

I'm not sure I agree.  If I have functionality available under a modern
name and a deprecated name, I would expect the deprecation to be
attached to the deprecated name, not to the functionality.  (If only
the latter is available, I can write a wrapper, but that's definitely a
workaround.)

> Functions are first-class, so what if I do mytable.reduce(t, add)?
> At this point the variable becomes an argument of reduce (the value
> is put on the stack when calling), and the deprecation info tied to
> the variable would be lost.

Even aside from the internal details, I as a programmer would expect to
get the deprecation warning on the call to mytable.reduce, the point at
which the name is converted into a value.  (I would certainly find it
extremely annoying to get a deprecation warning for every call made to
add().)

It seems to me, without having looked at it in detail, that...

> For deprecated table fields your library exposes, you can use __index
> or __newindex metamethods to warn.

...this sounds like a reasonable approach.  I see no reason deprecation
warnings must any particular _mechanism_, provided the _results_ are
what's wanted.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B