On 3/04/2014 6:01 p.m., Peter Levart wrote:
On 04/01/2014 11:28 AM, Bruce Chapman wrote:
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked dot notation (coined in
On 04/03/2014 09:54 AM, Bruce Chapman wrote:
On 3/04/2014 6:01 p.m., Peter Levart wrote:
On 04/01/2014 11:28 AM, Bruce Chapman wrote:
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked
On 04/03/2014 09:54 AM, Bruce Chapman wrote:
On 3/04/2014 6:01 p.m., Peter Levart wrote:
On 04/01/2014 11:28 AM, Bruce Chapman wrote:
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked
On 04/01/2014 10:20 PM, Eirik Lygre wrote:
What is the relationship between this naked dot proposal and the
chaining of void methods proposal? The reason for asking is not to be
negative, but rather to find out if these issues are best dealt with
together, or as independent proposals.
I
Hi,
Am 02.04.2014 11:08, schrieb Andrew Haley:
On 04/01/2014 10:20 PM, Eirik Lygre wrote:
What is the relationship between this naked dot proposal and the
chaining of void methods proposal? The reason for asking is not to be
negative, but rather to find out if these issues are best dealt with
On 04/02/2014 11:58 AM, Ulf Zibis wrote:
Hi,
Am 02.04.2014 11:08, schrieb Andrew Haley:
On 04/01/2014 10:20 PM, Eirik Lygre wrote:
What is the relationship between this naked dot proposal and the
chaining of void methods proposal? The reason for asking is not to be
negative, but rather to
In my opinion Project Coin was meant only to push some earlier chosen
changes into language.
Naked dot in language where long name are preferred is pure evil:
I would have to look pairing ; for every dot ?
someVeryLongName()/* explanation*/.otherLongNameMethod();
someVeryLongName();/*
Hi,
Just adding some perspective after following these language-feature
discussions for several years now.
In my opinion Project Coin was meant only to push some earlier chosen
changes into language.
The initial Project Coin process actually invited proposals from the
community. There were
On 04/02/2014 12:05 PM, Andrew Haley wrote:
On 04/02/2014 11:58 AM, Ulf Zibis wrote:
Hi,
Am 02.04.2014 11:08, schrieb Andrew Haley:
On 04/01/2014 10:20 PM, Eirik Lygre wrote:
What is the relationship between this naked dot proposal and the
chaining of void methods proposal? The reason for
On 04/01/2014 11:28 AM, Bruce Chapman wrote:
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked dot notation (coined in
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked dot notation (coined in
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.html)
has better value as .. a
syntax for
Am 01.04.2014 11:28, schrieb Bruce Chapman:
Slightly preceding Ulf's coin proposal by a few hours was
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html
Where I suggested the naked dot notation (coined in
Then it sounds as if the three of us, at least, are very much in agreement
about what is the appropriate scope for such a “naked dot” feature.
—Guy
On Apr 1, 2014, at 7:26 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 01.04.2014 11:28, schrieb Bruce Chapman:
Slightly preceding Ulf's coin
On Tue, Apr 1, 2014 at 6:37 PM, Guy Steele guy.ste...@oracle.com wrote:
Then it sounds as if the three of us, at least, are very much in agreement
about what is the appropriate scope for such a naked dot feature.
Am 01.04.2014 11:28, schrieb Bruce Chapman:
More formally, the naked dot (at
Sorry for late answer,
After some thought I came into conclusion, that both solutions are similar.
For me void functionality it to great to be in 100% replaced, other
reasons are not as important.
So if we consider that void would be replaced with 'this' or keep as
void, in additional some type
What about opting in? By that, I mean that these void methods must have a
specific TYPE_USE annotation on them at compile time to allow chaining.
This idea would require a JLS update to allow type annotations on void
return values -- perhaps exclusive to this annotation.
On Mon, Mar 31, 2014 at
2014-03-31 22:44 GMT+02:00 Paul Benedict pbened...@apache.org:
What about opting in? By that, I mean that these void methods must have a
specific TYPE_USE annotation on them at compile time to allow chaining.
This idea would require a JLS update to allow type annotations on void
return values
The number of cases that this dramatically increases readability are well
described. A single concrete counterexample would help.
I Use Builders which are created especially to be called in chain
mode, so even after a while code is 100% readable. But when we assume
that void could be replaced
--- Original message ---
From: Marek Kozieł develop4l...@gmail.com
Date: 29 March 2014, 18:02:06
Main problem is fact that in long chain you cannot be sure if type
changed and on which object you executing method. Now chain
constructions are so rare that you remember them all.
After such
On Fri, Mar 28, 2014 at 5:57 AM, Victor Polischuk vict...@ukr.net wrote:
Ulf,
I think that point leading style is something which can be easily
mistreat. If we complicate the example:
String mySub =
myVeryLongNamedString.substring(.indexOf(C),.indexOf(Q));
to something like:
On 03/28/2014 05:57 AM, Victor Polischuk wrote:
Ulf,
I think that point leading style is something which can be easily mistreat. If
we complicate the example:
String mySub = myVeryLongNamedString.substring(.indexOf(C),.indexOf(Q));
to something like:
String mySub =
Hi,
I really do not know why some proposals are restored back from the
grave, without answering for questions that was already made:
http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000382.html
2014-03-28 12:37 GMT+01:00 Ulf Zibis ulf.zi...@cosoco.de:
Am 28.03.2014 11:05, schrieb
On Mar 28, 2014, at 10:52 AM, Marek Kozieł develop4l...@gmail.com wrote:
Hi,
I really do not know why some proposals are restored back from the
grave, without answering for questions that was already made:
http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000382.html
Problem
Hi Guy and Paul,
thanks for liking my proposal.
What can we do to convince the officials ?
-Ulf
Am 26.03.2014 17:20, schrieb Paul Benedict:
It would be nice to make this language change. In the past years, it's pretty clear many JSR EE
spec leads have gone on to make their APIs return the
Am 26.03.2014 16:51, schrieb Guy Steele:
[...]
I am wholeheartedly in favor of allowing “chaining” of dotted expressions such
as
CharBuffer.allocate(26).position(2).put(C).position(25).put(Z”)
this also shows a potential point of critic this proposal will have to
find arguments against.
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou blackd...@gmx.org wrote:
Am 26.03.2014 16:51, schrieb Guy Steele:
[...]
I am wholeheartedly in favor of allowing “chaining” of dotted expressions
such as
CharBuffer.allocate(26).position(2).put(C).position(25).put(Z”)
this also shows a
On 03/27/2014 08:22 PM, Steven Schlansker wrote:
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou blackd...@gmx.org wrote:
Am 26.03.2014 16:51, schrieb Guy Steele:
[...]
I am wholeheartedly in favor of allowing “chaining” of dotted expressions such
as
Am 27.03.2014 20:22, schrieb Steven Schlansker:
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou blackd...@gmx.org wrote:
Am 26.03.2014 16:51, schrieb Guy Steele:
[...]
I am wholeheartedly in favor of allowing “chaining” of dotted expressions such
as
Am 27.03.2014 21:52, schrieb Eirik Lygre:
[...]
The JavaBean specification, with it's void setSomething() functions
are fundamental to so many things Java that they will never go away
(good thing, too!).The suggested language change builds on top of that,
is beneficial to a large body of
On Thu, Mar 27, 2014 at 10:02 PM, Jochen Theodorou blackd...@gmx.orgwrote:
Am 27.03.2014 21:52, schrieb Eirik Lygre:
[...]
The JavaBean specification, with it's void setSomething() functions
are fundamental to so many things Java that they will never go away
(good thing, too!).The
Am 27.03.2014 23:05, schrieb Eirik Lygre:
With this suggested change, the only behavior that will change is that some code which used to not
compile will start compiling, with a reasonable result. No code that used to compile will change.
Yes, this is one of the great advantages of this
Ulf,
I think that point leading style is something which can be easily mistreat. If
we complicate the example:
String mySub = myVeryLongNamedString.substring(.indexOf(C),.indexOf(Q));
to something like:
String mySub =
See:
https://bugs.openjdk.java.net/browse/JDK-6472931
https://bugs.openjdk.java.net/browse/JDK-6373386
https://bugs.openjdk.java.net/browse/JDK-6479372
https://bugs.openjdk.java.net/browse/JDK-4774077
https://bugs.openjdk.java.net/browse/JDK-6451131
See also:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001512.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001365.html
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html
-Ulf
Am 25.03.2014 21:19, schrieb Victor Polischuk:
Good
On Mar 26, 2014, at 4:17 AM, Ulf Zibis ulf.zi...@cosoco.de wrote:
See also:
. . .
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html
This last one has a specific proposal, which is simple and quite nice. The
important idea is
that we don’t actually make any change to
It would be nice to make this language change. In the past years, it's
pretty clear many JSR EE spec leads have gone on to make their APIs return
the same object because they strongly prefer to see object chaining in
code. I sympathize with those designers, but I don't agree; I wouldn't
affect my
Good day, everyone,
I have a question regarding a proposal I found some time ago:
http://tech.puredanger.com/java7#chained.
In a word, it is all about replacing 'void' behavior to always return 'this'
and I think for static methods it would be nice to return Class instance. I
have not found
On 26/03/2014 6:19 AM, Victor Polischuk wrote:
Good day, everyone,
I have a question regarding a proposal I found some time ago:
http://tech.puredanger.com/java7#chained.
More direct original link:
http://www.mernst.org/blog/rss.xml#AModestLanguageProposal
In a word, it is all about
38 matches
Mail list logo
