[chuck-users] OOP and Style Qs, Operators

[Veli-Pekka Tätilä]

Hi Spencer,
Very useful info. I'll snip a lot and only comment the stuff I have more 
questions or additions for.

> Additionally, you can save a little time/memory by using arrays of
> null UGen references, rather than arrays of UGens.
Hmm isn't this a bit suspicious, in terms of semantics. I mean the default 
of instanciating arrays as though objects where already constructed. If they 
are added, that design cannot support classes that lack a parameterless 
constructor, singleton classes in which it is private, and abstract classes 
or interfaces which cannot b instanciated in the first place. IS string also 
a class? I read something to that effect but cannot find its methods 
anywhere. I don't seem to be able to do much apart from concatenating them.

>> will there be a template mechanism or the ability to
>> downcast
>> arguments?
> You can always cast them to back to what they were initially, using
> the $ operator.  You just have to actually know what they are.
Ah that's the question. Quite OK for homogenous stuff but I can already 
imagine a design in which this is not known. IN which I have to branch on a 
type name. That's a bad smell in OOPy circles often but not always. Many 
recursive data structure dumpers require, for example, that you know whether 
an element is a single item, some reference to an array or object or 
something else. Not very relevant to chucK right now, though, as there's no 
serialization support.

> consider that most programmers coming to ChucK will think that ==
> makes the most sense, while arguably non-programmers won't have any
> particular predisposition to whether = or == is better.
OK, but then again one could claim the same about => if it didn't serve  a 
dual or triplle role as a way to pass function arguments and connect uGens. 
I'd like to be able to overload => on my own classes some day, though.

> used to = for assignment, as expressions involving = are caught with
> a compile-time error instead of a more subtle runtime error.
Yes, agreed. Some forms of Basic are the worst, they use = in a boolean 
context to mean equality but if it is not in a control structureand looks 
like a plain assignment, that's what it is. Pascal has := too.

>> 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.
> This is an interesting idea, but it wouldn't work right now because
> functions without parentheses are already rvalues (returning the
> function address I believe).
Hmm interesting. FUnctions as a first-class datatype are very nice and that 
makes sense for just that, functions and static methods. But I don't see 
much sense in getting the address of an instance method as you cannot 
determine that its invocant is of the correct type anyway. I think perl 
let's you do that, but hey it's Perl, <smile>.

> don't know yacc either, but in my experience its pretty easy to pick up 
> the
> basics by just reading a .y file.
Ah I'll take a look. I'll be lazy and ask if there's a direct URL to the 
current CHucK yacc  grammar. I usually don't get the source, though in this 
case it might be beneficial.

-- 
With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/