[chuck-users] OOP and Style Qs, Operators
vtatila at mail.student.oulu.fi
Wed Mar 21 12:57:13 EDT 2007
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
> 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
> 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:
>> 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
>> object.getter() => itsValue;
>> Could be reduced to:
>> object.getter => itsValue;
>> Where l-valueness and lack of braces Would imply a method call,
>> 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
> 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:
More information about the chuck-users