Hey Wolfgang, Kas, So, a few years ago I wanted the same thing for intelligent casting purposes. Instances of Object type respond to the method toString() as well as typeOf(), a stubbed out method in Object source code with no implementation. My solution was modify the implementation of toString() to only return the class name and inserted that into the stub for typeOf(). After recompilation, I could call typeOf() on instances (or instances of subclasses of) Object and get a string representation of that object's type. I can be more specific about the change and the files involved when I get back to my home after the holidays (Wednesday). Hope this helps! It's an easy change. -mike //-- Sent from my Tracking Device. --// On Dec 24, 2012, at 6:40 AM, Kassen wrote:

On Sun, Dec 23, 2012 at 03:45:45PM -0500, Wolfgang Gil wrote:

...

Hello chuckers

Hey Wolfgang!

...

I am looking for a reference to the 'string' object class in chuck. I am having a hard time trying to guess what methods are available for the class.

Sorry, but String is not a class, it is a primitive. Ok, it is a bit unusual primitive that sometimes acts a bit differently from int, float, dur, etc, but as far as I can remember those differences are bugs. String should be a primitive with all of the advantages (automatic instantiation) and all of the downsides (no member functions) of those.

This is talking from the ChucK side, in the C++ source things might be different; I never looked at that part of the source.

...

I also recently came across with the StringTokenizer object but it seems to work only when the token is a white space. Is it possible to assign a different token to the object?

Sadly no, not that I know of. Do we need that?

...

What gets printed is the object's type plus what I believe is a reference to memory that I am currently not interested in, separated by a colon ( TriOsc:1001f36a0)

Way cool! I've long wanted this. Could I suggest a way to get a array of types in hierarchy? That way we could get something like;

["Object", "UGen", "StkInstrument", "Sitar"] //it's all of those

or;

["float"] //floats are clearly not objects, even is strings are weird.

That would be a great help when working with groups of objects that have some things in common and not others. If, for examplle, we'd just want a egg we could simply check whether the object is a "bird" and thus would support .getEgg(), we might not be interested in whether it has more detailed functions like .getBlueFeather() . In some cases that might save a lot of checks and clean stuff up a lot. I don't like big trees of IF's.

Currently that is mostly relevant for the StkInstrument series and the Filter one, but I could see more sets like that and of course it would make sense for our own class hierarchies.

...

Happy holidays!

You too! Don't let my modest proposals keep you away from this choice reason to spend time with loved ones and food. There is probably some rule against suggesting more work on Dec.24th to people with European names. Sorry ;-)

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Since a lot of stuff in ChucK owes to Java, and java.lang.String is a class like any other, with the unique extra privilege of having its own kind of constructor using double quotes, I had a hunch that something similar may be the case here. Here's some experimental code: ----------------------------------------- "oy" => string c; <<< "tjo", c.length() >>>; <<< "tjo", c.upper() >>>; <<< "tjo", c.lower() >>>; class Y extends string { fun string toString() { return "gabber"; } } "jungle" => string o; <<< "I like " + o.toString() >>>; new Y => o; Y y; <<< "I also like " + o.toString() >>>; <<< "But why not " + y.toString() >>>; ----------------------------------------- At the top you can see the string type has at least three methods (length, upper and lower). Below you can see that you can make a subclass of string (trying the same thing with int causes an error). Below that I tried to override toString() and use it, which doesn't quite work (the second last line will not print the word "gabber", but the last will. The compiler complains if I change the return type from string to Object though, so it's clearly seeing it as an override of string's toString(). It's also interesting that if I add this line: <<< "Charred at ", o.charAt(0) >>>; I get this message [test.ck]:line(27): class 'string' has no member 'charAt' (note the word 'class'). While this: 7 => int x; <<< "Charred at ", x.charAt(0) >>>; yields: [test.ck]:line(27): type 'int' does not have members - invalid use in dot expression So while they may not have a whole lot of use as such, I'd say that strings can be viewed as classes, and more crucially they are objects - something complex that ChucK refers to rather than uses directly - a bit like arrays: int a[1]; <<< "Charred at ", a.charAt(0) >>>; ----------v------------- [test.ck]:line(31): class 'int[]' has no member 'charAt' I found the reference to upper() and lower() here after googling around: https://lists.cs.princeton.edu/pipermail/chuck-dev/2012-March/000435.html On Tue, Dec 25, 2012 at 7:59 PM, Wolfgang Gil wrote:

Hey,

Mike, your suggestion sounds great. I look forward to hearing more about it.

Kassen, thanks for the info. My german name was given to me in Venezuela, where I was born. I have not german family whatsoever. I am half venezuelan, half spanish, currently leaving in NY. Here I met my fiancée, a japanese lady I have been living with for the last four years. I use more chopsticks than fork and knife these days * * *C'est la vie ;)*

On Mon, Dec 24, 2012 at 3:03 PM, mike clemow wrote:

...

Hey Wolfgang, Kas,

So, a few years ago I wanted the same thing for intelligent casting purposes. Instances of Object type respond to the method toString() as well as typeOf(), a stubbed out method in Object source code with no implementation.

My solution was modify the implementation of toString() to only return the class name and inserted that into the stub for typeOf().

After recompilation, I could call typeOf() on instances (or instances of subclasses of) Object and get a string representation of that object's type.

I can be more specific about the change and the files involved when I get back to my home after the holidays (Wednesday).

Hope this helps! It's an easy change.

-mike

//-- Sent from my Tracking Device. --//

On Dec 24, 2012, at 6:40 AM, Kassen wrote:

...

On Sun, Dec 23, 2012 at 03:45:45PM -0500, Wolfgang Gil wrote:

...

Hello chuckers

Hey Wolfgang!

...

I am looking for a reference to the 'string' object class in chuck. I am having a hard time trying to guess what methods are available for the class.

Sorry, but String is not a class, it is a primitive. Ok, it is a bit unusual primitive that sometimes acts a bit differently from int, float, dur, etc, but as far as I can remember those differences are bugs. String should be a primitive with all of the advantages (automatic instantiation) and all of the downsides (no member functions) of those.

This is talking from the ChucK side, in the C++ source things might be different; I never looked at that part of the source.

...

I also recently came across with the StringTokenizer object but it seems to work only when the token is a white space. Is it possible to assign a different token to the object?

Sadly no, not that I know of. Do we need that?

...

What gets printed is the object's type plus what I believe is a reference to memory that I am currently not interested in, separated by a colon ( TriOsc:1001f36a0)

Way cool! I've long wanted this. Could I suggest a way to get a array of types in hierarchy? That way we could get something like;

["Object", "UGen", "StkInstrument", "Sitar"] //it's all of those

or;

["float"] //floats are clearly not objects, even is strings are weird.

That would be a great help when working with groups of objects that have some things in common and not others. If, for examplle, we'd just want a egg we could simply check whether the object is a "bird" and thus would support .getEgg(), we might not be interested in whether it has more detailed functions like .getBlueFeather() . In some cases that might save a lot of checks and clean stuff up a lot. I don't like big trees of IF's.

Currently that is mostly relevant for the StkInstrument series and the Filter one, but I could see more sets like that and of course it would make sense for our own class hierarchies.

...

Happy holidays!

You too! Don't let my modest proposals keep you away from this choice reason to spend time with loved ones and food. There is probably some rule against suggesting more work on Dec.24th to people with European names. Sorry ;-)

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

---

chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

--

http://www.wolfganggil.com http://www.wolfganggil.com/about

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

Hey Wolfgang, So I wanted to get back to you about this because this was something that I had messed with years ago. But when I looked for my modified code, I couldn't find it. So, I looked at the latest source and discovered that the stub had been removed, the code cleaned up under the hood, making my hack unviable. I took another stab at it. Since, from the user's perspective, the internal object ID isn't very useful, I removed that from the toString() method. Now, when you call toString() on an object, it returns a string representation of the class name. This is helpful in programmatically (albeit hackishly) creating a safe object coercion framework, if that's your game. Here's the link to the source: http://michaelclemow.com/projects/chuck/chuck-1.3.1.3_toString-modification.... When you unpack the archive, there will be an compiled binary for Mac OSX (Intel) called mcchuck, which is what I used to call my version. It makes me think of McDonalds… Anyway, the code compiles the normal way, if anyone else wants to try it on another system. There is also a trivial example in a new examples folder here: examples/tostring/test.ck Consider the following code: -------- // Object toString() modification SinOsc s; Object obj; Shred sh; <<< s.toString(), obj.toString(), sh.toString() >>>; // should print: SinOsc, Object, Shred if( s.toString() == "SinOsc" ) { // true <<< s.toString() + " type verified programatically!" >>>; } else { <<< "bummer..." >>>; } // here's where things get interesting/dangerous... s @=> UGen u; <<< "this UGen is a...", u.toString() >>>; // SinOsc! if( u.toString() == "SinOsc" ) { u $ SinOsc => SinOsc ss; <<< "safe coercion of UGen to SinOsc complete!" >>>; } else { <<< "no coercion because type is incorrect..." >>>; } --------- Why? Well, since this is all above board: SinOsc sin; Gain gain; sin @=> UGen one; gain @=> UGen two; one => two; one $ SinOsc @=> SinOsc sin2; two $ Gain @=> Gain gain2; <<< sin2.isConnectedTo(gain2) >>>; // 1, true I could, for instance, build an object that connects arbitrary UGens together in a specified way while remaining ignorant what UGens those really are. This could be a generic object that could operate on arbitrary UGens. Later, I could then cast (coerce) them back into whatever class they were when they were originally instantiated. At least, this is the kind of thing I wanted to do with this feature. I kept asking myself, "what good is this object hierarchy if I can't use it to write less code?!" Perhaps there's a way to accomplish the above without this feature--and, of course, better string methods would obviate the need for this--but you see what I mean. You could do similar things with arrays of heterogenous objects. Cast them all to Object type, iterate on them, move them around in an array, sort them by type, etc. Then get them all back to their original type and use them as you like. Of course, eventually, you have to decide whether you're okay with your code being useful to only you. In the end, since the developers seem to be of the mind that this isn't the way you're supposed to do it (and I don't necessarily disagree--especially this way!) I opted to not maintain my own version of ChucK to support this feature. But that's a personal preference; YMMV Anyway, I hope that this was helpful/interesting! I'd love to see what you do with it, if you use it. Best, Mike -- Michael Clemow http://michaelclemow.com http://abattoirprojects.com On Tuesday, December 25, 2012 at 1:59 PM, Wolfgang Gil wrote:

Hey,

Mike, your suggestion sounds great. I look forward to hearing more about it.

Kassen, thanks for the info. My german name was given to me in Venezuela, where I was born. I have not german family whatsoever. I am half venezuelan, half spanish, currently leaving in NY. Here I met my fiancée, a japanese lady I have been living with for the last four years. I use more chopsticks than fork and knife these days

C'est la vie ;)

On Mon, Dec 24, 2012 at 3:03 PM, mike clemow wrote:

...

Hey Wolfgang, Kas,

So, a few years ago I wanted the same thing for intelligent casting purposes. Instances of Object type respond to the method toString() as well as typeOf(), a stubbed out method in Object source code with no implementation.

My solution was modify the implementation of toString() to only return the class name and inserted that into the stub for typeOf().

After recompilation, I could call typeOf() on instances (or instances of subclasses of) Object and get a string representation of that object's type.

I can be more specific about the change and the files involved when I get back to my home after the holidays (Wednesday).

Hope this helps! It's an easy change.

-mike

//-- Sent from my Tracking Device. --//

On Dec 24, 2012, at 6:40 AM, Kassen wrote:

...

On Sun, Dec 23, 2012 at 03:45:45PM -0500, Wolfgang Gil wrote:

...

Hello chuckers

Hey Wolfgang!

...

I am looking for a reference to the 'string' object class in chuck. I am having a hard time trying to guess what methods are available for the class.

Sorry, but String is not a class, it is a primitive. Ok, it is a bit unusual primitive that sometimes acts a bit differently from int, float, dur, etc, but as far as I can remember those differences are bugs. String should be a primitive with all of the advantages (automatic instantiation) and all of the downsides (no member functions) of those.

This is talking from the ChucK side, in the C++ source things might be different; I never looked at that part of the source.

...

I also recently came across with the StringTokenizer object but it seems to work only when the token is a white space. Is it possible to assign a different token to the object?

Sadly no, not that I know of. Do we need that?

...

What gets printed is the object's type plus what I believe is a reference to memory that I am currently not interested in, separated by a colon ( TriOsc:1001f36a0)

Way cool! I've long wanted this. Could I suggest a way to get a array of types in hierarchy? That way we could get something like;

["Object", "UGen", "StkInstrument", "Sitar"] //it's all of those

or;

["float"] //floats are clearly not objects, even is strings are weird.

That would be a great help when working with groups of objects that have some things in common and not others. If, for examplle, we'd just want a egg we could simply check whether the object is a "bird" and thus would support .getEgg(), we might not be interested in whether it has more detailed functions like .getBlueFeather() . In some cases that might save a lot of checks and clean stuff up a lot. I don't like big trees of IF's.

Currently that is mostly relevant for the StkInstrument series and the Filter one, but I could see more sets like that and of course it would make sense for our own class hierarchies.

...

Happy holidays!

You too! Don't let my modest proposals keep you away from this choice reason to spend time with loved ones and food. There is probably some rule against suggesting more work on Dec.24th to people with European names. Sorry ;-)

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu (mailto:chuck-users@lists.cs.princeton.edu) https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

---

chuck-users mailing list chuck-users@lists.cs.princeton.edu (mailto:chuck-users@lists.cs.princeton.edu) https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://www.wolfganggil.com (http://www.wolfganggil.com/about) _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu (mailto:chuck-users@lists.cs.princeton.edu) https://lists.cs.princeton.edu/mailman/listinfo/chuck-users