Klaas-Jan Stol wrote:
hi,
Some suggestions for PDD15:
1.
reading PDD15, I noticed that some methods/ops are named using an
underscore to separate words, others don't, for instance:
* get_class (but also "getclass" is used in the examples)
* newclass
IMO, it'd be nice to be consistent, and stick to 1 style. (My personal
preference is to leave out the underscore)
The get_ standard entered with namespaces, and was itself a modification
of the find_ standard from the earlier opcodes for dealing with globals
and lexicals. For methods, I'd say the underscores are standard. For
opcoess, it's debatable whether underscores or no underscores is
standard at this point. I made a note to review it when I get to the
Opcodes PDD.
2.
Another thing; operations such as find_method return a NULL PMC on
failure. It might be nice to have it configurable for the user so s/he
can choose whether an exception will be thrown, or a NULL PMC is
returned. (IIRC, this can already be done for some ops, it'd be nice to
set it for all ops that may return a NULL PMC).
(as a detail: in PIR this might be represented by a pragma, like:
".pragma exceptions 1")
This is the same question we have for I/O, and really for large parts of
Parrot. I've temporarily held off on this decision until the new
exceptions PDD is implemented (widespread exceptions really aren't
practical with the current exceptions implementation).
3.
The syntactic sugar for the op:
callmethodsupercc "foo"
could well be: super."foo"()
but you I guess you have thought of that yourselves already :-)
Yeah, that could work. A pseudo-variable like 'self' in every method. Or,
self.super."foo"()
4.
Likewise, syntactic sugar for:
callmethodnextcc "foo"
(assuming object "obj")
Could be: obj."foo".next() (or maybe: obj."foo"().next, so there's a
little bit more emphasis as it looks stranger)
Also a good candidate. Or, to only modify PIR syntax in one spot,
self.next."foo"()
Great thoughts, thanks!
Allison
