Re: Attributes
Pier <[email protected]> Wed, 27 May 2026 19:21:21 -0700 (PDT)
| Newsgroups | gmane.comp.lang.lua.general |
|---|---|
| Message-ID | <[email protected]> |
If this were any other langauge I would likely agree with you because other langauges are heavily bloated. However, we're talking about an extremely small language (when compared to other modern languages) so my stance is that every new feature should earn a practical purpose. I don't see <const> as that because I feel the standard SNAKE_CASE is sufficient enough, not only because it stands out in a sea of keywords and other variables but it doesn't require you to remember its declaration beside its value, hopefully that makes sense. For contrast, the <close> attribute is a genuinely good addition because of its its practicality and solves a real frustration with lua regrading resource cleanup. And I will admit, the immutable table part was a bad idea in hindsight so I will agree with you and others (like lars) that extending the table library to have a freeze method is a much better idea. On Tuesday, May 26, 2026 at 1:46:36 PM UTC-4 Martin Eden wrote: > On 2026-05-24 19:34, Pier wrote: > > I absolutely love Lua for how easy it is to learn, how clean the > > syntax is, and how extendable it is. However, I do have a few thoughts > > on attributes which was in introduced in Lua 5.4 that I think deserve > > a good discussion maybe. > > > > The concept itself is not bad and the syntax is a fair compromise. The > > close attribute is amazing when working with systems where freeing > > memory is important but easily overlooked or forgotten (i.e. closing > > files). On the other hand, the const attribute is just... meh. I don't > > see any reason to include it, because as far as I know it doesn't add > > any performance and, importantly, it doesn't make tables immutable! > > The SNAKE_CASE convention to me is more than enough to denote > > constants. I hold onto the belief that developers are component enough > > to not make stupid mistakes such as changing variables that aren't > > supposed to be changed or changing variables in an unexpected way. > > Even if that does happen, they are usually caught through pull-request > > or during test. I don't know many teams that allow anyone to change > > the codebase freely. > > > > I guess for const to be useful it would have to add some extra benefit > > than just protection. I am no compiler designer, but if I had to come > > up with something I would say constant tables could be immutable and > > optimized internally since the keys would never change, or constant > > variables being expanded. I'm sure there are many ways to go about it. > > > > In the end, I still love Lua lol. Maybe I'm missing some context or > > something, so I'm always happy to continue the discussion on this topic. > > -- > > You received this message because you are subscribed to the Google > > Groups "lua-l" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected]. > > To view this discussion visit > > > https://groups.google.com/d/msgid/lua-l/a7fc6ef3-698e-4857-8603-66a3474f1f0bn%40googlegroups.com > > < > https://groups.google.com/d/msgid/lua-l/a7fc6ef3-698e-4857-8603-66a3474f1f0bn%40googlegroups.com?utm_medium=email&utm_source=footer > >. > > In the language plane Lua 5.4 added optional "attribute" element to > variable declaration: > > stat ::= local attnamelist [‘=’ explist] > attnamelist ::= Name attrib {‘,’ Name attrib} > attrib ::= [‘<’ Name ‘>’] > > Lua 5.5 allowed attribute to precede variable name: > > attnamelist ::= [attrib] Name [attrib] {‘,’ Name [attrib]} > > What "Name" here is implementation details. > > Since 5.4 implementation-supported attributes are "const" and "close". > > How good is support for "const" attribute is again implementation detail. > > From my usage experience of "<const>" in my code: > > * "<const>" is always in "local <const>" > > More clutter but code is actually more verifiable: > > If you see "local <const>" it means that we're just captured > value under convenient name. There would be no hanky-panky with > that value in code. > > Cases when we have just "local" are rare as is signal to > divert attention to code. > > * "<const>" breaks Lua 5.3 which is mainstream "pure Lua" for me > > If you're using Lua 5.3 library your new 5.5 code will break > there. So I just reverted my development from v5.5 to v5.3. > > > > The SNAKE_CASE convention to me is more than enough to denote constants. > > CAPPED_SNAKE_CASE is ugly abomination of ancient times! Well, it still > makes > sense if you're working with paper listings from text printer in 2026. > > > I don't see any reason to include it, because > > [...] > > it doesn't make tables immutable! > > "<const>" is declaration-time attribute. Making tables immutable since > declaration is a big overshoot. Proposed "table.freeze()" suits a lot > better. > > -- Martin > > -- You received this message because you are subscribed to the Google Groups "lua-l" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/lua-l/5436f0c3-e778-4cbe-b05d-221ca9a85f36n%40googlegroups.com.