Matt Diephouse wrote:
Allison Randal via RT <[EMAIL PROTECTED]> wrote:
> PMC Class name IDs ... will require a dot in front
My preference is to eliminate the dot in classname IDs. Lodge your
objections now, before it's made fact in 0.4.9.
Allison
I actually prefer the dot. I don't like the possible ambiguity between
types and local variables:
.local string MyClass
MyClass = '...'
$P0 = new MyClass # is this a type or a string?
Capitalized variable names may be rare and/or bad practice, but it's
bound to happen. There was talk on #parrot about how this still
conflicts with macros, but those are rarer than variables.
Also, if we decide that anything starting with a dot that doesn't have
parens is a type, I could write:
$I0 = typeof $P0
if $I0 == .Foo goto bar
I know we're not optimizing PIR for human readability, but I've
written a lot of it, so I appreciate the little things. :)
A dot also indicates that this is not pure PASM, but rather PIR. The dot
implies the token is pre-processed by IMCC (the type is looked up during
parsing, IIRC), which is, IMHO, more consistent with the other
dot-prefixed tokens from PIR. One could also think about it like this:
the dot indicates the difference between a variable having a value
during compile time or runtime, or, in other words, a dot-prefixed name
is a variable during compile-time, and no-dot-prefixed name is a runtime
variable. So:
compile time:
.local pmc p
p = new .Hash # dot indicates ".Hash" is looked up during compile time
by IMCC
runtime:
.local pmc p
.local int hash_type
hash_type = find_type "Hash"
p = new hash_type # no dot means "hash_type" gets a value during
runtime (the previous statement in this case, but usually it may not be
as clear as this simple example)
Just a thought,
klaas-jan
