Front page | perl.perl5.porters |
Postings from August 1999
On Mon, Aug 23, 1999 at 04:02:07PM -0400, Ilya Zakharevich wrote:
>Steve Fink writes:
I might as well comment now - after the bulk of the perl conference is done.
Here's to hoping that it doesn't get lost in the POD && XML typhoon..
>> 1. compile-time type checking
>Impossible. You need to chase ISA tree *back* to implement this.
How about 'use ISA' or 'use BASE' and hooks inside both?
The more difficult part I think would be following the class through prototypes,
ie:
my Dog $a = new Dog();
function($a, $a); # syntax error... needs to be a Cat
sub function(Dog $a, Cat $b)
{
}
and to be smart enough to handle overloading, ie:
my Dog $a = new Dog();
function ($a, $a);
sub function(Dog $a, Cat $b)
{
}
sub function(Dog $a, Dog $b) # this calls this instead of the first.
{
}
>> 2. run-time type checking
>> - it's still better to give a type error than to silently do something
>> unexpected. At least, if that's what you ask for. For example, it's
>> better than later complaining about an undefined method, since it
>> catches the original source of the problem and narrows down the set of
>> possible screwups.
>
>Like what? I do not see offhand how one would be able to provide a
>more meaningful error message.
I agree. If you have a class which does NOT have a method, you get
Can't locate object method "C" via package "A" at a.p line 8.
Tells you the package, the type of object the reference is, everything. If you
try to do this with a regular hash you get:
Can't call method "C" on unblessed reference at a.p line 9.
If you try it on a scalar, you get:
Can't call method "C" without a package or object reference at a.p line 9.
On an undefined value:
Can't call method "C" on an undefined value at a.p line 9.
How could these be clarified by strong typing?
>> 3. enabling optimizations
>
>Like *what*?
I agree - like what?
>> 4. more understandable code
>
>Maybe indeed.
well, I find:
my $a = new Dog();
and
my Dog $b = new Dog();
to be just as readable.. True, the second may provide a type check (make sure
$b is a dog after assignment) but usually I handle that like:
my $b = new Dog() || print(STDERR "Couldn't make a new dog!\n");
>> 5. user-defined type coercion
>> ( the programmer may know a better way of converting a Dog to a Cat
>> than the grooming function mentioned above ;)
I don't know, I would think that this would be better at pointing out when a dog
no longer *is* a dog, ie:
my Dog $b = new Dog();
$b = undef; # runtime error. needs to be a dog.
so its equivalent to a built-in watch. But that is a lot of overhead, and I'm
not sure that it is worth it.
Ed
Thread Previous
|
Thread Next