Joshua Isom wrote:
On Apr 10, 2007, at 2:05 AM, Allison Randal wrote:
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.
I'm a little mixed on this. Something like get_args probably
shouldn't be getargs or even getArgs, but if you look through ops.num,
it can be confusing to know what is what. Although not for beginners,
scanning through ops.num can help figure out why your code doesn't
compile as expected.
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).
Perhaps a namespace specific code can be used, and maybe applicable
for nested namespaces such that hll's can easily take advantage, so an
hll can say in it's root namespace "I want exceptions" and all
namespaces in that hll default to using exceptions. A file specific
option would be bug prone with something like pbc_merge or whatever,
and making it namespace specific seems simple and clean, even if a
little too DWIM for parrot.
Yes, I can see the problem you mean. To add a note to the potential
exception pragma, this could be translated to a single instruction that
changes the behaviour of parrot (either returning error codes/NULL
objects or throwing exceptions). If you think about it, it is just
another opcode being executed, changing the 'state of the world'. If for
instance in pbc file 1, you delete a global variable which is used in
pbc file 2, and you would merge those pbc files, it's also an error.
HLLs, OTOH, can 'protect' the user more, just as HLLs do access control:
some (if not most) OO HLLs don't allow the user to access private
members from other classes. In PIR, this is no problem, so the check is
done in the HLL compiler. Likewise, the syntax of the HLL can prevent
the user from doing stuff like that (if there were any way to set this
exceptions behaviour from a HLL).
my 2c,
kjs
