>>>>> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> # BD> my $rex=Dog.new; #ok at
BD> # this point...
BD> #
BD> # BD> $spot.bark(); #ok
BD> # BD> $fido.bark(); #ok
BD> # BD> $rex.bark(); #ERROR: $rex
BD> # isn't declared to hold an object
BD> #
BD> # is that a compile time or runtime error? i don't think you can make it
BD> # compile time since $rex can be assigned a real object and
BD> # still call the
BD> # bark method.
BD> Compile-time error. $rex was assigned a real object with Dog.new;
BD> however, $rex wasn't _declared_ to be holding an object of any kind.
BD> Thus, we can say at compile time that $rex can't bark since $rex isn't
BD> supposed to have an object in it.
then it should be a compile time error at the assignment to $rex and not
later. you can't trace $rex at compile time to see what kind of object
(if any) was assigned to it. so the illegal method call can't (easily)
be detected at compile time. it has to be a runtime error. the
assignment can be detected at compile time. what that means is that
objects can only be assigned to scalars that are declared to be that
type. i don't think that is needed for plain scalars though.
BD> # BD> 2. A 'normal' type:
BD> #
BD> # BD> use strict 'typing';
BD> # BD> my Dog $spot=Dog.new; #ok
BD> # BD> my $foo="bar"; #bad--no type on $foo
BD> # BD> my val $baz="quux"; #ok
BD> #
BD> # BD> I'm not necessarily suggesting 'val' as a type,
BD> # however--that's just a
BD> # BD> placeholder for whatever we would choose.
BD> #
BD> # i don't like that. plain perl scalars should always be
BD> # allowed even when
BD> # while odd pragmata are in effect.
BD> OTOH, we did invoke strict 'typing' so we would need to give types. It
BD> kinda makes sense that you would need to specify a normal type, so you
BD> don't accidentally forget to put a type in when you meant to.
but types on all scalars is too much. making it types only on scalars
that directly get assigned objects is ok.
BD> # no, that won't work. you can always bypass that at runtime in too many
BD> # ways. as damian stated, runtime checks for objects are always in
BD> # effect. if a method isn't found or handled by AUTOLOAD or something it
BD> # is fatal (unless caught, of course). the method itself will
BD> # always need
BD> # to check its arguments if it cares about whether a class or object is
BD> # the invocant (i like that word. thanx, damian!).
BD> I'm not sure if you understood what I meant there. I meant that,
BD> if we know $spot is supposed to have a Dog in it, can we avoid
BD> checking if it really does (at least some of the time) and maybe
BD> shuck some overhead by doing so? Perhaps we only check after each
BD> assignment to $spot, and when we check we set a flag saying that
BD> it's already been typechecked so we don't have to do it again.
BD> Whatever, methinks I may optimizing too early. We all know what
BD> Knuth says about that.
i agree with knuth here. :) and i understood what you meant. i was
saying that it is the method sub itself that worries about how it gets
called. and since the compiler can't track how a given object is
assigned to a scalar, it can't make sure a method ALWAYS gets called
correctly. you can always break method calls with a fully qualified sub
call and then the method should still work if it is passed decent
params.
you seem to be conflating what can and should be done at compile time
and at runtime. perl has so many runtime backdoors, that you can't ever
guard a method and assure (at compile time) it will always be called
correctly. so what our goal here is to allow stronger (or any!) compile
time typing and checking in relatively normal (as other languages see
it) cases with better sub and method signatures. any of these checks can
so easily be circumvented that method writing should still be as
defensive as they are (or should be) now.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
