ArrayMirror

[Paul Benedict]

Yeah, that sounds reasonable to me. Also, great work on this first cut.
It's very exciting to these features. Kudos to you and Maurizio and whoever
else is working on this project.

Cheers,
Paul

On Wed, Jun 15, 2016 at 1:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> The short answer is: this is a first cut, and we had to pick one way or
> the other just to have something concrete -- and if we had done it the
> other way, someone probably would have written the exact same mail asking
> "Why did you not have a separate ArrayMirror".
>
> The reality is that neither choice is great; it's a classic "lumping vs
> splitting" choice, and this one is pretty close to 50/50, meaning that
> whichever way you go, there's a good argument to go the other way.
>
> We erred on the side of "splitting over lumping" in this first cut,
> because that approach tends to be better at disclosing latent issues than
> the opposite, but don't make any assumptions about how things will look in
> the end based on this first cut.
>
> Our interest at this point is to give people a chance to explore the
> usability and expressiveness of the API.
>
>
>
>
> On 6/15/2016 1:55 PM, Paul Benedict wrote:
>
>> I have a question pertaining to ArrayMirror and why it was modeled as it
>> is.
>>
>> In the current JLS [1], an array is a subclass of Object. Given that int
>> is
>> a value, and int[] is an Object, is Box<int> a value and Box<int>[] an
>> Object too?
>>
>> Presuming that analogy holds true with Valhalla, why not model an array as
>> a ClassMirror with an isArray() member? Better yet, with Arrayish<T>
>> coming
>> down the pike with T acting as the component type, ClassMirror could be
>> sufficient in itself -- without isArray() -- and ArrayMirror could be
>> dispensed with.
>>
>> [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-10.html#jls-10.8
>>
>> Cheers,
>> Paul
>>
>> On Wed, Jun 15, 2016 at 12:19 PM, Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> wrote:
>>
>> Hi,
>>> I've just pushed a new Valhalla-centric reflection API; the main goal of
>>> this API is to allow programmers to reflect over the contents of the new
>>> generic classfile, as well as to programmatically create class/method
>>> parameterizations and perform dynamic operations (method calls, field
>>> access). More information about this API can be found at in the javadoc
>>> of
>>> the root of the hierarchy - available here:
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/x-reflection/valhalla/reflect/runtime/RuntimeMirror.html
>>>
>>> There's also a pretty comprehensive end to end test showcasing many of
>>> the
>>> API features:
>>>
>>>
>>>
>>> http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/0f7a9b8602e5/test/valhalla/test/valhalla/reflect/runtime/SimpleReflectionTest.java
>>>
>>> Note: this is just an initial API round/prototype. As such we didn't put
>>> too much effort on things like naming conventions etc. and we focussed
>>> instead on the set of features we would like this new API to have.
>>>
>>> We are obviously interested of any usability issue/bugs you encounter
>>> when
>>> using/learning this API!
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>>
>