lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


On 27-Aug-05, at 9:58 AM, Chris Marrin wrote:
Couldn't you have a rule that first tried the first way and if that did not work (because there is not __tonumber metamethod for that object, for instance) you would try __add? I agree that __add is needed for things like complex numbers. I don't happen to have that issue, though.
But why should you prefer __tonumber to __add? That's an entirely problem-domain-specific preference. Put another way, if my primary concern were complex numbers but I accepted that you also had an application, I might say, try __add and then try __tonumber :)
In any event, I'm generally of the opinion that coercions should be explicit; I'd be happier if 3+"2" where an error. I have learned the hard way that not doing numeric conversions explicitly leads to obscure bugs: 

-- in main, get a numeric argument from the command line
  local nrepetitions = arg[1]
  for i = 1, nrepetitions do
    handle_case(i)
    print_separator()
  end
-- No problem, right?
But someone notices that there is an extra separator at the end of the output. So we change it: 

- print_separator()
+ if i ~= nrepetitions then print_separator() end

Oops.

Now, if I'd been less lazy and originally written:
local nrepetitions = assert(tonumber(arg[1], "Option must be a number")) 

That would have completely avoided the contretemps
But for all intents and purposes an SFBoolean object IS a boolean primitive. The extra features that SFBoolean provides has nothing to do with its data type, only with how it can interact with other properties in the system. What I really want is for Lua not to judge me for how I want to coerce the object system :-)
That's fine. But presumably there are only two singleton members, SFTrue and SFFalse (or am I prejudging your Boolean system? :) Relating two enums to each other doesn't seem to me to be that painful.
This brings up what seems to be a dirty word here and many other language oriented places, Javascript. I say that because I see people all over the place mention the "top languages" as Python, C++, Java, event Self (which I have taken to be a codeword for Javascript).
Let me be clear that when I mention "Self" I mean "Self" :) (And I have some fondness for Javascript, but I think that Lua generally made better choices.)
I'm not sure why that it. Is it because Javascript has been erroneously associated with Java by its poor naming, or is it because people don't like to type ECMAScript, or is it because it has to much of the cachet of that other persona non grata language, Basic? It's almost like saying Voldemort in the Harry Potter books! But it is one of the most popular languages in existance, given the millions of web pages it appears on.
It certainly has one of the highest (lines copied)/(lines written) ratios of the languages I know. I call that the cargo cult quotient (CCQ). My hunch is that CCQ(Javascript) ==~ 2 * CCQ(VisualBasic) ==~ several orders of magnitude * CCQ(C).
I think javascript's reputation mostly suffers from inconsistency of implementation. The project to provide formal semantics for javascript is a good start at a solution. Formal semantics for standard libraries (or host classes, if you prefer) would be another big step. But we'd still end up spending our time writing workarounds for browser bugs and legacy browsers. And that is the aftertaste that most of us remember from javascript, I think.
Anyway, many of these concepts come from The-Language-That-Must-Not-Be-Named.
Yes, I recognized them. I think they are unintuitive in javascript as well, but that's not my primary irritation with javascript.
Since you asked (sort of), let me list them (along with some sideways glances at python):
1) Javascript has no mechanism for implementing a metaobject protocol. Lua's may not be perfect, but it goes a long way.
2) Javascript has no pure association-tables ("dictionaries"), only objects, and therefore you cannot change Object methods for a dictionary without possible odd consequences. While you could criticise lua for not having pure objects, only association-tables, it at least lets you use a dictionary as a dictionary, damnit. But then you can't use O-O style with that dictionary. Python probably comes closer to getting this right, but it really ought to return none for non-existent keys rather than throwing an exception. Python is trigger-happy, exception-wise.
3) Javascript does not allow arbitrary objects to be used as associative keys. (Neither does python. Why not?) Once you get used to being able to do this, any language which doesn't provide the feature feels second-rate.
4) Javascript's scopes try to combine the "best of" dynamic and static scoping, and as a result require a Doctorate in Javascriptology in order to cope with corner cases. Python is even worse. Lua scopes may not be the be-all and end-all (I would like dynamic scoping once in a blue moon), but you can describe the entire semantics in a paragraph.