You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1513 at the (current) bottom, I noticed a bug that is a little bit hard to fix in TimeSigNote (because its glyph is stored pretty far down in the system). And I've realized that the same bugs take place anywhere there is a lot of shared code between a Modifier (or StaveModifier) and a Note. (For instance, Clef and ClefNote; KeySignature and KeySignatureNote). And the difficulty of writing a new Note is probably why we don't have XNote versions of every modifier/stavemodifier.
In other languages, like Python, the answer would be pretty simple: Create something like ClefBase which has all the information that is currently in the Clef (StaveModifier), and then do:
class Clef(ClefBase, StaveModifier)...
class ClefNote(ClefBase, Note)...
and voila! two related classes deriving from different superclasses but with their shared guts in one place.
The problem of course is that JS does not have multiple inheritance. It is possible to do so with Mixin functions that return classes:
function ClefBase(baseClass) {
return class ClefBase extends baseClass {
setType(...) { }
}
}
export class Clef extends ClefBase(StaveModifier) {}
export class ClefNote extends ClefBase(Note) {}
I did this in a lot of projects in the past, and it was really helpful (especially in music21j where I had to port a lot of ideas from Python which has multiple inheritance).
I think that such mixin interfaces would go a long way to avoiding bugs in computing widths, collisions, etc.
It is, however, harder in TypeScript, so just in case we go in this direction, just to note how to set up a TypeScript happy mixin.
make sure that the assumed class to be mixed into is specified as the minimum base. Here, it'd be Element.
Specify that the class passed into the mixin must be the constructor for that base class.
There may be a need for a class between Element and Tickable(Note)/Modifier/StaveModifier that takes care of some of the similarities between them that we assume exists (setXShift()) -- this might be a good thing even if we don't go this route.
TypeScript version:
type GConstructor<T = {}> = new (...args: any[]) => T;
type ElementDerived = GConstructor<Element>;
export function ClefMixin<TBase extends ElementDerived>(Base: TBase) {
return class ClefMixin extends Base {
setType(...) { }
}
}
thoughts?
The text was updated successfully, but these errors were encountered:
In #1513 at the (current) bottom, I noticed a bug that is a little bit hard to fix in TimeSigNote (because its glyph is stored pretty far down in the system). And I've realized that the same bugs take place anywhere there is a lot of shared code between a Modifier (or StaveModifier) and a Note. (For instance, Clef and ClefNote; KeySignature and KeySignatureNote). And the difficulty of writing a new Note is probably why we don't have XNote versions of every modifier/stavemodifier.
In other languages, like Python, the answer would be pretty simple: Create something like ClefBase which has all the information that is currently in the Clef (StaveModifier), and then do:
and voila! two related classes deriving from different superclasses but with their shared guts in one place.
The problem of course is that JS does not have multiple inheritance. It is possible to do so with Mixin functions that return classes:
I did this in a lot of projects in the past, and it was really helpful (especially in music21j where I had to port a lot of ideas from Python which has multiple inheritance).
I think that such mixin interfaces would go a long way to avoiding bugs in computing widths, collisions, etc.
It is, however, harder in TypeScript, so just in case we go in this direction, just to note how to set up a TypeScript happy mixin.
TypeScript version:
thoughts?
The text was updated successfully, but these errors were encountered: