Some smallish comments on the current version of the spec.

[Alex Buckley]

If that's the scope of "too late", then I can promise you that a 
method-level @Container annotation would _not_ have been "too late" if 
suggested three months ago. It's a good, tightly-scoped idea. But you 
didn't comment three months ago, and now the feature is done, sorry.

Alex

On 11/27/2012 3:21 PM, Reinier Zwitserloot wrote:
> 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
> <mailto: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>
>         <mailto: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
>
>
>