[EMAIL PROTECTED] wrote:
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.
Yes.
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. :)
Miro
