Re: Query about to-be-closed semantics

[Arnaud Delobelle <arnodel@...>]

On Fri, 14 Jan 2022 at 11:03, Francisco Olarte <folarte@peoplecall.com> wrote:
>
> Arnaud:
>
> On Fri, 14 Jan 2022 at 10:49, Arnaud Delobelle <arnodel@gmail.com> wrote:
> ... example clearing metatable on a to be closed leading to an error snipped.
>
> > That makes sense as I removed the metatable from t before "closing
> > time".  However, when defining c
> >
> >     local c <close> = t
> >
> > at that point the Lua runtime checks that t indeed has a close
> > metamethod and produces an error if that's not the case.  Now it feels
> > to me that this check is conflicting with the behaviour above as this
> > check is not so meaningful if what it checks can be subsequently
> > invalidated.
> >
> > Has this been given consideration?   For example the runtime could
> > remember the close metamethod at variable definition so it will
> > definitely be the one used when the to-be-closed variable comes out of
> > scope.
>
> Any competent programmer can normally crash is language of choice (
> note I loosely consider crash the error, although it is the expected
> behaviour ). You could as easily have defined __close as  function()
> if (math.random()>0.01 then error("My, aren't you unlucky!") end end
> which will avoid that check. Or as "self:real_close()". Or have set
> __close to error in the metatable.

Yes, but I don't really see how it relates to my question.  My
question is in essence why check for a property that we require to be
true later, given that it could change in the meantime?

> I'm sure your exemplified hole can be closed, but I'm not sure the
> added complexity is worth it, giving one should be prepared to an
> error in the closing proccess, "If there is any error while running a
> closing method, that error is handled like an error in the regular
> code where the variable was defined. After an error, the other pending
> closing methods will still be called.", and this is beautifully
> handled, the only thing I would think on adding to it, and only if it
> was a simple, one line patch, would be distinguishing the case nil-not
> on metatable vs nil-object has no metatable as a purely debugging aid.

There doesn't need to be more complexity, for example the check for a
__close metamethod when the to-be-closed variable is defined could be
removed altogether.  The programmer will find out anyway when the
variable goes out of scope.

Also I am not saying the semantics should be changed, I am interested
in the considerations that made them what they are.

Regards,

-- 
Arnaud