Well, that still wouldn't work--compatibility with existing decorators (on the decorator implementer side) isn't a goal. Should it be?
-
-
Replying to @littledan @AdamRackis and
I'm suggesting, we could remove the check that the class is the subclass of the other class, but still leave it based on the finisher.
3 replies 0 retweets 2 likes -
Replying to @littledan @AdamRackis and
This is probably the most minimal thing we can do.
1 reply 0 retweets 2 likes -
Replying to @wycats @littledan and
Yehuda's been incredibly kind and helpful with me offline. It's clear what I'm asking for isn't possible.
2 replies 0 retweets 3 likes -
Replying to @AdamRackis @littledan and
I think we could make the pattern you want work as an escape valve but the returned class wouldn't get statics and proto (fine for your use)
1 reply 0 retweets 0 likes -
Replying to @wycats @littledan and
So Class => class{} WOULD work, but Class => class extends Class{} would NOT? Or am I missing something?
2 replies 0 retweets 0 likes -
Replying to @AdamRackis @wycats and
not sure what "wouldn't get statics and proto" means?
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @littledan and
It means the statics and proto would apply to the inner class, and the outer class is just a dummy wrapper. But this makes order significant
2 replies 0 retweets 1 like -
Replying to @wycats @littledan and
If the decor that 100% replaces class is run first, (inner) then next decorator above would get NEW class's members to work w/, right?
3 replies 0 retweets 0 likes -
Replying to @AdamRackis @littledan and
The new class but not its members. There's no way to get the members if you return a real class.
2 replies 0 retweets 1 like
It's just a bit of a composition hazard that goes away if you can manage to subclass instead of hiding.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.