[dart-misc] Mixin declaration style question

[Don Olmstead]

I often use mixins to do behaviors in Polymer. What I'm wondering is if
there's a particular style I should use when doing their declarations when
I'm expecting them to be mixed in with a certain type.

As an example I have code like

abstract class MyBehavior {
html.CustomEvent fire(String type, {detail, bool canBubble: true, bool
cancelable: true, html.Node node});

void doSomething() {
fire('my-behavior-event');
}
}


Should the mixin be declared as instead?

abstract class MyBehavior implements PolymerElement {
void doSomething() {
fire('my-behavior-event');
}
}



The later saves some typing and makes things clearer on what it needs to be
mixed in with, but I wasn't sure if there was a preference either way.

['John Messerly' via Dart Misc]

Post by Don Olmstead
I often use mixins to do behaviors in Polymer. What I'm wondering is if
there's a particular style I should use when doing their declarations when
I'm expecting them to be mixed in with a certain type.
As an example I have code like
abstract class MyBehavior {
html.CustomEvent fire(String type, {detail, bool canBubble: true, bool
cancelable: true, html.Node node});
void doSomething() {
fire('my-behavior-event');
}
}
Should the mixin be declared as instead?
abstract class MyBehavior implements PolymerElement {
void doSomething() {
fire('my-behavior-event');
}
}
The later saves some typing and makes things clearer on what it needs to
be mixed in with, but I wasn't sure if there was a preference either way.

Good question. I'd say it depends on your intent in MyBehavior, and how it
might evolve over time. In the first option MyBehavior says "I need to have
a 'fire' method with this signature". In the second it says "I need to be a
PolymerElement".

Things I'd be thinking about:

Are there other reasonable implementations of "fire", or in practice will
it always be provided by PolymerElement?

Will MyBehavior be adding new requirements (i.e. new abstract methods that
must be implemented)? If so, that's a breaking change. Are those new
methods likely to also be from PolymerElement? In that case, I can avoid
the breaking change by insisting from the start that all of
PolymerElement's interface is provided.

It's hard to answer without understanding your problem domain (and the
purpose of MyBehavior), but given the example of "fire", I'd probably lean
towards the "implements PolymerElement". "fire" to me feels like a part of
PolymerElement's API, rather than a method that makes sense on its own.

[Don Olmstead]

Thanks for the response John!

I was trying to keep things as a general sort of question hence the
vagueness. I find with Polymer I use mixins heavily and some of the mixins
depend on other mixins. Wasn't sure if something should be in the style
guide for something like that as mixins seem to be underrepresented in it.

I think in these cases where there's an assumption that you'll require
another class implementation that implements makes the most sense.

On Mon, Jan 4, 2016 at 10:49 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc

Post by Don Olmstead
I often use mixins to do behaviors in Polymer. What I'm wondering is if
there's a particular style I should use when doing their declarations when
I'm expecting them to be mixed in with a certain type.
As an example I have code like
abstract class MyBehavior {
html.CustomEvent fire(String type, {detail, bool canBubble: true, bool
cancelable: true, html.Node node});
void doSomething() {
fire('my-behavior-event');
}
}
Should the mixin be declared as instead?
abstract class MyBehavior implements PolymerElement {
void doSomething() {
fire('my-behavior-event');
}
}
The later saves some typing and makes things clearer on what it needs to
be mixed in with, but I wasn't sure if there was a preference either way.

Good question. I'd say it depends on your intent in MyBehavior, and how it
might evolve over time. In the first option MyBehavior says "I need to have
a 'fire' method with this signature". In the second it says "I need to be a
PolymerElement".
Are there other reasonable implementations of "fire", or in practice will
it always be provided by PolymerElement?
Will MyBehavior be adding new requirements (i.e. new abstract methods that
must be implemented)? If so, that's a breaking change. Are those new
methods likely to also be from PolymerElement? In that case, I can avoid
the breaking change by insisting from the start that all of
PolymerElement's interface is provided.
It's hard to answer without understanding your problem domain (and the
purpose of MyBehavior), but given the example of "fire", I'd probably lean
towards the "implements PolymerElement". "fire" to me feels like a part of
PolymerElement's API, rather than a method that makes sense on its own.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Don Olmstead]

@John one other plus side of doing the implements is that I had some strong
mode warnings resolving around overriding things in different classes that
went away with the implements.

Post by Don Olmstead
Thanks for the response John!
I was trying to keep things as a general sort of question hence the
vagueness. I find with Polymer I use mixins heavily and some of the mixins
depend on other mixins. Wasn't sure if something should be in the style
guide for something like that as mixins seem to be underrepresented in it.
I think in these cases where there's an assumption that you'll require
another class implementation that implements makes the most sense.
On Mon, Jan 4, 2016 at 10:49 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc

Post by Don Olmstead
I often use mixins to do behaviors in Polymer. What I'm wondering is if
there's a particular style I should use when doing their declarations when
I'm expecting them to be mixed in with a certain type.
As an example I have code like
abstract class MyBehavior {
html.CustomEvent fire(String type, {detail, bool canBubble: true, bool
cancelable: true, html.Node node});
void doSomething() {
fire('my-behavior-event');
}
}
Should the mixin be declared as instead?
abstract class MyBehavior implements PolymerElement {
void doSomething() {
fire('my-behavior-event');
}
}
The later saves some typing and makes things clearer on what it needs to
be mixed in with, but I wasn't sure if there was a preference either way.

Good question. I'd say it depends on your intent in MyBehavior, and how
it might evolve over time. In the first option MyBehavior says "I need to
have a 'fire' method with this signature". In the second it says "I need to
be a PolymerElement".
Are there other reasonable implementations of "fire", or in practice will
it always be provided by PolymerElement?
Will MyBehavior be adding new requirements (i.e. new abstract methods
that must be implemented)? If so, that's a breaking change. Are those new
methods likely to also be from PolymerElement? In that case, I can avoid
the breaking change by insisting from the start that all of
PolymerElement's interface is provided.
It's hard to answer without understanding your problem domain (and the
purpose of MyBehavior), but given the example of "fire", I'd probably lean
towards the "implements PolymerElement". "fire" to me feels like a part of
PolymerElement's API, rather than a method that makes sense on its own.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an