Re: OOBit

[steve donovan <steve.j.donovan@...>]

On Thu, Sep 30, 2010 at 8:16 PM, H. Diedrich <hd2010@eonblast.com> wrote:
> And I am perfectly sure Lua became what it is by being guarded against
> feature bloat and patches.
>
> I appreciate that. But the tone on the list can be improved.

That's true. The list has been a bit bad-tempered since the
switch-over to the new provider, must be a configuration setting ;)

> But I don't want to get a public beating I guess. What for.

Generally that doesn't happen around here. But if you propose a core
change to the language, expect skepticism. A proposer sticks his neck
out, he must have a tough neck, as KHMan observes.

The responses have been like this:
1. I don't like it
2. I personally don't like it. It will confuse people.
3. People must learn the language properly
4. Will it affect performance?
5. It could be useful for someone crafting a Lua dialect for their
purposes; say they have internal clients who don't like colons.

1 is obviously not constructive criticism, 2 is at least honest about
being a personal opinion,

3 comes across as being arrogant, but people do have to learn a new
language and reprogram their heads.  I know that some people have a
limited number of slots for new language features, or they are simply
too busy and goal-oriented to make room for new things.

 4 is the classic engineer's question.

5 is valid enough; I remember showing luajava code to an experienced
Java programmer, he liked it but was turned off by the colons. (At
least luajava _consistently_ uses colons, even for static methods,
which causes another kind of confusion ;))

So there is a place for a OOBit 'power patch', as an alternative to
using closures to get the 'familiar' dot notation.  But then you have
to document this very well, because the dialect will look different
from standard Lua.  And when you bring in an external library, like
luasocket, you have to ensure that the dot notation is enforced,
otherwise you have to explain why some objects use dot and some use
colon.

steve d.