I disagree with this in so many places that I don't really know where to
start...
First, I do agree with the view perl should have better support for
classes. Also, should the author want to, protection features from C++
(or other B&D languages) should be supported optionally.
> NOTE: these and other examples assume Highlander Variables (RFC 9)
> where '$mage', '@mage' and '%mage' all refer to different "views" of
> the same variable, rather than different variables as in Perl 5.
> Otherwise read '@mage' as '@$mage' and '%mage' as '%$mage'.
The implementation of a class should be invisible to the outside, so
details like this should not matter.
>
> When it comes to creating objects, a hash is the most common choice of
> structure for blessing as it offers the most versatility. However,
> you can get faster access and use less memory by using a list. The
> downside is that you lose the ability to reference items by name.
> A pseudo-hash provides the efficency of a list with the convenience of
> hash.
Why not take this a step further? Let's propose that, once you define a
class, perl will use some efficient implementation that allows named
access to the class and object data members. All other access (as
array, hash, whatever) is forbidden, allowing perl to take whatever
internal implementation it sees fit.
>> =head2 Defining a class
>
> The new C<class> keyword is proposed for defining an object class.
> This can be thought of as a special kind of C<package>. Lexical
> variables defined within the scope of a class declaration become
> attributes (or data members) of that class. The existing C<my>
> keyword indicates per-instance variables while C<our> is used to
> create class variables which are shared across all instances of a
> given class
>
> class Person;
> our $home = 'Middle Earth'; # class variable
> my ($name, $race, @aliases); # object (instance) variables
>
> The class definition would continue until the next C<class> or
> C<package> declaration, or until the end of the current file.
> Class definitions can be re-opened and extended.
Oh dear. Re-opening a class leads to trouble - not just for editors,
debuggers and class browsers, but also for the compiler, which can
generate code right from the point the class definition closes. Why not
allow forward class declarations and require all of a class to be
defined at one point? What feature requiers re-opening a class?
> =head2 Accessing variables and methods
>
> Object variables are accessed using the familiar C<-E<gt>> operator.
>
> print $mage->name, " has ",
> scalar @mage->aliases, " aliases\n";
Object variables should never be visible to the outside world unless
accessor functions have been declared. Even then, objects that define
accessors for all object variables are typically indicative of poor
design. The only access to object variables should be within the class
and, for designated member variables, to derived classes.
> =head2 Inheritance
>
> As with the existing C<use base>/C<use fields> pragmata, Perl 6
> classes should support single, linear inheritance only. Multiple
> inheritance is generally more trouble than it's worth.
Yuck. MI is useful though sometimes abused, and even (cough) Java
supports multiple inheritance of interfaces. There is existing perl5
code using mulitple inheritance that we should be able to support in
perl 6.
> =head2 Constructor Methods
>
> The default class constructor method, new(), should be available if
> otherwise undefined in the class. It should instantiate an empty
> object (via C<class::new()>), assign any parameters to object
> variables and then call any per-object initialisation method, NEW()
> (or _new()?). Base class NEW() constructors should be called in
> order. Note that the C<$class> variable should be correctly defined
> in the base class (e.g. Person) to contain the name of the derived
> class (User).
This is undesirable policy that should not be imposed on the coder. In
my persistent object package, objects are created using Build() or
Restore(). If I don't want to give the users a new() method, I should
be able to do so - without having to create a 'this is not a new'
method. This also comes up when defining Factory or Singleton classes.
Hildo
