What about making `ampersand-class-extend` an `amp` module?

[jvduf]

It's a utility module as well. Would be a clean and consistent approach to merge it into amp instead of having it as an individual module. What do you think?

It requires a small change to the objects extend module already in amp but that could be a simple name change, for example:
amp-object-extend
amp-class-extend

[jvduf]

@HenrikJoreteg what do you think about this proposal?

[HenrikJoreteg]

Yeah, seems logical as long as we can name things in a way that make sense. I'm hesitant to re-name but having amp-extend and amp-class-extend seems fine.

[wraithgar]

Just a suggestion to keep the nomenclature matching the other 'class' methods (i.e. amp-add-class) which would make this amp-extend-class

I'm a little lukewarm about renaming amp-extend since it's an already established programming concept (extending objects) versus this other subset of methods (that manipulate class attributes on a DOM element)

[gsf]

Any name with "class" in it is confusing to me given that all of the existing ones deal with DOM classes. How about following the lead of Closure and Node and going with amp-inherits?

[gsf]

Also worth thinking about is what happens to a utility like this as we migrate to ES6 classes?

[jvduf]

I like the amp-inherits!

re: ES6, I am not sure. I guess this takes some time.