On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
> First greatly stylistic compatibilty.  An inexperienced programmer would
> see:
> my Dog $spot = "Spot";
> 
> And become confused.  It's totally unintuitive (at least so far as other
> mainstream OO languages go).  It looks like Dog could be a type of String
> subclass.

Granted, the my Dog $spot = "Spot" example is a little confusing.  In this
specific example it doesn't make much sense to assign a value in this way. 
Consider, however, types:

    my int $i = 4;
    my float $f = 8.5e10;

possibly even (and I'm making syntax up here):

    my int ($x, $y, $z) = (4, 5, 6);


This general syntax is not entirely unseen, consider C:

    int x = 4;
    int x = 4, y = 5, z = 6;

or C++:

    string foo = "bar";

The latter being an overload of the assignment operator; any arbitrary value
could be there, provided you have an overload that matches it.  It's up to
the author of the library (or module) to make it make sense.

 
> The next most important point is that, up until this point, there has been
> no enforcement of the constructor name (nor for the $self name).  This
> obviously requires it.  Now there have been numerous discussions about RFCs
> that required such standardization.  Some stronger than others.  I don't
> think that this alone is a strong enough case to break backward
> compatibility (with things like DBI->connect).

The constructor name is only forced (if it's not author-controlled) when
using the my Dog $spot syntax.  my $spot = Dog->new() isn't going anywhere.


> As with the above, the problem you are trying to solve is long type-names
> (which is a bazzar thing to find in perl anyway).  I just think that there
> are better ways of skinning that cat.

Well, if it were only long type names I'm trying to solve, Doug MacEachern
submitted a patch that provides for:

    my __PACKAGE__ $spot = Animal::Mammal::Canine->new();

to be the equivalent long version.  (At least, that's what I think it's
supposed to do.) I was going for more elegance and simplicity, especially in
the case of specifying types.  Perhaps you can suggest some alternatives? :)


Michael
--
Administrator                      www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

Reply via email to