Re: the Time::Object module, Tim Jenness wrote:
> Sounds good since:
>
> 1. It removes unnecesary core functionality to a loadable module
>
> 2. Can be retrofitted to perl5 code fairly easily (essentially as easy as
> exporting a backwards compatible localtime() function).
>
> 3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> sense) so Mac, VMS and Windows users feel less confused.
>
> It gets my vote so long as perl6 has really fast methods.
I'm presuming we can count on really fast methods to be one of the
goals of the internals group. Perl is where I learned O-O
(discovering wasn't just a useless buzzword), and I'd like to see
Perl6 make O-O much more natural, without forcing O-O on people who
still think like I used to and prefer function-oriented interfaces.
Re: #1, above, I'd go so far as to suggest that nearly every system
call in Perl (along with just about every punctuation variable) should
find itself in a module and only in a module. Languages like C and
Pascal even go so far as to make I/O an "option" that you have to
#include (or whatever, depending on the language; Pascal makes you
specify it explicitly in some way I don't quite remember), and they
seem to do fine.
What if, in order to access dates, or I/O, or getservbyname(), or
semget(), or crypt(), or any of the other OS system and library calls,
you were expected to use a module? This would first of all encourage
earlier reliance on modules as someone learns Perl. Plus, most of
these standard modules could provide both an O-O and a
function-oriented interface, for reasons I detailed above.
I'm not even sure exactly what would be left in Perl if this were
done. It might simply be an interface to scalars, lists, and hashes,
with the ability to define subroutines and classes and the ability to
load modules. Think of the itty-bitty memory footprint! (Con: think
of the delay in always having to load modules you always use, such as
I/O. But those kinds of issues are going to be fixed by the internals
people, right? :)
Just random thoughts and suggestions.
J. David Blackstone
