lilypond-devel
[Top][All Lists]
Advanced

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

Re: Working on issue 665, how to proceed?


From: David Kastrup
Subject: Re: Working on issue 665, how to proceed?
Date: Sun, 17 Nov 2019 17:19:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

<address@hidden> writes:

>> -----Oorspronkelijk bericht-----
>> Van: Thomas Morley <address@hidden>
>> 
>> You use (oop goops).
>> Is there need for it? This is a question not a hidden request!
>> Speaking only for myself, I'm not familar with it. So reviewing your code 
>> will be
>> difficult for me.
>> We don't use it much so far.
> I am a C ++ programmer and like to use classes. As you might have seen
> I use several classes, and as far as I know goops is needed for that

Goops is a framework for classes.  It is a very, very generic framework
which means that it doesn't really prescribe much of a programming
style, and we don't have use of it established.

Using methods and generics (or what Guile calls differentiating function
implementations according to type) on Guile-1.8 has significant
performance impact.

There are some isolated modules using Goops that don't impact a lot of
other stuff (I think a central part of the part combiner).

In general "I am a C ++ programmer and like to use classes." is an
iffish proposal for things interfacing with user programming and also
gives some interplay with who will work with code.

MusicXML conversion _is_ isolated from what users in general do.  And it
definitely warrants building an extensible framework for conversion.  So
using it _if_ it helps extending the conversion capabilities easily
seems like a reasonable idea as long as one does not "infect" other code
with generics (like overloading existing operators).  The performance
for MusicXML conversion itself does not seem critical.

> I did use a lot of define-method, as it is easy this way to be type
> save.

I don't think the cost justifies the effort here.  Scheme is not
intended as a "type safe" language.

-- 
David Kastrup



reply via email to

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