[chuck-users] object / class hacking

Stefan Blixt stefan.blixt at gmail.com
Thu Oct 1 02:03:54 EDT 2009


Yeah, that's like what I did with my hash set example earlier (bar =
hashcode). It's how the hash collections in Java works, it requires a
hashcode function to be present.
http://java.sun.com/javase/6/docs/api/java/util/HashSet.html

Two problems with your ObjectString solution:

1: bar needs to contain a string that uniquely identifies the object it's in
- no two objects may have the same bar string. There are a lot of tricky
stuff involved with this (how do you generate an object and the another
object equal to the first? How do you make sure that two different objects
never get the same bar string?) Note that a hashcode doesn't need to be
unique, all it does is generate some string that sorts the object into a
group used for fast retrieval.

2: There is no way to iterate over associative arrays! Try this code:

int a[0];
<<< "Size: ", a.size() >>>;
7 => a["hello"];
<<< "Size: ", a.size() >>>;

The size() result (which is crucial for a for loops that wants to iterate
over this array) keeps returning zero even though you added an element.
Also, you don't know what to index the array with, even if you got the for
loop going. What ChucK needs is some way of getting hold of all associative
keys used in an array. Something like this:

a.keys() => string keys[];
for( 0 => int i; i < keys.size(); i++) {
        a[keys[i]] => Object value;
        [...]
}

...which I think is a thing that already has been touched upon in this
thread.

/Stefan

On Wed, Sep 30, 2009 at 9:30 PM, Andrew C. Smith <acsmith at willamette.edu>wrote:

> > A check check in the source codes suggested chuck is using std::map for
> the
> > associative array part. Then it is just to export to the chuck language
> > iterator type and functions begin(), end().
>
> Right, but as I understand it Robert wanted to use an array of
> Objects. It seems that the associative array only works to associate
> strings with values, so (for example) you couldn't do:
>
> int foo[0];
> 1 => foo[Bar bar];
>
> because the associations can't take an Object. You'd be left with
> creating a symbolic string for every created Object, rather than
> having an array of Objects that you could search through. Iterating
> over the array seems so fast (especially if they're sortable) that
> throwing a bunch of strings into the mix would be tough. Side thought:
>
> class ObjectString {
>  Object foo;
>  string bar;
>  ...(set, get, whatever)...
> }
>
> ObjectString hello;
> Object @ null;
> Object m[0];
>
> SinOsc sine => hello.foo;
>
> hello.foo @=> m[hello.bar];
>
> ...
>
> null @=> m[hello.bar]; // removes object
>
> So that then if you want to know if you have your object (hello), you
> can just ask if m[hello.bar] != null. I'm not sure whether this code
> will work or not, though, and all calls would have to be explicit (not
> iterative--so you couldn't set all m[] Objects to a particular
> parameter, I believe).
>
> Also, the array doesn't seem to be a contiguous block of memory now
> that we have operators << and popBack() and other dynamic array types.
>
> I remembered, .size() is a get method pretty much like .cap(), but
> .size(int) is a set method. Maybe .cap() is vestigial?
>
> Andrew (thanks, Hans, for catching how I only sent this to you)
>
> 2009/9/30 Kassen <signal.automatique at gmail.com>:
> > Hans;
> >
> >>> What is the difference exactly between .cap() and .size() ?
> >>
> >> Don't know. I just needed array size, and started using size() :-).
> >
> > Working from memory;
> >
> > In previous versions of ChucK .cap() could be used to get the length of
> the
> > array, it could also (undocumentedly) be used to (re)set the length
> though
> > at the expense of re-initialising all elements.
> >
> > In 1.2.1.2 .size() was added which can be used exactly like .cap() to get
> > the size of the array. It is overloaded to set the size, which should not
> > re-initialise the existing elements (this works as far as I'm aware) and
> > which should initialise any new ones added (this does not always happen
> in
> > practice). In the meantime .cap() is no longer overloaded to set array
> > length.
> >
> > Why this is like it is I don't know, in theory it might have broken some
> > code, like how we could set all array elements of a array of type int to
> 0
> > while maintaining the same length using this;
> > foo.cap( foo.cap() );
> >
> > more generally; using that we could re-initialise all elements without
> being
> > aware of the type of the array. In practice I never heard about this
> > resulting in any complaints.
> >
> > The current situation, however, *is* a bit unclear (if much preferable to
> > the old one). I can see how potentially breaking code would be preferable
> to
> > dramatically changing it's functionality without warning but I'm not sure
> > that is the reasoning that led to the choices made.
> >
> > Personally I use .cap() to get lengths and .size( int) to set them,
> purely
> > for readability reasons.
> >
> > 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
>



-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091001/72e4e0e8/attachment.html>


More information about the chuck-users mailing list