[foreign] RFR : Move array-like methods from Pointer to Array

[Jorn Vernee]

I realize I forgot about that yesterday.

I like your implementation, but LAST should be a pointer one past the 
end of the array to iterate over all elements. That's how it works in 
C/C++ as well, where you're allowed to have a pointer one past the last 
element of a container, as long as you don't dereference it. (I've also 
added a small test to check that the returned stream has the right size)

Naming it `iterate` as well makes sense to me, as it's essentially just 
another version of the Pointer::iterate method.

Updated webrev: 
http://cr.openjdk.java.net/~jvernee/panama/webrevs/arrays/webrev.05/

Maybe not in the scope of this RFR; should Array implement Iterable<X> 
and stream()? Currently we can get a stream of pointers-to-elements, I 
can imagine people being interested in getting a stream of just elements 
as well. Or should they just convert to a Java array for that (using 
toArray())?

Jorn

Maurizio Cimadamore schreef op 2018-11-20 02:42:
> Looks good - can the code in BoundedArray be rewritten in terms of
> Stream::iterate too? E.g. if you produce a pointer to the last element
> - call it LAST - then it should be that
> 
> Array::elements()
> 
> ~=
> 
> Array.elementPointer().iterate(LAST)
> 
> Right?
> 
> Also, don't we want to rename this to iterate() too?
> 
> Maurizio
> 
> On 19/11/2018 18:20, Jorn Vernee wrote:
>> Update webrev: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/arrays/webrev.04/
>> 
>> Added 2 `iterate` methods to Pointer, one that takes a predicate, and 
>> one that takes a pointer. Should I also add tests for these? 
>> (elements() was not being tested previously it seems).
>> 
>> Thanks,
>> Jorn
>> 
>> Maurizio Cimadamore schreef op 2018-11-19 16:27:
>>> <snip>
>>>>> 
>>>>> Stream<Pointer<T>> elements(Predicate<? super Predicate<T>> 
>>>>> hasNext)
>>>> 
>>>> Yes, this is a nice idea. Maybe we'd also want to have an overload 
>>>> that just takes a `Pointer<T>` as an argument, and iterations will 
>>>> be up until that pointer.
>>> Sure, the pointer-end overload sounds like a nice idea!
>>>> 
>>>>> And this would generally applicable to both arrays and pointers. No
>>>>> guesswork involved, users iterating on pointers will have to 
>>>>> provide
>>>>> an explicit termination condition; if they get it wrong, they will 
>>>>> get
>>>>> some exception when dereferencing the wrong memory location.
>>>> 
>>>> Well, for native-allocated pointers this will invoke undefined 
>>>> behavior or possibly crash the VM (or enable access to VM internals? 
>>>> I'm not sure what security is in place there currently).
>>> 
>>> A possibility there would be to avoid using EVERYTHING as a backing
>>> region. That is, the binder could, in principle, generate regions 
>>> that
>>> are small enough only to contain the region that we actually want to
>>> access (e.g. starts at base address , ends at base address + pointee
>>> layout size). If the client is not happy with that and knows that the
>>> pointer is a pointer to some kind of a buffer, perhaps an (unsafe?)
>>> operation could be provided to relax the memory region boundaries
>>> beneath the pointer.
>>> 
>>> But overall I think we should strive for the 'no VM crashes if you 
>>> are
>>> only using the safe API' (although we don't have to get there in one
>>> step).
>>> 
>>> <snip>
>>> 
>>>> 
>>>> 
>>>>> As a final point, I think we should implement elements() using
>>>>> Stream.iterate (and possibly document it in the API).
>>>> 
>>>> Agreed. Maybe we should also rename Pointer::elements to 
>>>> Pointer::iterate ?
>>> 
>>> I like that.
>>> 
>>> Cheers
>>> Maurizio
>>> 
>>>> 
>>>> Jorn