Re: Uppercase-initial globals

[Philippe Verdy <verdyp@...>]

It makes sense, but the two syntaxes have different meanings; name
bindings for the "sub" fonictions will not be looked up in the same
object.
- When you use string.sub(str,...) you perform the name lookup in an
object accessible by the name "string" in the current environment; it
may be the defining class where that function was initially bound, but
not necessarily (remember that "string" itself can be overridden and
is not necessarily the original class in the standard "root" library
provide by the local Lua engine
- when you use the str:sub(...) shortcut, you are actually calling
str.sub(str,...) and you lookup the "sub" function that has been bound
to the "str" object (hopefully an instance of the "string" class, but
also not necessarily in the "root" standard library). That function
may have been overridden for the instance itself, even if that object
referenced by the "str" varaible was initially created using the
"string" class.

In my opinion "str:sub(...)" is better for genericity (even if you can
also use the equivalent "str.sub(str, ...)", but at the cost of two
variable lookups for "str" in the local environment; but a decent
engine could optimize these lookups when they occur in the same
expression with no possible change of value (e.g. as a side effect of
dereferencing "str", for which the order of evaluation of the
expression to perform the 2 lookups may be significant: that Lua
engine will then have to see if the local environment overrides the
default variable lookup using a custom "rawget" or not; if "rawget"
has been overriden in the local environment, it is unsafe to replace
"str:sub(...) by "str.sub(str, ...)", unless Lua does not specify in
which order the lookups are performed, so that you get "unspecified
behavior" for such expression "str.sub(str,...)", but NOT when using
"str:sub(...)" because the lookup for "str" will be performed only
onced and cached in a hidden local variable, as if you had written
"(local tmp=str; tmp.sub(tmp, ...))", using a syntax still not allowed
in Lua where you can create local variables inside subexpressions
between parentheses, or called a lambda-expression like
"(function(...) local tmp=str; return tmp.sub(...))(other parameters)"
(a ugly way to do the equivalent using an anonymous function, but much
less clearly than using local variable declarations inside
subexpressions).

Le mer. 22 juin 2022 à 16:09, Javier Guerra Giraldez
<javier@guerrag.com> a écrit :
>
> On Wed, 22 Jun 2022 at 08:50, Flyer31 Test <flyer31@googlemail.com> wrote:
> >
> > On Wed, Jun 22, 2022 at 10:22 AM Egor Skriptunoff
> > <egor.skriptunoff@gmail.com> wrote:
> > >
> > > A question about Lua coding style.
> > > Is it a good or bad idea to distinguish global from local variables by its uppercase / lowercase initial letter?
> > > https://stackoverflow.com/questions/72710110/uppercase-or-lowercase-for-global-variables
> >
> > ... as I also use Visual Code for Coding (as your stackoverflow link),
> > I adapted to this.
>
> so, a given editor invents some "convention" (that i've never heard of)....
>
> > Only thing which is a BIT nerving in Visual Code: It will signify the
> > ":" operator as yellow curly error. (e. g. str:sub(1,4) will give
> > yellow warning, string.sub(str, 1, 4) will be fine).
>
> ... but don't implement actual syntax
>
>
> does it make any sense?
>
> --
> Javier