On Aug 13, 2:08pm, Nathan Wiger wrote:
> 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".
Yep, whatever. The syntax shouldn't really be an issue here. It was
proposed to be something different to '->' to distinguish them apart,
and because I didn't want to think fully through the implications of
overloading '->' (for now at least). The operator could be anything,
including '.' or '->', both of which I find reassuringly familiar.
I should also point out that I *don't* like Java much and consider the
dot operator to have had a long and varied history *before* Java got
their hands on it (C structures for example) :-)=
> If what you're looking for is something like this:
>
> $foo->bar = "hello"; # ignoring if bar() is a func, or hash, or
Yes, that's essentially one of the things I'm proposing. I also propose
that classes should be well ordered to allow offsets to be calculated
at compile time (like C structs) rather than at runtime (like Perl
hashes) or via explicit method calls (comparably very slow). I'd also
like to be told by the compiler that I've accessed a non-existant
variable or method, rather than waiting until runtime for a piece of
wrapper Perl code to tell me. I'd also like to be able to inherit
from other classes/packages in a safe manner and have most, if not all
of the initialisation done for me in a predicatable fashion, unless I
chose to override it, of course. And so on. There's more to it than
just some fancy new package options, but admittedly the RFC is something
of a brain dump in which the important points seem to get lost.
There's an important difference in the multiplicity between classes
and object and that of packages and typeglobs. In Perl 5, a package
is, if you like, the abstract concept of which a typeglob is the
concrete manifestation. We think of it as a namespace while Perl
represents it as a hash table. There is a 1:1 mapping between
packages and typeglobs.
On the other hand, a class is the abstract concept of which an object
is a manifestation, and there is a 1:many mapping. We can have many
instances of an object which all conform to a particular blueprint.
So think of a class as a new kind of package which we can use to
instantiate objects. Other than that, they're fairly similar. They're
lookup tables (aka vtables) for variables and subroutines related to a
particular namespace.
In Perl 5 we represent objects as references blessed into a particular
package. This allows the methods (package sub-routines) to be
correctly located, but doesn't do anything to manage your object data.
This you must store in a hash, or if you're efficiency conscious, an
array, or some other kind of structure. You can also monkey around
with lexical variables, providing, or automatically building accessor
methods. All neat solutions, I admit, but I personally don't think
that building additional, elaborate mechanisms around your objects in
Perl space is the best way to do it. Providing them with wrappers
within wrappers adds to complexity of the software and can severely
hamper performance.
I know that we can do these things in many different ways with existing
modules from CPAN, and I'm all in favour of keeping as much out of the
core as possible. However, I think the time has come to put something
in the core to support this, even if it's just the relevant hooks to
allow modules to step in as necessary.
> I agree with Damian. I think the idea of putting two distinct OO methods
> in Perl is a very bad idea, at best.
If some of these concepts could get integrated into a wonderfully
advanced and globally cool namespace facility, then so much the
better. At the moment, I've only got 'package' to work on, and
the 'class' concept is, significantly different, IMHO, as to warrant
a new "working title" for now. Nevertheless, I accept the above point.
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
