On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote:
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.
You are probably right, but are the twigils actually special? or is
it just a naming convention.
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?
Yes, but the . is the method invocation operator, the :: is package
symbol table access. I think they really mean different things.
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.
I don't think this is true, this is a Perl 5-ism.
How else would lexical namespaces inject variables from outer block
into the inner?
I think you are confusing namespacing with scoping. The scope rules
are as such that the inner can access see the outer.
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 don't think this would be so, unless you explicitly asked for it.
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
(sidebar: it will probably use .does actually, but this an as yet
unresolved detail)
multi bla (Foo $f);
would accept both bla(Foo.new()) and bla(::Foo). (Larry, please
correct me on this if I'm misparaphrasing you :) )
I am not 100% sure this is true given basic multi-method behavior,
however there is no reason we cannot either special case this, or do
some other kind of trickery to make it happen.
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 think we need some ability to differentiate between the class
version of Foo and the instance version of Foo.
Stevan
