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

["James Harkins" <jamshark70@xxxxxxxxx>]

On Fri, Dec 26, 2008 at 11:50 AM, Eric Lyon <audiodidact@xxxxxxxxx> wrote:
> It's not "correct," it's a design decision. We disagree on whether it is an
> optimal design decision. As a counter-example, MaxMSP loads the first
> external or abstraction it finds in its search path, either at startup or
> when referenced from a Max patch file. (It prints a warning when it finds
> duplicate abstractions.) No one has ever complained about this behavior, but
> I am certain that many people would complain if MaxMSP were to crash in
> every instance where it found a duplicate external or abstraction file.

I'm not averse to a different solution -- I just think the logic is
not as self-evident as you seem to suggest. So, if there is to be any
change, we need at least a loose functional spec to outline what's
supposed to happen. The spec needs to handle not just the likely
cases, but also the unlikely, catastrophic cases that could happen
when people do something they're not supposed to do.

I see your point that overriding a core class would never be
recommended. However, the compiler can never be sure that nobody will
ever do it. Since the consequences are pretty bad, I would be really
uncomfortable if the compiler's behavior in that case were not
explicitly and unambiguously defined. While the current behavior isn't
the best for convenience, it's at least unambiguous and prevents the
worst cases.

At the very least, there needs to be an order of priorities between
the main library folder, system extensions and user extensions. That's
easy enough. The real problem is if you have duplicates at the same
level (both definitions at user extension level, e.g.). Then, the
choice is basically arbitrary, and I would say it should not be up to
the compiler to choose one magically (how? Alphabetically, random?).
So maybe compilation is okay unless there's a clash at the same level,
then it would have to fail. Maybe also a list of core class names that
would always be illegal to override -- if overrides for these classes
are found in extensions, they would be ignored, and if found in the
main lib, again there's no choice but to fail compilation totally.

Conflicting method extensions at the same level have the same problem.
I was surprised, for instance, when I had wslib installed, to find out
that my postSorted got dumped in favor of Wouter's :)  Nothing
critical there, just cosmetic, but it's a flaw that the user doesn't
have a choice what to do in that case.

hjh


-- 
James Harkins /// dewdrop world
jamshark70@xxxxxxxxxxxxxxxxx
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/