[chuck-users] Intraspection - an example of what I'm attempting
aturley at acm.org
Tue Nov 9 13:27:12 EST 2010
Just to be contrarian here, I would like to point out that
"instanceof" and run-time type checking are generally considered a bad
idea in OO languages. Take a look at these to start:
http://www.artima.com/intv/constP.html (see the section "When to Use RTTI")
Maybe you could argue that for quick scripts the benefits outweigh the
problems, but I think I would look harder for an OO solution. Granted,
Chuck has somewhat limited support for OO, so maybe we just don't have
the tools we need for a better solution (multiple-inheritance [also
problematic], dynamic dispatch, type-safe downcasts, interfaces, etc).
I'm not trying to make the great the enemy of the good here, I'm just
saying that there might be better ways of solving this problem, at
least from a software engineering standpoint.
2010/11/9 Kassen <signal.automatique at gmail.com>:
> On 9 November 2010 18:46, Michael Heuer <heuermh at gmail.com> wrote:
>> Right, that's why I proposed className().
>> A real instanceof keyword would return true for all of
>> (myUgen instanceof SinOsc.class)
>> (myUgen instanceof UGen.class)
>> (myUgen instanceof Object.class)
> I'm a bit lost about this notation. Is this in the C++ stuff? I'd be happy
> with "my_ugen.instanceOf( SinOsc )" returning true or false as well. This
> would probably make code smaller and it would make debug printing slightly
> more complicated, though we can simply print the object and get a (useless)
> memory address and it's type.
>> which would help with Kas' use case. How about
>> fun String className()
>> fun String classNames()
> where ".classname()" would be equivalent to ".classNames()[
> .classnames().cap() - 1 ]", assuming we go from the most general to the most
> specific right? I'm not sure about that order yet. It will depend on whether
> we'd mostly be happy with some general info and would go into the details
> more rarely or whether we would tend to try something specific, then go up
> the tree until we encounter something that would hold. I suspect the first
> case to be more common. That's a bit of a detail though.
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users