Minor notes/suggestions on PDD15

[Klaas-Jan Stol]

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)

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")

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 :-)

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)

Regards,
kjs

[Allison Randal]

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

[Joshua Isom]

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.

> Allison
>

[Klaas-Jan Stol]

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