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

RE: Will subroutine signatures apply to methods in Perl6

Thread Previous | Thread Next
From:
Brent Dax
Date:
August 25, 2001 02:57
Subject:
RE: Will subroutine signatures apply to methods in Perl6
Message ID:
FJELLKOPEAGHOOODKEDPCEHGCEAA.brentdax@cpan.org

# -----Original Message-----
# From: Uri Guttman [mailto:uri@sysarch.com]
# Sent: Friday, August 24, 2001 8:56 PM
# To: brentdax@cpan.org
# Cc: perl6-language@perl.org
# Subject: Re: Will subroutine signatures apply to methods in Perl6
#
#
# >>>>> "BD" == Brent Dax <brentdax@cpan.org> writes:
...
#   BD> Two other possibilities:
#
#   BD> 1. Typing is required on variables which method calls
# are invoked on:
#
#   BD> 	use strict 'typing';		#don't look at
# the keyboard!  :^)
#   BD> 	my Dog $spot=Dog.new;		#ok
#   BD> 	my Dog $fido=new Dog;		#ok
# (indirect-object is staying, right?)
#   BD> 	my $rex=Dog.new;			#ok at
# this point...
#
#   BD> 	$spot.bark();			#ok
#   BD> 	$fido.bark();			#ok
#   BD> 	$rex.bark();			#ERROR: $rex
# isn't declared to hold an object
#
# is that a compile time or runtime error? i don't think you can make it
# compile time since $rex can be assigned a real object and
# still call the
# bark method.

Compile-time error.  $rex was assigned a real object with Dog.new;
however, $rex wasn't _declared_ to be holding an object of any kind.
Thus, we can say at compile time that $rex can't bark since $rex isn't
supposed to have an object in it.

#   BD> 2. A 'normal' type:
#
#   BD> 	use strict 'typing';
#   BD> 	my Dog $spot=Dog.new;	#ok
#   BD> 	my $foo="bar";		#bad--no type on $foo
#   BD> 	my val $baz="quux";	#ok
#
#   BD> I'm not necessarily suggesting 'val' as a type,
# however--that's just a
#   BD> placeholder for whatever we would choose.
#
# i don't like that. plain perl scalars should always be
# allowed even when
# while odd pragmata are in effect.

OTOH, we did invoke strict 'typing' so we would need to give types.  It
kinda makes sense that you would need to specify a normal type, so you
don't accidentally forget to put a type in when you meant to.

#   BD> I don't see this as being one of the 'normal' strictures--this
#   BD> would be in the @EXPORT_OK array, not @EXPORT (if strict used
#   BD> Exporter, that is).  You'd have to turn it on explicitly.
#
# if it has the meaning i proposed, it could be under the default set in
# use strict. but it deosn't have to be.

I like the stuff currently in strict, but I'm not sure if I'd want
strict 'typing' in most of the places I use strict.

#   BD> Could we use this so that we don't have to use 'ref'
# (or its moral
#   BD> equivalent) in method lookups?  In other words, if
# $spot is declared to
#   BD> hold a Dog, can we assume that it does, thus skipping
# the check with
#   BD> 'ref' normally used for method dispatch?  Would this even buy us
#   BD> anything?  Why am I asking myself these questions?  Why are the
#   BD> orderlies putting me in a white truck?
#
# no, that won't work. you can always bypass that at runtime in too many
# ways. as damian stated, runtime checks for objects are always in
# effect. if a method isn't found or handled by AUTOLOAD or something it
# is fatal (unless caught, of course). the method itself will
# always need
# to check its arguments if it cares about whether a class or object is
# the invocant (i like that word. thanx, damian!).

I'm not sure if you understood what I meant there.  I meant that, if we
know $spot is supposed to have a Dog in it, can we avoid checking if it
really does (at least some of the time) and maybe shuck some overhead by
doing so?  Perhaps we only check after each assignment to $spot, and
when we check we set a flag saying that it's already been typechecked so
we don't have to do it again.  Whatever, methinks I may optimizing too
early.  We all know what Knuth says about that.

BTW, I like 'invocant' too.  :^)

--Brent Dax
brentdax@cpan.org


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About