Rename calc-property-by-copy to copy-property-from-event

Rename calc-property-by-copy to copy-property-from-event

The old name was totally non-informative.  Btw, does this require
a convert-ly rule?  It seems quite internal.

[dak, 2014-08-01 19:30:45]

It's a public function, so a convert-rule seems prudent to do.  Purely internal
functions are not exported.

[dak, 2014-08-01 19:31:40]

On 2014/08/01 19:30:45, dak wrote:
> It's a public function, so a convert-rule seems prudent to do.  Purely
internal
> functions are not exported.

Actually, it's probably easier to do an alias rather than a convert rule.

[janek, 2014-08-02 10:29:33]

alias for old name

[janek, 2014-08-02 10:33:01]

On 2014/08/01 19:31:40, dak wrote:
> On 2014/08/01 19:30:45, dak wrote:
> > It's a public function, so a convert-rule seems prudent to do.  Purely
> internal
> > functions are not exported.
> 
> Actually, it's probably easier to do an alias rather than a convert rule.

Like this?  Or is there some special way of creating aliases?

Btw, is the new name optimal?  What about
- grob::event-property
- grob::copy-event-property
- grob::copy-from-event-property
- grob::copy-from-cause
?

[dak, 2014-08-02 14:36:37]

https://codereview.appspot.com/122750044/diff/20001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/122750044/diff/20001/scm/output-lib.scm#newcod...
scm/output-lib.scm:1114: (export grob::calc-property-by-copy)
You can just use define-public here.  It is only define-public with curried
definition syntax (like the immediately preceding define) that is broken through
much of Guile-2.0.

But since it only concerns the syntax of the definition rather than the actual
result of this definition, you don't need to jump through the same hoops for a
plain (define-public x y) even if y has been defined using (define ((y ...

[janek, 2014-08-02 18:32:41]

use simpler syntax

[dak, 2014-08-02 18:51:36]

On 2014/08/02 18:32:41, janek wrote:
> use simpler syntax

Looks good.  Looking at the name grob::copy-property-from-event, I think that
grob::property-from-event is shorter but probably equally descriptive.  Though
perhaps we have a number of others starting with copy- already.

Your call.

[janek, 2014-08-07 19:40:37]

2014-08-02 20:51 GMT+02:00  <dak@gnu.org>:
> Looks good.  Looking at the name grob::copy-property-from-event, I think
> that grob::property-from-event is shorter but probably equally
> descriptive.  Though perhaps we have a number of others starting with
> copy- already.
>
> Your call.

Ok.  I'll change it to grob::property-from-event when pushing, if you
don't mind.

thanks!
Janek

[dak, 2014-08-08 14:10:18]

On 2014/08/07 19:40:37, janek wrote:
> 2014-08-02 20:51 GMT+02:00  <mailto:dak@gnu.org>:
> > Looks good.  Looking at the name grob::copy-property-from-event, I think
> > that grob::property-from-event is shorter but probably equally
> > descriptive.  Though perhaps we have a number of others starting with
> > copy- already.
> >
> > Your call.
> 
> Ok.  I'll change it to grob::property-from-event when pushing, if you
> don't mind.
> 
> thanks!
> Janek

Oh phooey.  Rethinking this, what about just grob::event-property and
(eventually)
grob::parent-property ?  The grob:: makes clear that we are starting from a
grob,
and the xxx-property makes clear where we are ultimately looking.

We don't really need more than that in the name, do we?

Sorry for being late again with this proposal...

[dak, 2014-08-08 14:13:57]

On 2014/08/08 14:10:18, dak wrote:
> On 2014/08/07 19:40:37, janek wrote:
> > 2014-08-02 20:51 GMT+02:00  <mailto:dak@gnu.org>:
> > > Looks good.  Looking at the name grob::copy-property-from-event, I think
> > > that grob::property-from-event is shorter but probably equally
> > > descriptive.  Though perhaps we have a number of others starting with
> > > copy- already.
> > >
> > > Your call.
> > 
> > Ok.  I'll change it to grob::property-from-event when pushing, if you
> > don't mind.
> > 
> > thanks!
> > Janek
> 
> Oh phooey.  Rethinking this, what about just grob::event-property and
> (eventually)
> grob::parent-property ?  The grob:: makes clear that we are starting from a
> grob,
> and the xxx-property makes clear where we are ultimately looking.
> 
> We don't really need more than that in the name, do we?
> 
> Sorry for being late again with this proposal...

Uh, strike that.  grob::event-property would be fine for directly reading from
the corresponding
event property, but that's not what grob::event-property does.  Instead it
returns a callback
that, when called, reads directly from the event property.  So it does make
sense to put the
"from" in there, or some other phrase we pick for indicating a callback
generator.

[dak, 2014-08-08 14:48:39]

On 2014/08/08 14:13:57, dak wrote:
> On 2014/08/08 14:10:18, dak wrote:
> > On 2014/08/07 19:40:37, janek wrote:

> > > Ok.  I'll change it to grob::property-from-event when pushing, if you
> > > don't mind.
> > > 
> > 
> > Oh phooey.  Rethinking this, what about just grob::event-property and
> > (eventually)
> > grob::parent-property ?  The grob:: makes clear that we are starting from a
> > grob,
> > and the xxx-property makes clear where we are ultimately looking.
> > 
> > We don't really need more than that in the name, do we?
> > 
> > Sorry for being late again with this proposal...
> 
> Uh, strike that.  grob::event-property would be fine for directly reading from
> the corresponding
> event property, but that's not what grob::event-property does.  Instead it
> returns a callback
> that, when called, reads directly from the event property.  So it does make
> sense to put the
> "from" in there, or some other phrase we pick for indicating a callback
> generator.

But then probably grob::from-event-property might be less jumbled, and possibly
grob::event-property-getter might bring the callback nature better across.

Of course, this reeks of wanting to become a whole naming convention at one
point of time.  Should we run this through another discussion cycle with the
strong premise that the naming chosen here might, at a later point of time, be
adopted for all similar callback generators?

[janek, 2014-08-09 21:31:37]

Hi David,

2014-08-08 16:48 GMT+02:00  <dak@gnu.org>:
> But then probably grob::from-event-property might be less jumbled,

I'm ok with this one.

> and possibly
> grob::event-property-getter might bring the callback nature better
> across.

I don't like this one.  Maybe it's insufficient LilyPond knowledge on
my side, but if i had seen grob::event-property-getter in the code i
wouldn't know for sure what it does.  I think
grob::from-event-property would be more self-explanatory for me.

> Of course, this reeks of wanting to become a whole naming convention at
> one point of time.  Should we run this through another discussion cycle
> with the strong premise that the naming chosen here might, at a later
> point of time, be adopted for all similar callback generators?

No problem :-)
I'm not at rush with this change at all, and i don't have waiting
patches that depend on it, so take the time.  Actually, feel free to
take ownership of the issue if you'd like so.

I've set the tracker issue to review.

best,
Janek