Re: Implicit 'this' return for void methods

; together must be processed together; that which belongs apart must be >> processed apart. > > Point taken, but Project Coin (small language changes) worked well. > > Andrew. > -- Pozdrawiam Marek Kozieł ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/

Re: Implicit 'this' return for void methods

java.lang.Void methid(); or maybe noted as: null method(); So hopefully this would fit language peaty well. Any way it's to early for me to comprehend influence of such big change. I do not like such know-how solutions. -- Pozdrawiam Marek Kozieł ( Lasu ) http://na-

Re: Implicit 'this' return for void methods

anches and uncommitted code. 2014-03-29 18:42 GMT+01:00 Victor Polischuk : > --- 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

Re: Implicit 'this' return for void methods

p weaker ones/ Don't get me wrong i like chains but not if language readability would suffer, that why i suggested return 'this' : http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000523.html But this change is not so easy to introduce. -- Pozdrawiam Marek Ko

Re: Implicit 'this' return for void methods

(1) > read it and (2) understand it's sense. > > BTW, our 2nd example wouldn't work as expression in for loop arguments. > > But what for do we discuss the "leading dot expressions" such exhaustive, if > there still is no conviction to add the simple "chaining syntax" to the Java > language at all? > > -Ulf > -- Pozdrawiam Marek Kozieł ( Lasu ) http://na-chlodno.blogspot.com/ http://lasu2string.blogspot.com/

Re: Disambiguating empty catch blocks

way of thinking as interesting: http://lasu2string.blogspot.com/2010/02/forwarding-as-language.html but I doubt that any will be don about it. ^___^ -- Pozdrowionka. / Regards. Lasu aka Marek Kozieł > - The catch block is incomplete - a bug. > > > > To enable programmers to disamb

Re: Tune String's hashCode() + equals()

2010/3/4 Ulf Zibis : >> 5. >> Intern string do not need hash codes co comparing cos they have same >> address, so first loop would return true if they are equal, after this >> we need only to check if they are not equal: >> >>> >>> if (isIntern()&&  anotherString.isIntern()) return false; >>> > >

Re: Tune String's hashCode() + equals() [was: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)]

because memory lost this way may have great impact on average application efficiency. -- Pozdrowionka. / Regards. Lasu aka Marek Kozieł http://lasu2string.blogspot.com/

Re: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)

if (v1[i++] != v2[j++]) return false; } return true; } } return false; } This solution would powdered .intern() so once someone would optimise application and use interns it would improve speed and memory usage, also it do not have negati

Re: The new Objects class

ell me what target you want to obtain? Because I do not see any reason for that. -- Pozdrowionka. / Regards. Lasu aka Marek Kozieł http://lasu2string.blogspot.com/

Re: The new Objects class

ation for low number of arguments: public static int hash(Object value) public static int hash(Object value, Object value1) public static int hash(Object value, Object value1, Object value3) public static int hash(Object... values) public static int hash() // maybe ? But I'm not sure if we need that, probably time will tell... -- Pozdrowionka. / Regards. Lasu aka Marek Kozieł

Re: Gap Buffer based AbstractStringBuilder implementation

2009/11/17 Goktug Gokdogan : > Hi. > As you know, java.lang.String classes favor insertion to the end in > terms of performance. Adding to beginning or middle of these sequences > causes most of the array to be shifted toward the end every time. Every ones > in a while I end up changing my algo

Re: What methods should go into a java.util.Objects class in JDK 7?

emind everyone of Fan - http://fandev.org - > where all variable references are non-null by default, something which > we should all support. > > Stephen > I agree with Stephen. In real word you have to deal with "pathologies" which are made by others. When you deal wit

Re: First round of java.util.Objects for code review (bug 6797535)

ortant now what is the reason) he will be able to do it without re-implementing this part of code. So with suggested implementation we do not lose anything because specification of equals(Object o) is still valid, it just allow to extend it with null support which is main reason why it should

Re: First round of java.util.Objects for code review (bug 6797535)

s one could cover case when null is considered as object in object equals method, while in not time implementation result might depend from arguments order: class Boo { public String data; @Override public boolean equals(Object obj) { if (obj == null) return (data == null);// ... } } -- Regards. Lasu aka Marek Kozieł http://lasu2string.blogspot.com/