> I'm incredibly leery of
> putting two distinct OO mechanisms into Perl. That *won't* satisfy the
> OO purists or those who need guaranteed security.
>
> And I'm *really* against . as an attribute access mechanism :-)
This is my stance as well.
One thing to remember is that we're ripping the internals out
completely. This means we can redo everything, including the fact that
Perl OO is basically "bolted onto the side" as you mention (it is,
indeed).
I absolutely hate . as well. I always have, even in other languages. The
-> notation is much clearer that "hey, we're doing something with a
member attribute".
If what you're looking for is something like this:
$foo->bar = "hello"; # ignoring if bar() is a func, or hash, or
???
I don't see why we can't do that. Just rewrite the internals (hey, we're
doing that anyways!). And personally, I'm for this type of thing because
you can say:
($foo->bar, $foo->bar2) = split;
Without having to worry "is it a function? hash? array?". And we can
still leave:
$foo::bar = "scalar";
@foo::bar = ("array");
For people that want tight control over this stuff.
I agree with Damian. I think the idea of putting two distinct OO methods
in Perl is a very bad idea, at best. Fixing some stuff about the current
mechanism is, however, a very good idea. I think the RFC would be much
better spent if it listed annoyances and proposed fixes, rather than a
second whole OO scheme. Remember, we're trying to *decrease* bloat here.
:-)
I wouldn't worry about breaking stuff at this point. That's a next-stage
decision - benefits vs. costs. We're still in the "developing ideas"
stage. Remember, we're got conversion scripts, FAQs, Camel-4, and lots
of other ways to bring people up to date on changes.
-Nate
