On Tue, 9 Mar 2004, Edward S. Peschko wrote: > On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote: > > "Not an opcode" doesn't mean "balkanized." There is a parrot/stdlib > > directory. > > fair enough, but then where does the distinction lie? Why put gmtime, et al. > in opcodes? As well as addmonth?
Returning the current time since epoch x should be an opcode as this is a very common and latency sensitive operation. I believe an awful lot of code only wants to determine the elapsed amount of time by subtracting to subsequent timestamps. Date and time manipulation is complicated and belongs at a much higher level. > If you are optimising for simplicity and , it surely makes sense to put these in > the standard library. Only if it's a _correct_ implementation. There is no reason why DateTime.pm couldn't be ported to Parrot after object support settles down a bit. > If you are optimising for speed, then it makes sense to put them in opcodes. Bloating the core doesn't count as an optimization. > But I don't see the 'creeping featuritis' that you see. As well as the > memory imprint problems that you see. Is parrot going to link with libc? > > If so, you get a ton of functionality for (almost) free, just by doing an > intelligent wrapper around strftime. As well as providing much of your > localization support. And you get a natural boundary on what functionality should > be put (in the core) versus what should be put in a module. We all know how consistent the nice vendors are with there libc implementations. :) Do we really want to expose the platform specific strftime() extensions? -J --
