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 an
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 replac
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
https://bugs.openjdk.java.net/browse/JDK-5082736
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 day,
On Mar 26, 2014, at 4:17 AM, Ulf Zibis 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 the code of void me
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 A
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 agains
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou 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 pot
On 03/27/2014 08:22 PM, Steven Schlansker wrote:
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou 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
Am 27.03.2014 20:22, schrieb Steven Schlansker:
On Mar 27, 2014, at 9:35 AM, Jochen Theodorou 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
On Thu, Mar 27, 2014 at 5:35 PM, Jochen Theodorou 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
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 existi
On Thu, Mar 27, 2014 at 10:02 PM, Jochen Theodorou wrote:
> 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 langua
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 "simpl
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 =
myVeryLongNam
Am 28.03.2014 11:05, schrieb Florian Weimer:
String mySub = myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q"));
You can already write
String mySub = apply(myVeryLongNamedString,
(s) -> s.substring(s.indexOf("C"), s.indexOf("Q")))
with a helper function like this:
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 :
>
> Am 28.03.2014 11:05, schrieb Florian Weimer:
>>>
On Mar 28, 2014, at 10:52 AM, Marek Kozieł 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 lay on interfaces
> 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 replac
--- Original message ---
From: "Marek Kozieł"
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 change every call
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 wo
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 :
> 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 excl
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 r
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
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.
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 wrote:
>
> Am 01.04.2014 11:28, schrieb Bruce Chapman:
>> Slightly preceding Ulf's coin proposal by a few h
On Tue, Apr 1, 2014 at 6:37 PM, Guy Steele 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 the start o
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 proposa
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 wi
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
>>> negativ
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();/* expl
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 we
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" propo
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
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.
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
http://mail.openjdk.j
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 d
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 d
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 =
myVeryLongNamedString.concat("BLAH").substring(.indexOf("C"),.ind
On Fri, Mar 28, 2014 at 5: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:
>
>Strin
40 matches
Mail list logo
