lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSOC: change XY-extent to outer-XY-extent and inner-XY-extent (desig


From: Joe Neeman
Subject: Re: GSOC: change XY-extent to outer-XY-extent and inner-XY-extent (design - feedback requested)
Date: Mon, 18 Jun 2012 18:29:38 +0200

On Mon, Jun 18, 2012 at 4:49 PM, Janek Warchoł <address@hidden> wrote:
Hi Joe,

On Mon, Jun 18, 2012 at 1:23 PM, Joe Neeman <address@hidden> wrote:
> I think that what you propose can be done more generically using
> higher-order functions to build grob callbacks. This would have two main
> advantages that I can see: it would allow each grob to have more than one
> "core extent" to be used in different contexts, and it would allow those
> "core extents" to be referenced using meaningful names.

(this is probably a stupid question, but i'm not confident enough with
terminology yet:) You mean to create functions similar to these ones
(from self-alignment-interface):

// this just calls aligned_on_parent with specific argumments
MAKE_SCHEME_CALLBACK (Self_alignment_interface, aligned_on_y_parent, 1);
SCM
Self_alignment_interface::aligned_on_y_parent (SCM smob)
{
 return aligned_on_parent (unsmob_grob (smob), Y_AXIS);
}

// this one actually does the job
SCM
Self_alignment_interface::aligned_on_parent (Grob *me, Axis a)
{
 [....]
}

..?
If yes, that's exactly what i wanted to do.  I'm just wondering what
needs to be done apart from writing these functions, and how to do
this without creating a royal mess :)

That's basically what I mean, yes. The only difference is that I'm proposing to make it possible to define aligned_on_y_parent in scheme, given that aligned_on_parent is defined in C++. This part is basically what will allow us to avoid hard-coding a single name (like "core-extent") into the C++ code. Unfortunately, this slight difference requires some amount more work. To do it, you'll want to create a "higher-order function" (that is, a function which returns a function). For example, aligned_on_parent is currently a function (Grob*, Axis) -> Real (although the Real is wrapped in a SCM, but don't let that confuse you...). You'll want to turn it into a function Axis -> (Grob* -> Real) (that is, a function which takes an Axis and returns a function from Grob to Real). We actually already have some code to make this possible in C++; it's in simple-closure.cc.

In the medium/long term, it's probably worth while having some sort of C++ infrastructure for this, since there are several existing callback functions that might benefit. In the short term, I'd suggest doing a scheme implementation of a simple example, just to get the hang of how the pieces fit together (ie. don't even look at simple-closure.cc yet). It's _much_ easier to write higher-order functions in scheme.

Cheers,
Joe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]