Edward S. Peschko wrote: > Gordon Henriksen wrote: > > > Leave parsing and formatting entirely to libraries. > > Absolutely no need for that in the instruction set. > > well, I have a bit of a problem with that... As it was pointed out > before, people have gone hogwild with the parsing and formatting > routines, and its a bloodbath of modules on CPAN with different > methods for time parsing.
"Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib directory. > Perhaps there could be an extra argument for locales - and maybe the > op could be split in two (ie: for (r_)gm_fmtime, (r_)local_fmtime), > but for me, in processing time values most of the time you know the > format for dates - as long as they are machine generated. If they are not, > you can always fall back to the very slow Date::Parse and cousins, or > maybe string these ops along in a chain of '||' to query for multiple > formats. > > But how many times are you going to need to parse formats > like '3 weeks from next Wednesday?'. Uh. Yeah. This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the core, and regardless of how rich the interface is, it'll never be quite rich enough to satisfy everyone. Someone depends on formats like "3 weeks from next Wednesday" on a regular basis. You might not need to format dates from the Chinese lunar calendar, but you can bet that it's vital to someone. Eras? Well, sure. Fuzzy date parsing? (Guessing.) Oh, baby. Global time zone database? Bring it on. A kl-hw (Klingon Homeworld) locale? But of course! There'll always be pressure to further enhance the feature, increasing parrot's *core* memory footprint. You can't skip loading the implem- entation of core parrot ops like you can avoid DateTime.pm. So keep it to (un)loadable user code, and provide a class that solves 90% of the problem in the stdlib. Also, trying to nail down a rich interface before seeing what Larry has in mind for Perl 6 date handling is roughly a waste of time.... -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
