On Mar 16, 2007, at 6:55 PM, Veli-Pekka Tätilä wrote: A disconnect method is something that I can see being useful, Fair enough, especially as the module config can be changed in real time. WHich reminds me, we talked about growing arrays dynamically. If I change
Spencer Salazar wrote: the number of inputs on the fly for my OneOfN switch, and chuck new inputs to it, does this happen fast enough that I can run it in a 1::samp loop? I've never benchmarked it but somehow have an intuitive notion that allocating new memory might be heavy.
- 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. Hmm I still think it might be needed. The code for my connect method is: function void connect(UGen output) { out => output; } Where out is the Gain module. That is I need something to chucK to my output. And I presume that must be another UGen. As I cannot inherit from a UGen, I guess the gain module might be my only choice.
- ALso in the test script, I would like to initialize my UGen array anonymously Fortunately, there is the 'new' operator, which, similar to its counterparts in Java and C++, anonymously allocates an object of the specified type. [ new SinOsc $ UGen, new SawOsc, new SqrOsc ] @=> UGen @oscs[]; Ah that's the ticket, thanks. In Java you need the new operator for every non-primitive type. But in C++ not using new means that the variables live in the stack just like other function arguments. So are chucK objects, not allocated with new, also stack variables? HOw's the VM like, by the way, would it make sensse to hand-code anything in ChucK assembler?
Note that the initial $ UGen (typecast to UGen) is needed to tell the compiler that this is a UGen array, not a SinOsc array. Ah I see, sort of. Is this dollar thing documented in the manual?
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. Ah, that's bad. I mean the arrays are homogenous then and each element must be of the specified type or some derived type. As polymorphism based on a method name, aka duck typing, is not supported as this is a Java:ish language, will there be a template mechanism or the ability to downcast arguments? For example, Java's ArrayList can store objects but you can then downcast them to the desired type or let the compiler do it for you which is called autoboxing I think.
There is no style manual, but I think following the lead of the examples and Java is probably the best approach at this point. Ah yes, that sounds reasonable. And Howabout the braces are they commonly
One practice you might consider adopting is returning the value of the parameter in your set method <snip> myClass a, b, c, d; 1 => a.p => b.p => c.p => d.p; Ah the good old chained assignments. ANother possibility would be to return
Another way to do it might be to add some reflection API through which you can ask for the method and call it for a particular object. I've noticed there's already a class named Class, based on some error messages. What ,members does it have? Which brings us to inheritance. You said that interfaces are considered as a future extension. IF it works like Java. does this mean I can currently inherit from only one class even if it would be abstract? Would it be feasible to keep track of how many instances a particular class has as a static member? Sure you can inc the count in a constructor, but one would need a ddestructor to know when to decrease the count? Or alternatively, have uggly method calls for upping and downing the count explicitly, as in COM. the K&R style or the BSD/Allman style? I think Java and most other C-like langs have adopted the former. I like the latter myself for some fairly specific reasons, although being a fan of the K&R book. In addition to preferring to comment decisions right after the opening brace, I use magnification and braille in coding which means a limited viewport. Only a handful of chars magnified and max 40 in braille, though you stil have to scan that with your fingers. So keeping the braces aligned makes them easier to spot. This is also why I comment end braces, as you can easily check Which brace it was using sspeech or braille. Though these are definitely minor things I guess I'd ideally take the ADA syntax foo some stuff end foo. I guess it might be slightly more musician friendly anyway, than C:ish things like braces, the pre and post dec and inc ops, augmented assignments and other such thingies, most of which are just syntactic sugar. But I've gotten used to them in C; Perl and java, so I ain't complaining. Speaking of operators, I really like the assignment operator in ChucK. AS I've never been a fan of doubling a symbol to give it another meaning, I once suggested that some language should have something similar to what ChucK has only right-associative. So I was very pleased to see => in ChucK: and that's even left-associative, meaning potentially more user-friendly. Which brings me to the chucK equality operator ==. Why two equals signs, one would be much more logical as we have a dedicated assignment operator anyway, and as >= has one equals sign, not two. Another thing I like is the syntactic sugar for handling setters as properties. That is: object.setter(firstArg); can be turned into firstArg => object.setter; So you don't have to know it is a function call behind the scenes. But could this also be exteneded to cover getters as well. Namely that as an l-value: object.getter() => itsValue; Could be reduced to: object.getter => itsValue; Where l-valueness and lack of braces Would imply a method call, provided that the class does not have a public data member named getter. But this is a bit more ambiguous I know, and there might be some pathological cases in the context of the whole language if this kind of addition is made. It is hard to judje the extent of such changes, though they are easy to suggest, from the user point of view. Is there a BNF grammar for chucK, by the way? I don't know Yacc yet, but should probably look into it some day. the object itself so you could chain method calls. A Perl module I saw recently did just that to let you construct English looking regular expressions via huge chains of method calls. Another funny consequence is in Java: String s = "foo"; s.toString().toString().toString(); Doesn't make any sense at all, but is legal, because all objects including String have a toString method. ChucK would benefit from one, too. As well as more formatted printing, hint sprintf is in very many languages these days including Java, C++, Perl, Python and even PHP.
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? [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. Why is the message talking about another value, though? Conceptually, one does not think of the function's formal argument as being a value. ONly when it is an actual one, it has a value at that point. But this is a minor semantic quibble.
There are various other practices for naming instance data. Although not really for oop use in Perl, I could use the prefix my for instance data and our for class data. And some Java styleguide recommended its and their, too, which I kinda like as well. I read code partially with synthetic speech so if it sounds like English that's a plus. You could infer from this i like SQL as well. Other practices, hmm, the SymbianOS uses a small i for instance and a small letter a for function arguments. SO a player class might have a member named iTunes, pun intended.
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 Ah yes, will do that. Although it means I'll have to call it explicitly anyway. Would be nice to have constructors some day, <sigh>.
snipped plenty of stuff here. Thanks for the rest of the ansers, too. Apparently the typos are my bad, again, and crashing in null pointers will be fixed. I think I'll wait for the official next release to try And see that it does not crash any more, as I'm pretty happy with this one. IS the manual updated in sync with the next release? -- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/