Damian Conway <[EMAIL PROTECTED]> writes:
> Yes, subroutine variables *are* like underwear.
> But parameter names *aren't* like underwear.
> Because they're not (primarily) subroutine variables.
>
> So they're like the labels on the knobs, dials, and buttons of your
> favourite elctronic device. They're part of the *interface*, not
> (primarily) part of the implementation. They should be chosen with
> care, and not changed on a whim.
There's always the Smalltalk approach:
Dictionary extends Collection
at: key put: anObject
Good Smalltalk style uses the variable names to suggest the variable
type and the 'selector' names to say that they're used for.
In Perl6, it seems that this would be sort of 'turned inside out',
variable names would suggest roles while compiler hints would suggest
(enforce) types.
class Dictionary is Collection {
method insert_at( Object $key, Object $value ) {...}
}
> I do, however, understand the desire to allow them to change, or to
> be somewhat "fuzzy" (i.e. "filename" vs "file_name" vs "file"). And
> I agree that it could be a very useful facility.
>
> But your proposed syntax is...err...less than ideal.
>
> If we were to have this, I'd far rather we use the existing
> mechanism for annotating variables. Namely: properties.
>
> For example:
>
> sub load_data ($filename_tainted is named('filename'),
> $version_input is named('version','ver') //= 1)
>{...}
But down that road lies the likes of Symbol::Parameter::Approx. Which
may, or may not, be a bad thing.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
