[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Allow table.keyword rather than table['keyword']?
- From: Sean Conner <sean@...>
- Date: Mon, 14 Mar 2016 16:32:22 -0400
It was thus said that the Great Roberto Ierusalimschy once stated:
> > Unless I'm missing something, this wouldn't result in any ambiguous
> > syntax. An identifier, followed by a . or :, followed by a keyword, is
> > never valid syntax under current rules, so treating the keyword in
> > that sequence of tokens as an identifier shouldn't cause problems.
> >
> > So I'm +1 on this. It would be nice to have the ability to do things
> > like _G.end (or _ENV.end). Again, unless I'm missing something (which
> > I very well might be given that I'm currently recovering from a cold
> > that's screwing with my thinking a bit).
>
> If not causing ambiguity is a good enough reason, why stop at reserved
> words? We could as well add all the other tokens, too. None of them
> cause ambiguities:
>
> _G.* _G.% _G.>= _G.< _G.== _G.( _G.] _G:)
My initial reaction was "Gaaaaah! Nooooooo!" but upon further reflection,
this might be okay. You could change the names of the metamethods:
mt.+ = function(a,b) ... end -- __add
mt.* = function(a,b) ... end -- __mul
mt.[ = function(t,k) ... end -- __index
mt.] = function(t,k,v) ... end -- __newindex
mt.# = function(t) .. end -- __len
mt.: = function(self,...) ... end -- __call
mt.} = { ... } -- __metatable
mt." = function(self) ... end -- __tostring
mt.== = function(a,b) .. end -- __eq
mt.{ = function(...) ... end -- __pairs
mt.@ = "name" -- __name
-spc (Yeah, that could work!)