On <close> and <const>

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

On <close> and <const>

Rodrigo Azevedo
Why not use a simpler model for <close> variables as a simple
mechanism of a predictable call of __close() from its respective
value?

e.g.:

do
  local x <close> =  whatever
  x = something -- it's OK
  local y <const,close>  = true
  -- y = false -- compile-time error

  -- going out-of-scope
  -- call __close(), if it exists, from 'something' value.
  -- call __close(), if it exists, from 'true' value.
end -- end-of-scope

Namely, it does not imply <const> or checks before variables are out-of-scope.
If we want <const>, just explicitly declares it.

--
Rodrigo Azevedo Moreira da Silva

Reply | Threaded
Open this post in threaded view
|

Re: On <close> and <const>

Coda Highland


On Sat, Oct 5, 2019 at 8:43 AM Rodrigo Azevedo <[hidden email]> wrote:
Why not use a simpler model for <close> variables as a simple
mechanism of a predictable call of __close() from its respective
value?

e.g.:

do
  local x <close> =  whatever
  x = something -- it's OK
  local y <const,close>  = true
  -- y = false -- compile-time error

  -- going out-of-scope
  -- call __close(), if it exists, from 'something' value.
  -- call __close(), if it exists, from 'true' value.
end -- end-of-scope

Namely, it does not imply <const> or checks before variables are out-of-scope.
If we want <const>, just explicitly declares it.


We rehashed these arguments many, many times already.

Short version: performance and robustness. It simply works better to set up the on-exit behaviors right away, and you can do most of the work at compile time. In light of that, making it const is meant to prevent nasty surprises.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: On <close> and <const>

Philippe Verdy
In reply to this post by Rodrigo Azevedo
Note that the syntax <const,close> is still not allowed in the current beta doc, which allows a single optional attribute between angle brackets (the comma is not described or may be reserved for later addition of attribute-specific parameters) and also does not allow adding multiple bracketed notations if there are multiple attributes.


Le sam. 5 oct. 2019 à 15:42, Rodrigo Azevedo <[hidden email]> a écrit :
Why not use a simpler model for <close> variables as a simple
mechanism of a predictable call of __close() from its respective
value?

e.g.:

do
  local x <close> =  whatever
  x = something -- it's OK
  local y <const,close>  = true
  -- y = false -- compile-time error

  -- going out-of-scope
  -- call __close(), if it exists, from 'something' value.
  -- call __close(), if it exists, from 'true' value.
end -- end-of-scope

Namely, it does not imply <const> or checks before variables are out-of-scope.
If we want <const>, just explicitly declares it.

--
Rodrigo Azevedo Moreira da Silva