Re: [sc-users] SuperCollider 3.3. alpha release

Subject: Re: [sc-users] SuperCollider 3.3. alpha release

From: felix <felix@xxxxxxxxxxxxxxxxxxx>

Date: Fri, 26 Dec 2008 18:53:40 +0100

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=99l7UnSi6tWrCdS3bHomc3W5/Zrhoomr53JhSBD9Ihc=; b=sfjLnxAmi/eBJuBqep9UKf5Vbi5biJo5uEnrgPUM+UlgiD+snifDx9DrkM2zek30FX IqKv3FAD/vaenQfCUkQ8HPtiy3FKh3wL5d2w845xks+srQaSNbbENxcREHN4i9p8tf41 lKEXxv40iqUUTLxLoUlWIhPvDlxvsn+M6hj/c=

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=ft9R5C0CSk9v0x99A+epi47rjXPl2cW12iTHc7QjskDgvaZ4S2TcZzfuArUaQ3Xt6j uKsQg9br1C3G30miTytxWkMVneiEoHG52UuNWEPASERIUoHIbnK5NKZ4XdTlLns/Fe8C p3Ewl77LybGswiZJe2Z0A+aSBpltAJ36Q3Xr4=

In-reply-to: <4fc349ba0812260812n1cd10c24hbcff401e7d72c4b3@xxxxxxxxxxxxxx>

List-id: SuperCollider users mailing list <sc-users.create.ucsb.edu>

References: <p06230914c5791425e2c9@xxxxxxxxxxxxxx> <CEBFE1B8-7681-4065-91BF-B59D6DD52292@xxxxxxxxxxx> <49543B4C.9030004@xxxxxxxx> <f20f14250812260248k2f45ee72pbe315a836f39bbf@xxxxxxxxxxxxxx> <EE746144-DB66-4750-97D9-520672EE266F@xxxxxxxxxxx> <4954E83B.3060109@xxxxxxxx> <4fc349ba0812260712h377cb1d3mf5d3cbc5197aafd4@xxxxxxxxxxxxxx> <52d6e990812260740g3a2421fale4ad485f99245ec2@xxxxxxxxxxxxxx> <4fc349ba0812260812n1cd10c24hbcff401e7d72c4b3@xxxxxxxxxxxxxx>

Reply-to: sc-users@xxxxxxxxxxxxxxxx

Sender: owner-sc-users@xxxxxxxxxxxxxxxx

On Fri, Dec 26, 2008 at 5:12 PM, Eric Lyon <audiodidact@xxxxxxxxx> wrote:

On Fri, Dec 26, 2008 at 3:40 PM, James Harkins <jamshark70@xxxxxxxxx> wrote:

On Fri, Dec 26, 2008 at 10:12 AM, Eric Lyon <audiodidact@xxxxxxxxx> wrote:
> It's easy enough to fix, but perhaps it would be better if, upon
> encountering duplicate class definitions, SC were to simply print a warning,
> and then choose one of the two class files, rather than render the entire
> application inoperable.

i agree

Hmm... my first thought is, I understand the frustration of the lib
not compiling, but I think the current behavior is reasonable. If
there's a discrepancy, it's better policy (more stable) to insist on
the discrepancy being fixed before continuing.

OTOH
why is it a feature to allow methods to be overwritten but its a catastrophic bug when a class is overwritten ?

you could more easily screw the whole system by implementing some method extensions.

rendering the application itself inoperable is the wrong way to handle it. (you can't even open class files to try to figure out what went wrong ! because it uses command-J)

all of the class name conflicts I've heard about were identical classes (BEQ suite, ProgramChangeResponder) that simply got moved or duped.

btw. eric update your wslib so that the dup ProgramChangeResponder goes away.