Возвращать значения переменных в 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]=2; DoIt(a,b);в переменной b[0] окажется 124?

← →
ТНЕ картман (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. Это позволяет и несколько значений возвращать, и параметры не трогать. Все-таки в неизменности параметров функции есть некая идейная чистота.

> Kerk © (13.02.14 11:03) [26]

> Вы же тут хотите, чтобы в Java появилась передача параметров
> по ссылке

Допустим, да, хочу. Хотя не особо он и нужно, есть обходные пути, но не хочется писать лишних классов ради элементарных вещей.

> и при этом исчезла возможность передачи параметров по значению

Почему исчезла? Вот этого я как раз не хочу, и нигде этого не говорил.

> (а именно это произойдет, если все классы сделать мутабельными).

Зачем именно все?

> И это вместо того, чтобы хотеть аналог дельфового var в
> параметрах, который добавил бы нужный функционал ничего
> глобального не ломая.

Вот именно этого я и хочу. Вообще, от языка я хочу, чтобы он давал мне широкий набор возможностей - в том числе, регулярные процедуры и функции, определение своих НЕобъектных типов, передачу параметров и по ссылке, и по значению, прямую работу с памятью, прямое управление временем жизни объектов, использование goto и т.п. А я, имея эти возможности, уж как-нибудь сам разберусь, стоит ли их применять, где, как и в каких случаях.

Причем такой язык существует. Угадали, как он называется? Ну да, Delphi.

> Юрий Зотов © (13.02.14 11:28) [29]
>
> > и при этом исчезла возможность передачи параметров по
> значению
>
> Почему исчезла?

Если сделать подобные классы мутабельными, то любая функция сможет изменять значения своих параметров. То есть передачи параметров по значению уже не будет существовать.

> > (а именно это произойдет, если все классы сделать мутабельными).
>
> Зачем именно все?

Хорошо. Только integer, остальные трогать не будем :))

> Вот этого я как раз не хочу, и нигде этого не говорил.

Абсолютно. Ты этого нигде не говорил. Я понимаю чего ты хочешь, но тот путь который ты предложил (сделать подобные классы мутабельными) ломает слишком много всего и тащит за собой последствия, которых ты не хочешь. Ты спросил почему они так не сделали - я ответил.

На самом деле, тут есть над чем подумать :)
Возможно (возможно!), невозможность возвращать более, чем одно значение, должна влечь за собой не поиск костылей, а немного другой подход к программированию?

> [31] Kerk © (13.02.14 12:31)

Ну так в упаковках возвращать можно, только может быть неудобно и неэффективно. В жабе, случаем, не запрещено?

> Inovet © (13.02.14 12:39) [32]

То что ты назвал "неудобно и неэффективно", я выше назвал поиском костылей. Моя гипотеза заключается в том, что если нечто неудобно делать, то авторы языка предполагали, что так делать не нужно, а делать нужно по-другому?

Ведь известно, что программист на фортране сможет писать на фортране на любом языке :). Так вот хочется понять, отсутствие var-параметров, это недочет или речь идет о другом стиле программирования, где они не нужны?

> авторы языка предполагали, что так делать не нужно, а делать
> нужно по-другому

КМК, тогда бы авторы языка как минимум дали бы пояснение на этот счёт.

Не знаю, я только это нашел:

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

Но то, что мы не видели пояснений, не означает, что их нет :)

> Возможно (возможно!), невозможность возвращать более, чем
> одно значение, должна влечь за собой не поиск костылей,
> а немного другой подход к программированию?

ну ладно, в шарпе и дельфи я эвентом верну, в метод подвязанный к событию. В яве есть события типа дельфовых и шарповых делегатов? :)

← →
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.

если тебе нужны неограниченные возможности, то плюсы гораздо больше подойдут.

Собственно, подоплека лежит в ненарушении принципов SRP ( Single responsibility principle ).

На пальцах: http://www.objectmentor.com/resources/articles/srp.pdf

Ну и:
http://en.wikipedia.org/wiki/Single_responsibility_principle

P.S.
Если хочется чего-то поновее - переходите на Scala, предполагаемый преемник Java:)

http://habrahabr.ru/post/99347/

Возвращать значения переменных в Java Найти похожие ветки