develooper Front page | perl.perl6.language | Postings from August 2001

Re: Will subroutine signatures apply to methods in Perl6

Thread Previous | Thread Next
Uri Guttman
August 24, 2001 21:31
Re: Will subroutine signatures apply to methods in Perl6
Message ID:
>>>>> "BD" == Brent Dax <> writes:

  BD> #   BD> 	my $;			#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;
  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 $;	#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

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 Guttman  ---------  ----------
SYStems ARCHitecture and Stem Development ------
Search or Offer Perl Jobs  --------------------------

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About