On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote:
Disclaimer: I don't ~~ @larry :)

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.


Reply via email to