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.

Gack, furthermore, I was thinking 'has' and reading/writing 'my'. Sorry. :(

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.


Now to be literal-minded, if Foo is a class...

Foo::method() would mean package(Foo)::method() (do package access, call method. No invocant, but you can access the proper child of Foo as $*MODULE) Foo.method() would mean Class::method(Foo:) (forward to metaclass, with class as an invocant)

Nicely symetric, and (IMHO) completely unintuitive. So what exactly means to say that a class is a module?

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.

Fair enough. I was talking about implementation - this means you need symbol table import and shadowing (with the symbols defined in the inner scope). Same (or similar) policy could be used for class methods and attributes.

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'm not sure I understand, why not?

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.

I think we agree here. :)


Reply via email to