Some smallish comments on the current version of the spec.

[Alex Buckley]

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