[chuck-users] Latest on subclassing UGen within ChucK?

[Chris Harris]

On Fri, Feb 22, 2013 at 7:55 AM, Kassen <signal.automatique at gmail.com> wrote:

>> If this sort of subclasses can't work, a nice improvement would be for
>> ChucK to provide an error here. Is there any legitimate reason to
>> subclass a UGen in ChucK language? If not, attempting to do so should
>> generate a compile error. Alternatively, maybe trying to chuck a
>> non-C++ Ugen subclass into another Ugen (and especially into dac)
>> should throw a runtime error.
>>
>
> As I see things there are valid reasons to want this and wanting to
> extend UGen or a particular type of UGen makes sense, both
> syntactically and as a way of working with sound.
>
> While it is not a "error" I could this see being grounds for a
> "warning" that points the user towards ChuGins. For me a "error" is
> going too far; these are classes and classes can be extended, while
> the end result is not what we'd intuitively want there is no error on
> the syntax level as such, I feel. I can see how this might be grounds
> for debate though.

Agree that you might want to be able to extend a particular UGen. For
example, something like this might be useful for something or other:

class MyCosine extends SinOsc
{
    1 => int timesPlayed;

    fun void increment()
    {
        1 +=> timesPlayed;
    }
}

And clearly you should also be able to have a variable of type UGen,
that could hold any concrete ugen.

I think if we were handling this sort of situation in Java, then UGen
would be an abstract class; you can't instantiate it, only subclasses
that actually implement certain critical methods. And you can't
actually write the relevant methods in the ChucK language, so
attempting to extend a UGen in ChucK would fail. Of course, that would
require abstract classes, which may not be worth adding for for that.

> I recommend a mail to the list over staring at things for hours.

Oh, you must mean the dev list? I was wondering if I was getting too
technical here anyway.