Why no number methods?

[Magnus Lie Hetland]

> From: "Paul Foley" <mycroft at actrix.gen.nz>
>
> On Mon, 14 May 2001 12:39:31 +0200, Magnus Lie Hetland wrote:
>
> Why would you have to avoid numbers and arithmetic?

Not entirely. Just for the first few examples, because I was
hoping to use a very simple and consistent syntax (like that
of the object calculus of Abadi and Cardelli, mentioned
before).

I just thought it would be nice to show the general mechanism,
and then show how "1+2" is a just syntactic sugar/a special
case etc. Of course, that's not how it is today. (Although
I'm sure it's dead easy to understand, even for 100% newbies.)

> Have you been brainwashed into thinking that something's only OO if
> you can use some foo.bar() nonsense?

Whoa! Now _there's_ a loeaded question. I'll politely answer
"no", and leave it at that.

> That's not only not true, but
> it's actually anti-true -- it's *more* OO to write bar(foo) than
> foo.bar()

Really? Now that's interesting. I would have thought that neither
was "more" object-oriented than the other. As far as I know,
object-orientedness has little to do with syntax...

What was thinking about was a minimal basic syntax (i.e. you
have literals, names and method calls -- and that's it). If
I am to use that now, I can't do arithmetic, for instance.
It's as simple as that.

It was just a thought. Not really an important feature of the
language, I guess...

> [not in Python/C++/etc., because they don't do run-time
> dispatch in that case, unless you write "def bar(x): x.bar()" or
> something, which is a bit pointless, but in a more general sense]

OK. So which languages are you referring to, and why do you think
bar(foo) is more object-oriented than foo.bar()? To me, the former
connotes a function which is defined separately from the argument;
in Haskell and Prolog I would see it differently, but neither is
known for being object-oriented at their core. (Sure, you could
do OO in any turing-complete language, but ...)

Scheme/Lisp (w/CLOS)? Is that your ideal?

> [Note, too, that 1.add(2) can't be made internally consistent in
> general (it needs to be covariant on both arguments, but Python
> doesn't work like that -- the same problem exists for the + operator
> on user-defined objects (via __add__ methods), of course, but at least
> it can know about the various built-in numeric types and do the right
> thing, which a 1.add() method would break)]

Why would it break that? How is this broken in SmallTalk or Ruby,
for instance? (Just curious.)

> > Well, well. Anyone care to explain why this is difficult
> > or horribly difficult to implement?
>
> It isn't.  I don't think Guido would accept it, though (that is, I
> hope not!)

Well -- numbers will eventually be objects with classes (deal with it).
Whether they'll have methods I don't know. I was just hoping that
the methods could be added preliminary (as with strings), before
the long-awaited Python 3000...

Anyway, thanks for your interesting (and somewhat caustic) comments :)

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick