Make Grob::name accessible to Scheme

Make Grob::name accessible to Scheme

Needing to determine the name of a grob is extremely common to users
of Scheme.

[david.nalesnik, 2015-02-15 19:54:19]

Please review.  Thanks!

[dak, 2015-02-16 07:56:10]

On 2015/02/15 19:54:19, david.nalesnik wrote:
> Please review.  Thanks!

"Needing to determine the name of a grob" should actually rarely be necessary:
the pervasive information connected to the functionality of a grob is rather its
interfaces.  That's the usual criterion for deciding whether to deal with a
particular grob.  Relaying on the name makes it harder to create variants of
existing grobs.

[david.nalesnik, 2015-02-16 13:46:29]

On 2015/02/16 07:56:10, dak wrote:
> On 2015/02/15 19:54:19, david.nalesnik wrote:
> > Please review.  Thanks!
> 
> "Needing to determine the name of a grob" should actually rarely be necessary:
> the pervasive information connected to the functionality of a grob is rather
its
> interfaces.  That's the usual criterion for deciding whether to deal with a
> particular grob.  Relaying on the name makes it harder to create variants of
> existing grobs.

I see what you are saying.  I'm aware that grob recognition takes place through
interfaces, and that the user could use grob::has-interface.  (This does lead to
awkwardness when, for example, you want a NonMusicalPaperColumn, since there is
no nonmusical-paper-column-interface.)

There are uses for the name of a grob, say for inclusion in text.  Also,
ly:context-grob-name and ly:engraver-make-grob accept a name as argument.

This function would one of a group: ly:context-name, ly:translator-name, and
ly:font-name.

[dak, 2015-02-16 14:05:46]

On 2015/02/16 13:46:29, david.nalesnik wrote:
> On 2015/02/16 07:56:10, dak wrote:
> > On 2015/02/15 19:54:19, david.nalesnik wrote:
> > > Please review.  Thanks!
> > 
> > "Needing to determine the name of a grob" should actually rarely be
necessary:
> > the pervasive information connected to the functionality of a grob is rather
> its
> > interfaces.  That's the usual criterion for deciding whether to deal with a
> > particular grob.  Relaying on the name makes it harder to create variants of
> > existing grobs.
> 
> I see what you are saying.  I'm aware that grob recognition takes place
through
> interfaces, and that the user could use grob::has-interface.  (This does lead
to
> awkwardness when, for example, you want a NonMusicalPaperColumn, since there
is
> no nonmusical-paper-column-interface.)
> 
> There are uses for the name of a grob, say for inclusion in text.

Yes, debugging is clearly useful.
>  Also,
> ly:context-grob-name and ly:engraver-make-grob accept a name as argument.

Also quite definitely useful as argument here.

> This function would one of a group: ly:context-name, ly:translator-name, and
> ly:font-name.

Well, font-name likely returns a string, and I guess we rather want the symbol
when talking about ly:engraver-make-grob.  There are clearly good reasons for
having the function.  But I do expect to see uses that will need to get revised
eventually.

[david.nalesnik, 2015-02-18 19:32:57]

Hmmm.  Since this is no longer just a wrapper for Grob::name, I suppose I should
rewrite it in Scheme.

[david.nalesnik, 2015-02-18 20:46:03]

On 2015/02/18 19:32:57, david.nalesnik wrote:
> Hmmm.  Since this is no longer just a wrapper for Grob::name, I suppose I
should
> rewrite it in Scheme.

Not so sure now.  Error reporting options in Scheme aren't as good.

[david.nalesnik, 2015-02-19 16:53:54]

On 2015/02/18 20:46:03, david.nalesnik wrote:
> On 2015/02/18 19:32:57, david.nalesnik wrote:
> > Hmmm.  Since this is no longer just a wrapper for Grob::name, I suppose I
> should
> > rewrite it in Scheme.
> 
> Not so sure now.  Error reporting options in Scheme aren't as good.

I take that back.  If I don't specifically meddle with the error message--as
with grob::has-interface--I get what appear to be the same results.

[david.nalesnik, 2015-02-19 17:00:20]

And in a few moments a version where I didn't strip the docstring...