On Mon, Jan 19, 2009 at 01:09:14PM -0800, chromatic wrote:
> I've skimmed all of the ops in our .ops files, and here are my 
> recommendations for deprecations.  [...]

Short answers to chromatic's original list first, then I'll
make longer responses to the other items in the thread.

> How often do we use the bitwise ops?
>     - could they become functions?
>     - multidispatch functions?
>     - means pulling them out of vtables, which doesn't hurt my feelings

Pulling bitwise ops out of vtables sounds good to me;
we currently use them in Rakudo but could use functions
just as easily.

> Ops to remove:
>       set_addr/get_addr

Exceptions currently need these (or something like them), Rakudo
makes use of it in a few places.  I've used them enough times
that I'd prefer to see them remain rather than disappear.

>       pushmark/popmark/pushaction
>       exchange
>       set[insp]_ind
>       clear[insp]
>       bytelength
>       sizeof

I don't need these.

> Ops we could make into methods:
>       schedule
>       addhandler
>       debug
>       bounds
>       profile
>       trace
>       gc_debug
>       interpinfo
>       getstdin / getstdout / getstderr
>       spawnw (make into a Proc object with methods?)
>       time* (make into a Time object with methods?)
>       sysinfo (make into a Sys object with methods?)

The only items that I use here are trace, getstd*,
and time.  Either opcode or methods are fine with me.
The trace opcode is used quite often (for debugging) --
it might be worth leaving it as an opcode so that someone
doesn't have to do PMC manipulations.

> Debug ops:
>       - most of these could be methods on a debugger object
>       - getline/getfile can possibly stay

Haven't used these.

> Experimental ops:
>       - drop all except iter, exec, find_sub_not_null

I definitely use iter and find_sub_not_null.  We also make
heavy use of the splice opcode in Rakudo.

> Math ops:
>       - ceil/floor
>       - transcendental ops
>       - gcd/lcm/fact

I use the math ops because they exist, but could easily
switch to a library without too much difficulty.

> Object ops:
>       - could add/remove parent become class methods?

IIRC, they already are methods -- the opcodes are simply leftover.

Pm
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Reply via email to