Syntactic Confectionery Delight | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I'm looking only at your first examples in that post for now. To write a robust Fibonacci function, you might write something like this: You are being unnecessarily verbose, aren't you? All those checks just fold into two:
The two checks can also be written on one line and no harm done:
The checks can be skipped completely, if the caller is the recursive subroutine itself:
Optional typing in signatures would improve that, for sure - but there's Params::Validate for instance. Then, what should happen if a sub takes an Uint and gets a polymorphic object which resolves to a Uint in numeric context via overloading, but as a filehandle at I/O ? Would we need typecasting? Would the object be aliased to its numeric interpretation in such a subroutine body, or would other slots and/or behaviors still be available and valid? I personally believe that such constraints go against the Camel's hair, and against the best thing perl has since sliced bread, which is context awareness, which forces the programmer to be aware of the context in which they are moving things around. Also, neither your Ruby, PHP nor Python versions do any parameter checks, but you write them for your perl5 version. Write an equivalent Python class, and you will have exexption definitions and try/catch branches and such. No need to be unfair to perl to make a point - and no need to blow away the very foundations of perl either ;-)
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
In reply to Re: Recap: The Future of Perl 5
by shmem
|
|