Disclaimer: I don't ~~ @larry :)
[EMAIL PROTECTED] wrote:
class Bar {
our $.bar;
{
my $.foo;
}
}
I assume that the leading "$." is what makes the difference, however,
IIRC the "$." is just part of the name, and no more special than
that. Which means that I can choose that name (yes, it is evil, but I
assume I can still do it).
Ummmm... I'm not sure that allowing $. injection from the nested blocks
is a good thing. I don't think it's ambiguous, but to me it looks weird
and confusing - if a user put the variable in the nested block like
that, it's almost certain he actually meant to write
{
my $foo;
}
and the . was put there erroneously.
But given that the variable will be accessible to all methods via the
closure mechanism, the only thing missing I think is the ability to
get at the variable via introspection.
Now, as for class methods, I suppose it is possible to just stash
then in the classes symbol table like with variables. However, do we
then loose the method call syntax?
Well, if it belongs to the module part of the class, the syntax would be
Bar::method(...), right?
This also means that they would not (directly) be inheritable since
inheritence moves along superclass lines, and not with @ISA.
Well, namespaces should generally be inheritable. How else would lexical
namespaces inject variables from outer block into the inner? I guess at
the package level declaration that Class1 is Class2 would just inject
symbols from one module into the other? (yes, this is kinda handwavy :/ )
I am also not sure what you mean about multi-methods either, could
you please explain more?
Uhm. I'm not sure either. :) The way I read Larry's mail, multimethods
use .isa operator to detect whether $foo belongs to Foo. And for every
class, Foo.isa(Foo) is true (this is exceptional behaviour of .isa). So
multi bla (Foo $f);
would accept both bla(Foo.new()) and bla(::Foo). (Larry, please correct
me on this if I'm misparaphrasing you :) )
Anyway, this makes me cringe on a certain level, although I'm not sure I
can put the reason into words. Strictly speaking, it's bad only if there
are cases where multimethod should behave differently for a class and an
instance. One case I can think of is
class AutoCreation { ... };
multi dwimmy_instance(class AutoCreation $obj) { $obj.new() }
multi dwimmy_instance(AutoCreation $obj) { $obj }
(I pulled the syntax out of my nose for this). Anyhow, this looks like a
pretty contrieved usage. I'm still trying to think of a non-contrieved,
more realistic situation when you might actually want something like this.
Miro
