Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
On Tue, Aug 29, 2000 at 12:57:07PM -0700, Matt Youell wrote:
So perhaps sometimes in Perl we could say:
my Dog $spot = undef;# Automagically knows to be a Dog ref instead
of a Dog object because of the undef.
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
That's a little too special-case and magical for my tastes. What if the
programmer really wants to call the constructor with an undef argument? Or
what if the programmer calls my Dog $spot = $foo, expecting $foo to be
defined, but it isn't? That would end up being a difficult to trace bug.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
Eeeeww. Most of the time I use 'my Dog $spot' is along the lines
of:
package Dog;
sub bark {
my Dog $self = shift;
print $self-name, " barks!\n";
}
package Main;
my Dog $spot = Dog::Dalmation-new(name = 'Spot');
$spot-bark;
Or what about:
my Dog $patches = $dog_pound-get_cute_stray;
There's a whole host of occasions when you want 'my Dog $spot' but you
*don't* want $spot to be set to Dog-new.
--
Piers
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
Jonathan Scott Duff wrote:
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.
Why would the programmer become confused? In C++ (a mainstream OO
language), if a Dog constructor was defined that took a string as an
argument, the string would be auto-converted to a Dog.
So, if this were adopted for Perl, the programmer would know that the
class constructor for Dog would be called to instantiate $spot, then,
because of the assignment, the Dog-STORE() method would be called.
And if the programmer were inexperienced, it would be a perfect time
for them to learn something.
Note that in C++ this can be sufficiently confusing that the 'explicit'
keyword is required to mark constructors as "do not use them for this
kind of behavior".
Many people see even this as a bad choice, saying that 'explicit' should
be the default, and that C++ constructors should be marked 'implicit'
for this behavior to be allowed.
Anyway, what's wrong with:
my Dog $spot = Dog-new("Spot");
as that scales to
my Animal $spot = Dog-new("Spot");
my Dog $fifi = PersistentDog-restoreFromDatabase("fifi");
and others - i.e., it does not impose policy on the poor user.
Hildo
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
What, then, happens to the following code:
my Dog $spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
This is a tricky case that deserves a lot of attention, but not exactly
as written. Imagine this code block:
my int ($x, $y, $z) = (4, 5, 6);
if ( $x $y ) {
$x = $z;
}
That seems like simple enough code. But what would that = line do?
$x = $z; # $x-STORE($z)
That doesn't make any sense, because $z is an object of class int, and
not a number.
I'd propose the following precedence rules for assignment:
1. If it's an object being assigned, then the old object
gets overwritten
2. If it's a simple value being assigned, then -STORE
is called
So for example:
my int ($x, $y, $z) = (4, 5, 6);
if ( $x $y ) {
$x = $z; # $x overwritten
$y = "15"; # $y-STORE(15)
}
That's off the top of my head. Any input? This point should probably be
addressed in the RFC in one way or another.
-Nate
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
Right now, the default behavior of perl is that un-initialized variables
are automatically undef. It would be weird to have to do explicit
assignment of an variable to say so.
You're right. And as another post mentioned, it's too much "magic". But It's
hard to come up with a comfortable syntax for doing both.
In C++, you've got two syntaxes for a reason: Objects either live on the
stack or the heap. So each syntax has a direct under-the-hood correlation to
the different ways of storing an object. I Perl, we don't really care where
the object gets stored so it's not as natural to make the distinction.
Perhaps the shift-on-the-fly usage could explicitly use a typeglob syntax
and declare it to be associated with Dog?
my Dog *spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
Matt
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
mainstream OO languages go). It looks like Dog could be a type of String
subclass.
That was my first thought as well. Besides, I'd rather type:
my Dog $spot("Spot");
Which says everything that needs to be said without any repetition, and it's
fairly intuitive.
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.
I think the main idea here is this: being allowed to say what you mean
without repeating yourself.
Matt
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
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 --
