Форум: "Прочее";
Текущий архив: 2014.09.21;
Скачать: [xml.tar.bz2];
ВнизВозвращать значения переменных в Java Найти похожие ветки
← →
Jimmy (2014-02-12 11:58) [0]Добрый день!
Подскажите аналог описания функции на ПаскалеFunction DoIt(a:byte; var b:integer):boolean
в Java. Проблема в описании переменной b, значения которой не только передаются функции, но и возвращаются.
Заранее спасибо!
← →
MBo © (2014-02-12 12:25) [1]В яве AFAIK нет передачи аргументов по ссылке, только по значению
Нужно что- то модифицировать - возвращать как результат или упаковывать в объект.
← →
Jimmy (2014-02-12 12:30) [2]То есть можно делать как-то так:
MyType=Record I:integer; B:Boolean; end;
Function DoIt(a:byte; b:integer):MyType;
Так?
← →
Jeer © (2014-02-12 13:01) [3]Может все же почитать что-то про Java?
← →
ТНЕ картман (2014-02-12 13:16) [4]
> Function DoIt(a:byte; var b:integer):boolean
boolean DoIt(byte a, int[] b){
b[0] = a + 123;
return true;
}
← →
Jimmy (2014-02-12 13:55) [5]>ТНЕ картман
Разве после командa=1;
в переменной b[0] окажется 124?
b[0]=2;
DoIt(a,b);
← →
ТНЕ картман (2014-02-12 14:27) [6]
> Jimmy (12.02.14 13:55) [5]
>
> >ТНЕ картман
>
> Разве после команд
> a=1;
> b[0]=2;
> DoIt(a,b);
> в переменной b[0] окажется 124?
сложный вопрос...
← →
Юрий Зотов © (2014-02-12 21:46) [7]А все почему? Потому что метод Integer.getIntValue есть, а метода Integer.setIntValue нет. А если бы был, то все было бы очень просто:
public boolean doIt (byte a, Integer b)
А вот почему геттер есть, а сеттера нет - загадка природы.
← →
Компромисс1 © (2014-02-12 23:46) [8]Потому что Integer - immutable object.
Можно b сделать Collection<Integer>, хотя фунции с побочным эффектом не рекомендуются.
List<Integer> list = new ArrayList<Integer>(1);
doIt(..., list);
... list.get(0);
← →
Юрий Зотов © (2014-02-12 23:53) [9]> Компромисс1 © (12.02.14 23:46) [8]
Спасибо, кэп! Осталось только выяснить, почему.
← →
Inovet © (2014-02-12 23:54) [10]Это жаба какая-то. Такие сложности чтобы передать по ссылке.
← →
Юрий Зотов © (2014-02-13 00:09) [11]> Inovet © (12.02.14 23:54) [10]
Это следствие слепого следования кем-то когда-то выказанным личным мнениям, которые почему-то возвели в ранг абсолютных догм. Например:
- goto есть плохо
- всё есть объект
- побочные эффекты есть плохо
- прямая работа с памятью есть плохо
и т.п.
А вот совершенно разумное мнение, что все есть хорошо, будучи правильно использованным нужном месте и в нужное время - вот его почему-то в ранг догмы не возвели. Хотя именно его и следовало бы.
← →
Компромисс1 © (2014-02-13 00:31) [12]Не понимаю, как можно говорить про кэпа, если так и поняли, что сеттер не применим к immutable objects по определению. Если для Вас immutable objects в той же области, что запрет на goto, то у меня просто нет слов ;)
← →
Компромисс1 © (2014-02-13 00:32) [13]так и НЕ поняли
← →
Юрий Зотов © (2014-02-13 01:18) [14]> Компромисс1 © (13.02.14 00:31) [12]
> если так и НЕ поняли, что сеттер не применим к immutable objects
> по определению
Сорри, но эта азбука была понята лет эдак хрен знает когда назад.
Непонятно другое - почему Integer сделан неизменяемым? Почему бы было не ввести в нем сеттеры, а в конструктор - флаг доступности этих сеттеров? Например, что-то вроде этого:
public class MyInteger extends Object {
private boolean isImmutable = true;
private int intValue;
public MyInteger(int intValue) {
super();
this.intValue = intValue;
}
public MyInteger(boolean isImmutable, int intValue) {
MyInteger(intValue);
this.isImmutable = isImmutable;
}
public boolean isImmutable() {
return isImmutable;
}
public int getIntValue() {
return intValue;
}
public void setIntValue(int intValue) throws SomeException {
if (isImmutable)
throw new SomeException("Immutable objet can not be changed");
this.intValue = intValue;
}
}
И все тип-топ: как хочешь, так и юзай, хоть изменяемый, хоть нет.
Вот можете объяснить, почему так не сделали?
← →
Юрий Зотов © (2014-02-13 01:25) [15]> Компромисс1 © (12.02.14 23:46) [8]
>> почему геттер есть, а сеттера нет
> Потому что Integer - immutable object.
Этот Ваш ответ из серии:
- Почему у сороконожки так много ног?
- Потому, что она сороконожка.
Ответ столь же очевидный, сколь и ничего не объясняющий. Поэтому - кэп.
← →
Германн © (2014-02-13 01:53) [16]
> Юрий Зотов © (13.02.14 01:18) [14]
>
> Сорри, но эта азбука была понята лет эдак хрен знает когда
> назад.
Вряд ли более 10 лет назад. :)
> Это следствие слепого следования кем-то когда-то выказанным
> личным мнениям, которые почему-то возвели в ранг абсолютных
> догм. Например:
> - goto есть плохо
> - всё есть объект
> - побочные эффекты есть плохо
> - прямая работа с памятью есть плохо
> и т.п.
>
> А вот совершенно разумное мнение, что все есть хорошо, будучи
> правильно использованным нужном месте и в нужное время -
> вот его почему-то в ранг догмы не возвели. Хотя именно
> его и следовало бы.
Это в церкви есть догмы.
А с нашей ущербной точки зрения ограничения/запреты практически всегда легко можно алгоритмизировать. А вот с разрешениями гораздо сложнее.
← →
antonn © (2014-02-13 08:33) [17]
> Вот можете объяснить, почему так не сделали?
потому что бараны, слепо следующие ООП и каким-то своим выдуманным правилам. имхо
там еще есть arraylist, в котором есть insert, add и remove. но нет exchange, что было бы очень удобно (грубо говоря я хотел сделать свою сортировку). Объяснить, что заменить два указателя быстрее и оптимальнее, чем создавать новый объект, задавать все поля и вызывать все конструкторы, а потом удалять объект из списка и вставлять туда новый, мне не удалось. Сказали что я ничего не понимаю в структурах данных в яве.
← →
Компромисс1 © (2014-02-13 08:35) [18]Боюсь опять оказаться кэпом, но с моей точки зрения, если класс должен себя вести по-разному в зависимости от boolean параметра конструктора, то это должны быть два разных класса (возможно, имеющие общего предка).
Final immutable objects являются наилучшими в плане безопасности, именно поэтому они и были реализованы, на них вся JVM держится. Если кому-то нужны другие классы, похожие на Integer, никто не мешает их реализовывать. Некоторые так и делают, кстати (http://docs.liferay.com/portal/6.0/javadocs/com/liferay/portal/kernel/util/IntegerWrapper.html).
Oracle (как и Sun раньше) просто не стремится (да и не сможет физически) создать все классы, которые могут кому-то понадобиться.
Например, https://code.google.com/p/guava-libraries/wiki/GuavaExplained содержит кучу полезных классов, я был бы не против, чтобы многие из них были в стандарте, но мечтать не вредно ;)
← →
Компромисс1 © (2014-02-13 08:38) [19]там еще есть arraylist, в котором есть insert, add и remove. но нет exchange, что было бы очень удобно (грубо говоря я хотел сделать свою сортировку)
http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#sort(java.util.List)
← →
antonn © (2014-02-13 09:19) [20]речь про arraylist
← →
antonn © (2014-02-13 09:23) [21]а вообще такие вот кренделя с абсолютно базовым функционалом - когда для какой-то фички я должен найти другой класс ее реализующий - очень напоминает шарп. Там тоже надо не мозгом шевелить, а тупо знать 5000 всяких классов и классиков для того чтобы собрать то, что я хочу. Не мозг включить на пол часа, а документацию почитать пол дня чтобы использовать лишь то, что мне предложил производитель. Быдлокодинг какой-то...
← →
Юрий Зотов © (2014-02-13 10:08) [22]> antonn © (13.02.14 08:33) [17]
С сортировкой ArrayList как раз вопросов нет. Например, пишем свой компаратор - и нет проблем. Причем, если мы хотим иметь свою сортировку, то сравнивающий код придется писать в любом случае.
← →
Юрий Зотов © (2014-02-13 10:09) [23]> antonn © (13.02.14 09:23) [21]
+1
← →
Юрий Зотов © (2014-02-13 10:10) [24]> antonn © (13.02.14 09:23) [21]
+1
← →
Юрий Зотов © (2014-02-13 10:23) [25]> Компромисс1 © (13.02.14 08:35) [18]
> Если кому-то нужны другие классы, похожие на Integer, никто
> не мешает их реализовывать.
Само собой. Но здесь я солидарен с Антоном - чтобы сделать абсолютно элементарную и совершенно базовую операцию (да хоть ту же передачу по ссылке), приходится заниматься писаниной и городить аж целый класс.
И всего лишь потому что кто-то когда-то почему-то изрек, что возвращаемые параметры есть плохо.
← →
Kerk © (2014-02-13 11:03) [26]Сейчас в Java нет передачи параметров по ссылке. Вы же тут хотите, чтобы в Java появилась передача параметров по ссылке и при этом исчезла возможность передачи параметров по значению (а именно это произойдет, если все классы сделать мутабельными). Радикалы так вообще хотят кроме этого и статическую типизацию сделать менее строгой (Компилятор, угадай, какой параметр типа integer метод ждет на вход - мутабельный или немутабельный! Не угадал? Ну ничего, в рантайме само упадет, если что).
Это не какая-то мелочь, это изменение семантики всего языка.
И это вместо того, чтобы хотеть аналог дельфового var в параметрах, который добавил бы нужный функционал ничего глобального не ломая.
← →
antonn © (2014-02-13 11:11) [27]
> С сортировкой ArrayList как раз вопросов нет. Например,
> пишем свой компаратор - и нет проблем. Причем, если мы хотим
> иметь свою сортировку, то сравнивающий код придется писать
> в любом случае.
я вообще про изменение, сортировка это лишь повод. ну вот даже просто переместить элемент в списке (потом через baseapadter список выводится в listview) - это надо создать новый, удалить старый и вставить новый.
> Kerk © (13.02.14 11:03) [26]
безотносительно выше сказанному про мутабельность - в дельфи есть var, в шарпе ref/out, ну можно же там по возврату управления получить переменную установленную в методе, почему и в яве не сделать такое? да даже пусть оно будет нативно делать обертку над object, чтобы самому не воротить огромные портянки приведения типов, уже было бы удобно.
← →
Kerk © (2014-02-13 11:26) [28]Не знаю почему аналога var не сделали. Вероятно, это было бы логично и всех бы устроило. Но идея с отказом от иммутабельности очень плохая.
Вообще, для возврата из функции нескольких значений в более развитых языках придумали тип tuple. Это позволяет и несколько значений возвращать, и параметры не трогать. Все-таки в неизменности параметров функции есть некая идейная чистота.
← →
Юрий Зотов © (2014-02-13 11:28) [29]> Kerk © (13.02.14 11:03) [26]
> Вы же тут хотите, чтобы в Java появилась передача параметров
> по ссылке
Допустим, да, хочу. Хотя не особо он и нужно, есть обходные пути, но не хочется писать лишних классов ради элементарных вещей.
> и при этом исчезла возможность передачи параметров по значению
Почему исчезла? Вот этого я как раз не хочу, и нигде этого не говорил.
> (а именно это произойдет, если все классы сделать мутабельными).
Зачем именно все?
> И это вместо того, чтобы хотеть аналог дельфового var в
> параметрах, который добавил бы нужный функционал ничего
> глобального не ломая.
Вот именно этого я и хочу. Вообще, от языка я хочу, чтобы он давал мне широкий набор возможностей - в том числе, регулярные процедуры и функции, определение своих НЕобъектных типов, передачу параметров и по ссылке, и по значению, прямую работу с памятью, прямое управление временем жизни объектов, использование goto и т.п. А я, имея эти возможности, уж как-нибудь сам разберусь, стоит ли их применять, где, как и в каких случаях.
Причем такой язык существует. Угадали, как он называется? Ну да, Delphi.
← →
Kerk © (2014-02-13 11:32) [30]
> Юрий Зотов © (13.02.14 11:28) [29]
>
> > и при этом исчезла возможность передачи параметров по
> значению
>
> Почему исчезла?
Если сделать подобные классы мутабельными, то любая функция сможет изменять значения своих параметров. То есть передачи параметров по значению уже не будет существовать.
> > (а именно это произойдет, если все классы сделать мутабельными).
>
> Зачем именно все?
Хорошо. Только integer, остальные трогать не будем :))
> Вот этого я как раз не хочу, и нигде этого не говорил.
Абсолютно. Ты этого нигде не говорил. Я понимаю чего ты хочешь, но тот путь который ты предложил (сделать подобные классы мутабельными) ломает слишком много всего и тащит за собой последствия, которых ты не хочешь. Ты спросил почему они так не сделали - я ответил.
← →
Kerk © (2014-02-13 12:31) [31]На самом деле, тут есть над чем подумать :)
Возможно (возможно!), невозможность возвращать более, чем одно значение, должна влечь за собой не поиск костылей, а немного другой подход к программированию?
← →
Inovet © (2014-02-13 12:39) [32]> [31] Kerk © (13.02.14 12:31)
Ну так в упаковках возвращать можно, только может быть неудобно и неэффективно. В жабе, случаем, не запрещено?
← →
Kerk © (2014-02-13 12:49) [33]
> Inovet © (13.02.14 12:39) [32]
То что ты назвал "неудобно и неэффективно", я выше назвал поиском костылей. Моя гипотеза заключается в том, что если нечто неудобно делать, то авторы языка предполагали, что так делать не нужно, а делать нужно по-другому?
Ведь известно, что программист на фортране сможет писать на фортране на любом языке :). Так вот хочется понять, отсутствие var-параметров, это недочет или речь идет о другом стиле программирования, где они не нужны?
← →
Ega23 © (2014-02-13 13:23) [34]
> авторы языка предполагали, что так делать не нужно, а делать
> нужно по-другому
КМК, тогда бы авторы языка как минимум дали бы пояснение на этот счёт.
← →
Kerk © (2014-02-13 13:51) [35]Не знаю, я только это нашел:
There is exactly one parameter passing mode -- pass by value -- and that helps keep things simple. -- James Gosling, et al., The Java Programming Language, 4th Edition
Но то, что мы не видели пояснений, не означает, что их нет :)
← →
antonn © (2014-02-13 13:54) [36]
> Возможно (возможно!), невозможность возвращать более, чем
> одно значение, должна влечь за собой не поиск костылей,
> а немного другой подход к программированию?
ну ладно, в шарпе и дельфи я эвентом верну, в метод подвязанный к событию. В яве есть события типа дельфовых и шарповых делегатов? :)
← →
jack128_ (2014-02-13 14:11) [37]
> Вообще, для возврата из функции нескольких значений в более
> развитых языках придумали тип tuple.
ИМХО туплы в "более развитых языках" - это спорный момент. у туплов нет имен, а это сказывается на читабельности. Хороший был бы вариант - это инлайн декларация типа прямо в сигнатуре метода, что типа такого:class Widget
{
public {int X, int Y} GetLocation() { return new {x = 10, y = 20}; }
}
var loc = widget.GetLocation();
Console.WriteLine("X = {0}; Y = {1}", loc.X, loc.Y);
> ну ладно, в шарпе и дельфи я эвентом верну, в метод подвязанный
> к событию. В яве есть события типа дельфовых и шарповых
> делегатов? :)
есть анонимные классы, через которые можно съэмулировать события.
← →
jack128_ (2014-02-13 14:13) [38]
> Причем такой язык существует. Угадали, как он называется?
> Ну да, Delphi.
если тебе нужны неограниченные возможности, то плюсы гораздо больше подойдут.
← →
Jeer © (2014-02-13 14:18) [39]Собственно, подоплека лежит в ненарушении принципов SRP ( Single responsibility principle ).
На пальцах: http://www.objectmentor.com/resources/articles/srp.pdf
Ну и:
http://en.wikipedia.org/wiki/Single_responsibility_principle
← →
Jeer © (2014-02-13 14:24) [40]P.S.
Если хочется чего-то поновее - переходите на Scala, предполагаемый преемник Java:)
http://habrahabr.ru/post/99347/
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2014.09.21;
Скачать: [xml.tar.bz2];
Память: 0.56 MB
Время: 0.004 c