Simplifying extensibility mechanisms.

[quickredfox]

I'm not saying you should necessarily expose your classes publicly, this is just one approach (see bellow) but as food for thought:

Last evening I wanted to extend the Note object with a toUTF8() method (which would replace #,b etc from the simple name with real utf8 musical entities ).

1. I could not extend the prototype, for it's not exposed.
2. I would have had to monkey patch all teoria methods (chord, note, scale) etc and do itterations on collections to find notes adding the method to each note instance.

It would have been a cinch had I been able to do:

teoria.TeoriaNote.prototype.toUTF8 = function(){ return this.name.replace /...../ }

Or maybe I'm missing something? In either case, I think planning extensibility will give you more control on what you decide to bring into the core and what you decide doesn't go there without preventing others to do so.

[saebekassebil]

Hi @quickredfox,

The classes are exposed in the namespace teoria. So that:

teoria.TeoriaNote = TeoriaNote
teoria.TeoriaChord = TeoriaChord
teoria.TeoriaScale = TeoriaScale
teoria.TeoriaInterval = TeoriaInterval

So extending the prototype should be quite possible. I had this working for me:

teoria.TeoriaNote.prototype.toUTF8 = function() {
  return this.toString()
    .replace('#', '\u266F')
    .replace('bb', '\uD834\uDD2B')
    .replace('b', '\u266D')
    .replace('x', '\uD834\uDD2A');
}

Is this what you mean? When you talk about extensibility, do you mean there should be some kind of API to attach methods or isn't the .prototype enough?

[quickredfox]

No, you're good. Tis why I said "Or maybe I'm missing something?".