ooc-dev team mailing list archive

[Amos Wenger <amoswenger@xxxxxxxxx>]

On Sun, May 16, 2010 at 7:09 AM, Bart van der Werf <bluelive@xxxxxxxxx>wrote:

> i think victim should come before array for this to happen.
>
> Regardless, I think we all agree bound-checking is good in most cases
(plus, you can still use raw arrays if you really want to - and recent
versions of gcc are smart about removing unneeded bound checking)

> When allocating a new uninitialized ooc array, what value is in the slots ?
>
> Filled with '0', because gc_malloc is used, and it's something it
guarantees.

> 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.
>
> I was wondering about the 'elementSize' thing - if we're gonna do that, it
comes much closer to an ArrayList, and we could just as well store a 'class'
field (which contains a 'size' field plus a name, etc.).

I haven't given much thought to mutable arrays, I would've assumed they
weren't but maybe it's a good thing to make them resizeable? How so, then?
Append with += ? I'm waiting for your suggestions on this one, people.

> Does the no alliasing rule hold ? if you can do an 'as Int*' ?
>
> That's a good point, but - you can only do 'as Int*'  for an Int[]. Every
other type (especially with a different elementSize) should be prohibited.
What really happens when doing 'as Int*' is an access to the 'data' field of
the array underlying struct.

> Do arrays allow copyless slicing ?
>
>  That would be better achieved with an object, not a built-in data
structure, right?

> 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.
>
> Same issue - this would be easy if arrays were in fact objects. About
parameterizing (e.g. Array<T>), I'm not sure though. Generics aren't
template, this may not be as trivial as you think.
One could definitely do a cover from Int[] or something.

But maybe it's better to keep arrays pretty simple, as basic building
blocks, allowing to build more advanced data structures, when used as class
members. Isn't it?

Having real meta-programming would help having pure-ooc arrays (e.g. doing
away with the 'array.h' header), but I'm not sold on a syntax for that
either.

Amos Wenger (nddrylliog)


> 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
>>
>>
>