[chuck-users] Dealing with String objects?

Wolfgang Gil wolfgang.gil at gmail.com
Wed Jan 9 14:24:45 EST 2013


thanks Mike,

I will take a look at it as soon as I can and get back to you

Lets get together for a listening session one of these days

On Wed, Jan 9, 2013 at 2:08 PM, Michael Clemow <michaelclemow at gmail.com>wrote:

> 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.zip
>
> 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 <michaelclemow at gmail.com>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 <signal.automatique at gmail.com> 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 at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> _______________________________________________
> chuck-users mailing list
> chuck-users at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 

http://www.wolfganggil.com <http://www.wolfganggil.com/about>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20130109/fe2e8588/attachment-0001.html>


More information about the chuck-users mailing list