Helping to find the usefulness of a proposal

[rssh at gradsoft.com.ua]

>>
>>  Yes. I think all understand this.
>> // btw, near all proposals in project coin are easy implementable.
>>
>
> I do not share that opinion.
>
> There are no simple language changes in Java.
>

Of course, word 'simple' is relative ;)
 // And to be correct, I mean proposals upward some quality point.

 .......
>
> On this point, I've long thought the Java platform is like the elephant
> in the parable about the blind men and the elephant:
>
>     http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
>
> That is, while each of us may know and understand our own usage of Java
> quite and well and have valid ideas about how Java could be changed to
> improve programming in our own areas of interest (properties! operator
> overloading! design by contract!  your favorite feature!), evolving the
> platform  with an eye toward optimizing it *as a whole* will  mean at
> least some areas don't get what they want.
>

 Good point. In parable elephants exists and each blinder can touch his
part. In our case, for some blinders, elephant must not exists ;)))

Even if it can be 'build' in such direction, but we choose not to grow
elephant in all directions, because we can't grow quickly.

And also exists many group of blinders, near different points of elephants,
some groups are big but silent, some are small but loud. Elephant designers
are also blinders and guided listening ;)


> [snip]
>
>> Note, that I does not propose use polls as one and only one criteria. I
>> just tell that see result of such poll will be interest.
>>
>> // btw - from other side, all this activity is overkill, I can suggest,
>> // that  accepted proposals would be exactly same, which was listed in
>> // project-coin description (before coin was started)
>> //     http://blogs.sun.com/darcy/entry/project_coin
>> //   +ARM  +jsr292  and ...  it's already 6, which is more than 5 :)
>>
>
> Your own sentence disproves your point since ARM was not listed among
> the five proposal areas under consideration before Project Coin started.
>

I mean not '<cite>would be exactly same, which was listed in project-coin
description (before coin was started)[url]</cite>', but '<cite>would be
exactly same, which was listed in project-coin description (before coin
was started)[url] +ARM  +jsr292</cite>',
 sorry for ambiguity.

 ARM floating around (and widly discussed) from late 2007 or early 2008.
And all we know, that if BGGA will not available, than at least ARM must
be included.  I. e. I can't say that ARM is 'external' and new or not to
be generally known be included in Java 7 before project coin start.

I have no pretension about judgement process, It's only about information
flow: i. e. Sun have all proposals before and <IMHO> call for new
proposals with process of selecting 5 from set of newly received and 5
apriory well-known items, for which we know, that they are necessory, it's
near the same, that throw away all non-apriory proposals.
</IMHO>

I. e. I guess, that when people asked to submit new proposals, they expect
that exists demand for new proposals, not demand for choosing from five
well-known items. When appointment of all new proposals to be thrown away,
with role be backgroung for well-known items, people, which invested some
time in such activity, usually frustrated. It's why I think, that call for
new proposals, whithout real possibility to implement something new (not
well-known before) was an error. If we have slot, for example, in summary
for 10 proposals to implement (5 well know and 5 new) - then all ok, it's
fair game.


>> I. e. doing project coin with external auditory  was a 'Sun system
>> error',
>> I guess; if they want some feedback from community, correct way was at
>> first implement own stuff, than ask community for something new ;)
>>
>
> The call of proposal phase of Project Coin is an effort both to solicit
> feedback from the external community and also to invite the external
> community to participate more directly in evolving the language.  That
> opportunity to participate also implies participating in the large
> amount of work required to go from "I have this great idea!" to "I have
> this great idea and here is a carefully considered review of all the
> implications of the idea, along with a prototype."  The blogs I wrote
> last year and the proposal form itself are part of an effort to explain
> and expose what this language work entails so more people can get
> involved.
>


It would be great, to participate in language evolution in future.
For now I does not see general aviable process for future participation:
call closed, all new proposal throwed away.
Finish. Fire bug reports is useless - they will live in bugzilla for years.

One possible solution: is make 'coin project' regular, for example once a
year. (May be with
entry barrier as 'required implementation in some form')
Another - propose some process (may be long) for author, how to push his
proposal (whith implementation)
into language after JDK7 (or receive official position, that this change
is rejected)


> Unfortunately, many of the submitted proposals did not do a credible job
> of analyzing the true effect the proposal would have, which has a rather
> strong relation to why many were not chosen for further consideration.
> For example, let's take the "'This' type" proposal:
>
 ...


Problem with inaccurate proposals - it's well known problem, the same with
publications, wildly used technique is peer review. (Honesly, overall
quality of proposals was better that I was expected).

Good entry barrier can be requirement to proposal to be implemented in
some form.

P.S. Project coin involved me to think about Java more close than before.
So, despite my criticism, you achieve goal to raise interest to
participate in process of Java language evolution ;)