remove $class (#35)

[doy]

Not sure what we're going to end up deciding in #35, but this is a pull request for the requested functionality if we end up choosing that.

[stevan]

Do you think we can handle CLASS as a compile time thing using Parse::Keyword?

On Aug 9, 2013, at 2:46 PM, Jesse Luehrs notifications@github.com wrote:

Not sure what we're going to end up deciding in #35, but this is a pull request for the requested functionality if we end up choosing that.

You can merge this Pull Request by running

git pull https://github.com/stevan/p5-mop-redux remove-class-var Or view, comment on, or merge it at:

https://github.com/stevan/p5-mop-redux/pull/63

Commit Summary

remove $class (#35) File Changes

M lib/mop/internals/syntax.pm (8) M t/001-examples/003-binary-tree.t (6) M t/010-basics/000-basic.t (2) M t/010-basics/001-new.t (2) M t/200-meta/003-localized-vars-in-class.t (1) M t/200-meta/004-localized-vars-in-roles.t (1) M t/ext/Option/Option.pm (14) Patch Links:

https://github.com/stevan/p5-mop-redux/pull/63.patch https://github.com/stevan/p5-mop-redux/pull/63.diff

[doy]

We can handle __CLASS__ as a compile time thing using use constant. The main question was whether __CLASS__ made sense inside role blocks, or if we should pick a different keyword.

[stevan]

I think it should be ROLE in a role, cause CLASS would have to be dynamic

On Aug 9, 2013, at 4:23 PM, Jesse Luehrs notifications@github.com wrote:

We can handle CLASS as a compile time thing using use constant. The main question was whether CLASS made sense inside role blocks, or if we should pick a different keyword.

— Reply to this email directly or view it on GitHub.

[doy]

The only issue with that is that it would make refactoring harder - splitting out methods from a class into a role is a pretty common thing to do when refactoring.

[stevan]

Then maybe we should stick with $class

;)

On Aug 9, 2013, at 6:12 PM, Jesse Luehrs notifications@github.com wrote:

The only issue with that is that it would make refactoring harder - splitting out methods from a class into a role is a pretty common thing to do when refactoring.

— Reply to this email directly or view it on GitHub.

[doy]

So taking a step back, I think there are two separate things going on here. The current $class is just another name for $self, used when the invocant isn't blessed. Checking for blessedness on every call has a runtime cost though, which is why getting rid of this would be nice (along with the fact that unlike $self, $class is not too uncommon as a normal variable/attribute name). __CLASS__ would be different from this - it would be a constant set at compile time to the name of the currently compiling class (like __PACKAGE__). These aren't the same thing:

class Foo {
    method bar {
        say join ' ', $class, __CLASS__;
    }
}
class Bar extends Foo { }

Foo->bar; # "Foo Foo"
Bar->bar; # "Bar Foo"

I think that the current use of $class should go away entirely, potentially replaced by syntax like method foo ($class: @args) { } in the future, but whether or not we should add __CLASS__ is a different issue.