From:

Date:

May 15, 2005 09:52Subject:

S29 Q: Rules for boxed typesMessage ID:

1116175940.4413.73.camel@markabIn reviewing S29 as it stands now, I see that many builtins both receive and return boxed basic types. This seems like potentially spurious overhead in some situations, while essential in others, so I wanted to work out a set of rules for when boxed vs. unboxed types would be used in core routines (given that all rules will have exceptions). Here's my first pass for review, using the standard meaning of "must" and "should" from the RFC world. * By default, basic type parameters should be unboxed * "is rw" parameters must be boxed * Return values should not be boxed by default This means: sub lc(str ?$string = $CALLER::_) returns str {...} sub chomp(Str ?$string is rw = $CALLER::_) returns int {...} This all assumes that it is far more trivial to extract an unboxed basic type from a boxed basic type (which requires accessing encapsulated data) than it is to go the other way (which requries construction). Thoughts?Thread Next

**S29 Q: Rules for boxed types**by Aaron Sherman- Re: S29 Q: Rules for boxed types by Rod Adams
- Re: S29 Q: Rules for boxed types by Aaron Sherman

nntp.perl.org: Perl Programming lists via nntp and http.

Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About