Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature requset: coalesce role BUILD/TWEAK/DESTROY #2241

Open
vrurg opened this issue Aug 29, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@vrurg
Copy link
Member

commented Aug 29, 2018

The Problem

Currently any of BUILD/TWEAK/DESTROY submethods declared in a role are ignored if consuming class defines any of them. For this reason if a role needs to perform any action at the object construction/destruction stages it has to define a method and ask the consumer to call it in a respective submethod. This adds to the boilerplate and generally reduces flexibility of the code.

Expected Behavior

role R1 {
    submethod TWEAK { say "R1::TWEAK" }
}
role R2 {
    submethod TWEAK {say "R2::TWEAK" }
}
class Foo does R1 does R2 {
    submethod TWEAK { say "Foo::TWEAK" }
}
Foo.new

The output would be:

R1::TWEAK
R2::TWEAK
Foo::TWEAK 

Since there is uncertainty about the order of calling class/role submethods it could be postulated that by default it's resembles MRO behavior (parents are first, children then following) in a way that a role could be taken as a kind of a parent to the class. Though in special cases a trait is after (or call after) could be used:

role R1 {
    submethod TWEAK { say "R1::TWEAK" }
}
role R2 {
    submethod TWEAK is after {say "R2::TWEAK" }
}
class Foo does R1 does R2 {
    submethod TWEAK { say "Foo::TWEAK" }
}
Foo.new

would produce the output:

R1::TWEAK
Foo::TWEAK 
R2::TWEAK

@AlexDaniel AlexDaniel added the 6.e label Aug 29, 2018

@AlexDaniel

This comment has been minimized.

Copy link
Member

commented Aug 29, 2018

For anyone reading: please change the label to 6.d if you know how to make it happen in v6.d.

@lizmat

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2018

@lizmat

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2018

@vrurg

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2018

Note, please, that I mention BUILD/TWEAK/DESTROY in the beginning.

And, as I remember, order of parent classes define their order in MRO.

@lizmat

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.