Joseph Rushton Wakeling <joseph.wakel...@webdrake.net> writes: > On 03/06/12 17:44, David Kastrup wrote: >> I don't want to remove "as much C++ as possible". That's about as >> useful as to remove "as much C as possible" from Emacs. The point is to >> consider C++ as the building language for primitives, and tie together >> the primitives in Scheme. > > OK, I misinterpreted your remarks somewhat. I had read them as > meaning that (besides re-architecting things so that control flow > etc. was organized from within Scheme) you wanted to strip out the > object-oriented side of things and move that over to Scheme, so that > what was currently C++ would be pared back to being fairly pure C.
Well, the code written in C++ needs to stay manageable as well. If you take a look at Goops, you have considerable leeway for adding a Scheme OO layer modeled along an existing C++ layer. As I said, I am going through the context/property system, and I don't intend to change the C++ code using it significantly (well, there will be a number of macros redefined and obviously things like context-property.cc and other stuff _implementing_ those interfaces are bound to go). But there are things like a "let's implement the Ambitus engraver as an example in Scheme" project that are sort of an academic exercise because of hand-cranking a lot of stuff. And there are a few examples in snippets and/or regtests that actually use Goops, and they are ad-hoc-ing some artificial and arbitrary structures together that make understanding matters harder for the average reader. If the context/property system has a _natural_ Goops/Scheme interface, then you have an object oriented _framework_ you can get into. Doing a full-featured engraver in Scheme, including interfaces, grobs, mobs, event-classes, whatever, is then just an exercise of following existing practice and using existing structures and mechanisms. You don't need to make it all up. Learning how to _use_ stuff is orders of magnitude easier than learning how to _invent_ stuff. Most importantly: you don't need to make design decisions. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
