ooc-dev team mailing list archive
-
ooc-dev team
-
Mailing list archive
-
Message #00147
Re: Ooc Revision Consideration - Arrays. Coming with a working implementation.
int array[10];
int victim = 42;
array[11] = -1;
i think victim should come before array for this to happen.
When allocating a new uninitialized ooc array, what value is in the slots ?
The underlying c: shouldn't there be 3 or 4 fields, i'm missing an
'elementSize' and possibly a 'stride', a 'capacity' field may also
make sense if arrays are mutable in length.
Does the no alliasing rule hold ? if you can do an 'as Int*' ?
Do arrays allow copyless slicing ? iterators ? inheritence ? maybe add
a basetype below Int[] like Array<T> that supports the api and allows
for non arrays to get close to the api.
On Sat, May 15, 2010 at 6:30 PM, Amos Wenger <amoswenger@xxxxxxxxx> wrote:
> Hi everyone,
>
> I've been working on pure ooc arrays, and 1) rock-ooc-arrays is
> self-hosting again now, 2) here's the ORC for it:
> http://github.com/nddrylliog/middleearth/blob/master/drafts/Arrays.md
>
> Now waiting for your comments / proposals / questions / trolls / general
> input before merging into master.
>
> A note for those wanting to try the ooc-arrays branch: older versions of
> rock will choke on that line in structs/ArrayList:
>
> operator as <T> (array: T[]) -> ArrayList<T> { ArrayList<T> new(array data,
> array length) }
>
> Because 'T[]' used to be interpreted as 'ArrayList<T>'
> You should just comment it when compiling rock-ooc-arrays with an older
> rock, and not forget to uncomment it afterwards.
>
> Also, considering these are pretty big changes (adding up with properties,
> ?!, and ACS), what about a rock 0.9.1 soon?
>
> Enjoy!
> Amos Wenger (nddrylliog)
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ooc-dev
> Post to : ooc-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ooc-dev
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References