On Fri, Jul 6, 2012 at 9:51 AM, David Kastrup <d...@gnu.org> wrote: > Joe Neeman <joenee...@gmail.com> writes: > > > I think it's exercises like that that help strengthen the Scheme > > bindings and thus lead to more customizability/extensibility. > > > > > > In this case, I disagree. The function in question is used in 2 places > > in the C++ code, neither of which is a good candidate for > > customization. The only argument for porting this function in the > > first place is that it happened to live in the same file as some other > > stuff (which _did_ make sense to port). That doesn't sound like a very > > good argument to me. > > To me it sounds like a Scheme interface to > Pointer_group_interface::find_grob is needed here. >
That may be useful at some point, but it's orthogonal to what's going on here. I think being able to move the _entire_ chunk of functionality to Scheme > makes _excellent_ sense since it means we arrive at a piece of > functionality that can serve as a template for _user_ written > functionality without requiring recompilation. > The entire chunk of functionality has already been ported. That is not the issue. > A chunk of Scheme code with "just" one or two semi-trivial C++ functions > required to complete it is useless for that purpose. > The semi-trivial C++ function is _not_ useful for the scheme code. It is used in two parts of the C++ code. However, because it belonged to the same file as various other functions that were being ported, Marc was planning to port this semi-trivial function to scheme also, and then call the new scheme function from C++ code. In the amount of time we've spent discussing this, we could have rewritten the function in scheme, haskell, perl, and brainf*ck by now. I really think that the best thing is just to leave the function where it is and stop worrying. Cheers, Joe
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
