[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: `depreciated` attribute for Lua?
- From: Mouse <mouse@...>
- Date: Tue, 12 Sep 2023 08:28:07 -0400 (EDT)
> 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