[chuck-users] OOP and Style Qs

[Spencer Salazar]

Hi Veli-Pekka,
please see responses below.

On Mar 16, 2007, at 6:55 PM, Veli-Pekka Tätilä wrote:

> 1. Is the code in the class OK in terms of style and implementation  
> i.e. is
> there something highly uncanonical in naming or some things that  
> could be
> done smarter for such a simple thing?

Looks pretty good from here.  A disconnect method is something that I  
can see being useful, though.

> - In particular, I'm not sure if the gain module is needed in the  
> output.

It shouldnt be needed, but may be useful if you wanted to adjust the  
gain of the entire UGen unilaterally.

> - Is there a better way to grow the array on demand? In Perl I can  
> just
> assign to higher indeces and it will grow, or use the push function  
> to add
> an arbitraryly sized list at the end. And Java has array lists, too.

Yes, your approach is currently the only way to grow the numeric part  
of the array.  It is a goal to eventually have the ability to  
dynamically adjust the capacity of an array.

> - ALso in the test script, I would like to initialize my UGen array
> anonymously without having to make up variable names for each  
> object and
> manully assign the indeces, I'm lazy  I guess.

I don't see this as laziness, necessarily--it is a completely  
legitimate thing to want to do.  Fortunately, there is the 'new'  
operator, which, similar to its counterparts in Java and C++,  
anonymously allocates an object of the specified type.  Amending part  
of your code below to use this operator would look something like this:

> UGen @oscs[3];
> // Our oscs.
> new SinOsc @=> oscs[0];
> new SawOsc @=> oscs[1];
> new SqrOsc @=> oscs[2];

or even this:

> [ new SinOsc $ UGen, new SawOsc, new SqrOsc ] @=> UGen @oscs[];

Note that the initial $ UGen (typecast to UGen) is needed to tell the  
compiler that this is a UGen array, not a SinOsc array.

One caveat to this technique is that you won't be able to set any  
parameters to your oscillators beyond those that are present in every  
UGen.  Notably, UGen doesn't have a frequency parameter.

> - Is there a style manual for ChucK? Until we can inherit from UGen  
> it would
> be great to have a common set of method names for UGen like modules.
> Currently I've drawn my influences from Java and Dinky.ck.

There is no style manual, but I think following the lead of the  
examples and Java is probably the best approach at this point.

> - Which reminds me, does chucK support duck typing? Abstractly put,
> Suppose a class or interface c with the method name m and an object  
> o such
> that not o instanceof c. Does o.m() get called in its own class,  
> even if o
> is not related to c by inheritance. Polymorphism that works based  
> on a name
> is there in Perl and Python, I think, where as Java is stricter and  
> requires
> that the object be a subclass or interface implementation of c, a  
> common
> method name is not good enough.

ChucK follows the Java model, requiring explicit inheritance for  
polymorphism to be (ab)used.

> 2. How is ChucK naming like?
> Suppose we have a parameter p of type t. I would like to create its
> accessors as:
>
> - function void p(t i); // set
>   function t p(); // get
> Yet although chucK supports overloading functions, it does not let  
> them
> differ only by return type, right? In a test class I get stuff like:
>
> [test.ck]:line(5): function signatures differ in return type...
>
> The same thing with JAva really and I do understand it could often be
> ambiguous. Perl is one of the few languages in which this works  
> well as
> scalar is the only primitive scalar type and it has list and void  
> context to
> make things more or less unambiguous. But ChucK is not Perl, nough  
> said.

Yes, ChucK is a strongly typed language, which generally require  
return types of functions to be known at run-time.  One practice you  
might consider adopting is returning the value of the parameter in  
your set method, i.e.

> function t p(t i); // set
> function t p(); // get

This approach also makes things like this possible, which is  
sometimes appealing (or appalling):

class myClass
{
     int _p;
     fun int p( int __p ) { return __p => _p; }
     fun int p() { return _p; }
}

myClass a, b, c, d;
1 => a.p => b.p => c.p => d.p;

> - As I think parameters with the verbs get and set are slightly  
> redundant,
> if boolean stuff starts with e.g. is , I thought I would use:
> function t p();
> function setP(t i);
> However, if there is already a data member named p chucK does not  
> let me hav
> a member function named p in the same class, right? After modding  
> my test
> class, I got:
>
> [test.ck]:line(4): function name 'p' is already used by another value

Yes, this is similar semantically to many C-like languages.  A common  
practice that I see is, for a given parameter p, to call it _p and  
then have the accessors use p, as in the myClass example above.  m_p  
(for member variable p) is another popular approach.

> 3. To save some duplicated code, and as there's no constructor  
> support, it
> occurred to me I could write a function that given an array of UGens,
> instanciates my audio switch (OneOfN), populates it and returns a  
> reference.

Ah, yes, a "factory" method.  You might consider making this function  
a static member function of the OneOfN class rather than a non-class  
function.  This has the advantage of making the function accessible  
to all shreds if OneOfN is a public class.  (Its also liable to  
satisfy any object oriented nitpickers reading your code.)

> What might be wrong, i.e. why does it think an array of UGen is  
> just a UGen rather than an array? I'm mightily confused here. The  
> code:
> [...]
>    choices.caps() => int max; // Cache it, so only one method call.

I believe this should be choices.cap() (no 's').

> 4. When I use my audio switch to determine whether audio flows  
> through, i.e.
> as an audio relay one of whose inputs is practically disconnected  
> (I've
> patched blackhole there), it seems to work OK i.e. I get the sound of
> silence when expected. However, if I change my array initializer in
> OneOfN.ck:
>
> from:
>
> blackhole @=> newIn[i]; // Not connected initially.
>
> to
>
> null @=> newIn[i]; // Not connected initially.
>
> Strange things start to happen. I don't get a null pointer  
> exception at
> runtime as I would expect in my test script, as the unconnected  
> input is
> actually null. In stead ChucK crashes spectacularly with the standard
> WIndows XP dialog about it.

Yes!  This is a known bug in the currently release version.  It  
should be fixed in the current release candidate, and the upcoming  
release as well (feel free to test/try to break it at your convenience).

> [Speaking of Dracula, I'm just reading Frankenstein, talk about funny
> co-incidences. Hmm what's the code name for the next release?]

Coincidentally, frankenstein was the code name of the original ChucK  
release.  dracula is the code name for the current series of ChucK  
releases, whatever that means, so the name will probably be dracula  
for a while.

> I think these were my questions. As I tend to have a bad habbit of  
> asking
> all too much, when someone who knows far more than I do is around, I'd
> actually be pleased if even half of these would get answered  
> eventually,
> <smile>.

No worries!  We're all here to help.

spencer