Some smallish comments on the current version of the spec.

[Reinier Zwitserloot]

No, my comments are focused entirely on the snippet: "Probably too late".
That sentence should not be uttered in language spec design. Especially not
when "... you had 3 months" and "that's a good point" preceded it.

 --Reinier Zwitserloot



On Tue, Nov 27, 2012 at 10:45 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

> You're mixing my comments from the other thread with the specific
> responses I gave in this thread. Please don't do that. I will respond in
> the other thread when I have a chance.
>
> Alex
>
>
> On 11/27/2012 1:10 PM, Reinier Zwitserloot wrote:
>
>> A spec is posted for 3 months and it's too late for further commentary?
>> I feel like I'm in a Douglas Adams sketch.
>>
>> I get the feeling 'too late' would have been the answer if I posted
>> these comments 5 minutes after this list was created; the very first
>> post explains how lots had already been done.
>>
>> It's language design. Specs cannot change (easily). Surely "Do it right"
>> wins over "release quickly". This spec is riddled with concessions in
>> the interest of speed-of-release. It would be nice if the spec included
>> a section explaining what's on fire, because this spec does not strike
>> me as something that needs to be pushed out, half-baked.
>>
>> Between this and my earlier commentary on how it is not neccessary to
>> burden the language with boilerplatey workarounds -forever-
>> (containers), 'half-baked' seems appropriate.
>>
>>   --Reinier Zwitserloot
>>
>>
>>
>> On Tue, Nov 27, 2012 at 1:24 AM, Alex Buckley <alex.buckley at oracle.com
>> <mailto:alex.buckley at oracle.**com <alex.buckley at oracle.com>>> wrote:
>>
>>     On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote:
>>
>>         "@ContainerFor supports the java SE platform reflection…" - This
>>         paragraph
>>         seems to make the point that it is important to differentiate
>>         @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why
>>         is this
>>         relevant? Also, later on, the examples of how JDK8 answers
>>         .get(Declared)Annotation queries indicates that differentiating
>>         these two
>>         cases in not actually important. That leaves the question of: Why
>> is
>>         @ContainerFor needed in the first place?
>>
>>
>>     This was discussed in August in the list's very first thread.
>>
>>
>>         "@ContainerFor" itself: While the stated aim is to be as
>>         compatible with
>>         existing containers as possible, there are now 2 restrictions:
>>
>>         * The container method must be "value()".
>>         * All other methods must have a default.
>>
>>         There are also many DRY violations: There's both @ContainerFor and
>>         @ContainedBy, _AND_ in the container annotation, the base type
>>         is repeated.
>>         At the very least, it is possible to eliminate both the value()
>>         restriction
>>         and one repetition of the base type by getting rid of
>>         @ContainerFor and
>>         introducing the @Container marker annotation.
>>
>>
>>     This is a reasonable suggestion, though probably too late.
>>
>>     Alex
>>
>>
>>