Re: Allow table.keyword rather than table['keyword']?

[Jonathan Goble <jcgoble3@...>]

On Mon, Mar 14, 2016 at 3:32 PM, tomas <tomas@tecgraf.puc-rio.br> wrote:
> Hi
>
>>> As for pros, not allowing keywords in these situations sometimes leads
>>> to situations with contrived names (such as `bit32.band`...), and I
>>> had to uglify my code in the past with `bla.["keyword"]` in situations
>>> where all other uses of bla were nicely `bla.field`. On the other
>>> hand, I wouldn't like the inconsistency of being able to use `x` to
>>> write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
>>> able to use `and` to write `bla.and`, `{ and = 123 }`, `function
>>> and()` but not `and()`.
>>
>>
>> This is the main reason I support this change: because some keywords
>> would otherwise be natural field names in a data table or object.
>> "end" is one that I ran into while developing something for my
>> matchext library, and instead of using "start" and "end" as fields for
>> the start and end positions of a match, I ended up having to use
>> "startpos" and "endpos". The ability to use "end" as a field name
>> would be nice.
>
> But you could use "End" or "END", don't you?
>
> Since I usually do something like:
>
> local gsub = require"string".gsub
>
> It would be natural to try:
>
> local end = require"your_lib".end
>
> Which would not be allowed, I suppose.  Also, I cannot feel comfortable
> writing something like:
>
> {
>   start = function ()
>     ...
>   end,
>   end = function ()
>     ...
>   end,
> }
>
> This seems weird!
>
> Maybe it is just me, but I think Lua is better the way it is :-)
>
> Regards,
> Tomás

In my case, what would be the "end" field isn't a part of the module
table, or a function at all. Rather, some matching functions in the
module table return a single table containing information about the
match, specifically the full match, all captures, and the start
position and end position of the entire match and every capture.

On Mon, Mar 14, 2016 at 3:35 PM, Gary V. Vaughan <gary@vaughan.pe> wrote:
>> On Mar 14, 2016, at 6:42 PM, Jonathan Goble <jcgoble3@gmail.com> wrote:
>>
>> This is the main reason I support this change: because some keywords
>> would otherwise be natural field names in a data table or object.
>> "end" is one that I ran into while developing something for my
>> matchext library, and instead of using "start" and "end" as fields for
>> the start and end positions of a match, I ended up having to use
>> "startpos" and "endpos". The ability to use "end" as a field name
>> would be nice.
>
> Forgive the grammar pedantry, but start & end do not go together anyway; you should use either 'begin' & 'end' or 'start' & 'finish'.
>
> Cheers,
> Gary

Well, if we're going to get pedantic, Thesaurus.com [1] lists "end" as
an antonym of "start". ;-) And this is about start of a match and end
of a match; one would not say "begin of a match" (perhaps "beginning
of a match", but that's unnecessarily long), nor "finish of a match"
(perhaps when talking about the *event* of completing a match, but 1)
"completion" would be clearer in that case and 2) not when talking
about the numerical index of the last string position matched). In
other words, they're being used as nouns here, not verbs.

Also, the Python "re" module's match object uses "start" and "end" for
this purpose. Good enough for me. :-) (Much of this "match table" was
inspired by Python's match objects.)

[1] http://www.thesaurus.com/browse/start