[gsharp-devel] Architecture question

[Robert Strandh]

Timothy MOORE writes:
 >
 > Presumably the score pane knows how to render scores. A score is a 
 > collection of objects that follow a "score protocol" that is, have some 
 > semantics for functions that "do stuff" with scores.

I kind of don't think so.  The reason is that a real score is much
more than what is visible in a score pane.  It is therefore convenient
to define what is visible in a score pane as a different kind of
object from that which is managed by the score editor. 

Also, you do not want to put too much semantics into a score pane
object, because different applications might want to do different
things with it. 

 > Right, but these seem a bit more like protocol classes than 
 > presentation types to me. That is, the score pane will handle the 
 > rendering of the entire score and do the right thing when it finds 
 > clefs, noteheads, etc. 

Again, I am not sure.  If you build all that into the score pane, you
no longer have a free choice of which application you want to write. 

 > I don't imagine that a "client" of a score pane 
 > would write (present x 'notehead). 

Why not?

 > On the other hand, the presentation 
 > type 'notehead does make sense for input; if the score pane rendering 
 > code has recorded the presentation type of each interesting object with 
 > with-output-as-presentation, then these types will be available to the 
 > commands of the client code.

Yes. 

 > You can make these types disjoint from Gsharp types if you want but, 

I have the feeling that that is what I want, but I am not sure. 

 > like I said, these make sense to me as protocol superclasses inherited 
 > by the concrete Gsharp classes.

Hmmm.  That would mean that the internal data structure assumes the
existence of a GUI.  I am not sure that is a good idea.

 > Right; use-package should never be mandatory for a client. I wouldn't 
 > worry too much about choosing a short package nickname for your 
 > package; after all, that might conflict with a nickname in the client's 
 > system, which is a far more painful problem to work around than 
 > individual symbol conflicts. 

Good point. 

 > The client should be free to use a package 
 > if they want, import individual symbols, use the package name 
 > explicitly, or "adopt" the external symbols into a package of their own 
 > with a short nickname, if they really want that.

Agreed. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------