2000-09-27-21:53:34 Michael Fowler:
> You can ask "why?" (or "why not?") until you're blue in the face,
> and the question would still be valid. He just doesn't want to,
> nor do I.
We may have a misunderstanding here about what "it" is.
> If $str = "foo" and m/foo/ are somehow magical objects, that's
> fine, as long as it doesn't impact my not wanting to use them as
> objects. That'd be some feat, but if you can manage it, more
> power to you.
I think that's the proposal in this RFC, and it doesn't seem at all
tricky; rather, it seems like a simplifying unification, removing
some special-cases that are currently hard-coded into the language
that don't turn out to buy performance, replacing them with
syntactic sugar to keep the old non-OO expressions working.
> Everytime I see the title "Everything in Perl becomes an object" I
> groan and have to wonder exactly what the point is.
If everything is an object, then you can take control over how new
objects interact with existing scalars when overloading expressions
using the existing overloading tools, lightly seasoned with
inheritence. That's the hope, anyway:-).
> OO is a neat tool, sometimes, but Perl has done rather well
> without having objects -everywhere-, and I like my Perl pretty
> much the way it is.
I like perl just the way it is quite a lot. I think I'd like it more
with fewer special cases buried in it, and less inflexibility
starched in around them. Right now there are builtins that look like
functions but that that can't be wrapped, and there's this bizarre
and slow "tie" thing that does much of what object overloading and
inheritence does with a different syntax and distressing
performance. Turning tie into a backward-compatibility syntactic
sugar for a simple inherited class would be awfully nice.
-Bennett
PGP signature
