declarative programming

[Reinier Zwitserloot]

Your first sentence suggests you intend this for JDK7. As Patrick explained,
that is off the table. I fail to see the relation between this feature and
lambdas. Can you elaborate on why you believe the introduction of
declarative initialization has any bearing on lambdas?

As Patrick said, if it is _not_ related to lambdas, then the appropriate
venue for this will be coin2 (which will probably be called coin - the flip
side, if you want to set a google alert). Be aware that coin-flip will run
in phases, and projects that do not meet the requirements for each phase are
dropped no matter how good they sound. One of the requirements of one of the
phases will be a working prototype. Thus, if you aren't personally capable
of either writing such a prototype or finding someone to do so, don't count
on coin-flip to help make this idea a reality. Such feature requests with no
intent for research and implementation are better logged at bugs.sun.com, at
the 'request a feature' link.

I'm repeating information given at for example Devoxx 2010 by Brian Goetz,
Mark Reinhold, and Joe Darcy.

 --Reinier Zwitserloot



On Tue, Dec 7, 2010 at 9:55 AM, Tom <tbee at tbee.org> wrote:

> Not sure if this is the place to post this, but one has to start somewhere.
> Since closures will not be part of JDK7 there may be time to hook in one
> more idea, which uses some of the features introduced by closures;
> declarative programming.
>
> Basically what declarative programming is, is initializing objects in a
> readable form. Something like:
>     Class1 {
>         property1 = value1;
>         property2 = Class2 {
>             property3 = value3;
>         }
>     }
>
> This should result in a new instance of class1, that has values for it
> properties, even if they are other classes.
>
> In Java something similar is somewhat possible using an anonymous
> constructor, this is "static { }" without the static keyword. For example:
>
>     new Class1() {{
>         property1 = value1;
>         property2 = new Class2() {{
>             property3 = value3;
>         }};
>     }};
>
> The code above is actual Java code and works, note the {{ }} which create
> an anonymous inner class and within that an anonymous constructor. There are
> a few drawbacks though:
> - The values must either be constants or final variables. Since this is an
> anonymous class, referring outside the class to local variables or
> parameters requires them to be final.
> - The property is actually an instance variable which is being access
> directly.
> - The notation is a tad more verbose, requiring "new" and (){{.
>
> I feel that the verboseness should not be a big issue, it is not that much
> more code. Accessing the property directly is not perfect, but livable. If
> Java ever decides to introduce an actual @property then that will
> immediately solve this point. One could also use setters or a combination,
> but setters reduce readability:
>
>     new Class1() {{
>         setProperty1(value1);
>         setProperty2( new Class2() {{
>             property3 = value3;
>         }});
>     }};
>
> The choice is to the coder. The biggest issue in fact is the final
> requirement. If you try to code like this, the amount of finals you have to
> start spreading through the code is soon going to stop you from continuing.
> I know that closures have the same problem and that it is being addressed,
> but I'm not deep enough in to judge if it is feasible to also use that to
> make this possible.
>
> Any ideas?
>
> Tom
>
>