[chuck-users] Reply to Kassen on shreds, functions and objects

[Jim Hinds]

Apologies: I broke mailing list rule #1: "dont use subject lines like  
Re: chuck-users Digest, Vol 28, Issue 23"  My bad.

HI.  The function is a function.  It is only a function and things  
within it (the string beep) are totally invisible to anything outside  
of the function definition.  (That's only partly true as they  
theoretically could be passed by reference to something else, just  
ignore this fact for now.)  'beep' does not belong to the sporked  
object.  In fact, the name 'tester' isn't likely to be known to the  
sporked object.

Chucks object and class capabilities are growing, but as they say on  
the street, they are not all 'that.'  It has to do with inheritance,  
namespaces, run-time magic, and lots of stuff that would kill the real- 
time capability of a shred.   All these are fun problems for a  
computer science person, but not so very fun if you just want to make  
chuck sing.  I usually just pretend that sporked things are not  
objects at all.

A shred is more like an independent agent: a baby.  All it knows is  
the function that is used to give it birth.  That function must know  
how to do all the communication to and from the outside environment.   
That function can call other functions (in other classes, possibly),  
look at global variables (in the same source file) and such.

I'm sticking with global variables, at least for the short term.   
Programs in chuck are usually on the smallish side and a few global  
variables won't hurt the music and are just a necessary evil.  I give  
those global variables useful names like "second_violin_bow_velocity"  
or some such and to keep track of them better.

Jim Hinds
http://www.jahbini.org/

>
>
> On Nov 15, 2007 4:46 PM, Kassen <signal.automatique at gmail.com > wrote:
> Dear list,
>
> Shreds are objects (of type Shred) and functions aren't objects.  
> This is all good and well but it gets harder when we spork a  
> function and the function becomes a Shred and hence a Object.  
> Consider this;
>
> ------------------------
> fun void tester()
>     {
>     "boom" => string beep;
>     while(1)
>         {
>         <<<beep>>>;
>         second => now;
>         }
>     }
>
>
> spork ~ tester() @=> Shred foo;
> 5::second => now;
>
> "clik" => foo.beep; //this doesn't work
>
> day=> now;
> ----------------------------------------
>
> It's not so clear to me *why* the offending line doesn't work. Maybe  
> I'm misunderstanding something or making a syntax error but I think  
> that what we are seeing here is a loss of namespace that would be  
> useful and I don't understand why this happens.
>
> I also tried stuff along these lines;
>
> ----------------------
> class Bar extends Shred
>     {
>     //stuff including variables and a constructor
>     }
> ------------------------------
>
> If I do that I can instantiate a "Bar" but all it does is run it's  
> constructor; I can't manage to spork a Bar or assign a sporked shred  
> to a Bar. I can also make a array of Bar's but all that gets me is  
> the constructor running;
>
> ---------------------------
> class Bar extends Shred
>     {
>     static int number;
>     <<<number++>>>;
>     }
>
> //print a series of numbers, no shreds in sight
>  Bar array[5];
> ----------------------------------
>
> So, now I'm quite happy I said so many times that there are no  
> "stupid n00b questions" because now it's my turn to ask exactly what  
> a "Shred" is because I'm starting to feel like I have no idea. :¬)
>
> Could somebody please explain to me exactly what's going on here?
>
>
> Yours,
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071116/388f2c5c/attachment.htm