Re: [ANN] Lua 5.2.0 (alpha-rc2) now available

[Lorenzo Donati <lorenzodonatibz@...>]

KHMan wrote:
> To me it's just a library. No different from the rest. Why does it have 
> to look different? We did fine before with lower case.
>
> Leaving aside the aliasing, many people are attuned to having all caps 
> as constants.
[snip]
> ...[snip] and one becomes attuned to quickly scanning source code 
> patterns in that way. [snip]...

I agree on that. For me code readability is paramount (I rarely need 
extreme performance, so my focus is biased).

Especially when scanning visually large sections of code, an all caps 
identifier shouts to my brain "I'm a CONSTANT!". If a function had such 
a name I will lose some milliseconds ( :-) )in telling my brain "hold 
on! It's just bit32 stuff".
It's not really a pain, but it's a huge "distractor", ie. background 
noise. No showstopper at all, sure, and human minds are flexible enough 
to adapt, with time, but ... why this useless exercise? _ENV had to be 
ugly on purpose (I totally agree), but bit operations?
If ugliness has a purpose, it should be that of telling the coder 
"BEWARE! You are walking on thin ice! Know what you are doing!"

After all, if the answer is "you can rename that", well, we can also 
have bit32.bit_and or lua_bit_library_32.BIT_AND or whatever (and for 
the same reasons also string.match_iter or matchiter instead of gmatch - 
what is "global" here?!?).

As KHMan hinted, there is some "mental" overhead in renaming things (and 
some organizational too - different projects - different coders - so you 
must establish a convention to rename things all the same), so it should 
be a practice IMHO limited to places where you have got no (easy) 
alternative.

Since bit32 is a new library, there is no legacy burden (beside possible 
clashes with Mike Pall's bitlib), why adding noise and inconvenience?

Many people on this list have suggested some alternatives (me too - I 
must admit).
I don't see any advantage of having all caps AND instead of _and or 
b_and (ruling out "band" to avoid clashes with bitlib, If I got it 
right). They all sucks, in a way, but since also lhf said that AND 
sucks, well ... IMHO I think:
_and, b_and
or even:
and32, and_,  __and__ (only 1 leading + 1 trailing underscore intended - 
my client insists on underlining)
suck a bit less (no pun intended), and they are less "noisy".

--
Lorenzo