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

← →
Юрий Зотов © (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/

← →
Kerk © (2014-02-13 14:27) [41]

> jack128_ (13.02.14 14:11) [37]
>
> > Вообще, для возврата из функции нескольких значений в более
> > развитых языках придумали тип tuple.
>
> ИМХО туплы в "более развитых языках" - это спорный момент.
> у туплов нет имен, а это сказывается на читабельности.

Что-то более читаемое, чем туплы сложно придумать :)

int X, int Y; (X,Y) = widget.GetLocation();

← →
Юрий Зотов © (2014-02-13 14:31) [42]

> Kerk © (13.02.14 11:32) [30]

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

Еще как будет. Достаточно лишь передавать клон объекта. Правда, это уже отдельная тема.

← →
Kerk © (2014-02-13 14:35) [43]

> Юрий Зотов © (13.02.14 14:31) [42]

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

Мутабельность - зло, ее должно быть как можно меньше.

← →
Kerk © (2014-02-13 14:37) [44]

К Скале я делал несколько подходов. Мне этот язык кажется несколько over-engineered (как это по-русски?). Слишком дофига всего. Невероятными усилиями разработчикам удалось сделать не элегантный и не компактный язык. То есть избавить Скалу от традиционных качеств функциональных языков :)

← →
Jeer © (2014-02-13 14:39) [45]

Или наделить, в отличие от Джавы, функциональным окрасом:)

← →
Kerk © (2014-02-13 14:43) [46]

> Jeer © (13.02.14 14:39) [45]

Ну, как я вижу, многим нравится. Возможно и правда что-то в нем есть.
В конце концов это единственный более-менее популярный функциональный язык со статической типизацией. Всякие Ruby/Python/Clojure типизируются динамически, а у меня к такому некоторое предубеждение есть.

P.S. Да, я знаю, что все перечисленные языки можно назвать функциональными лишь с натяжкой, но чистая функциональщина в мейнстрим так и не смогла пролезть.

← →
jack128_ (2014-02-13 14:53) [47]

> int X, int Y;
> (X,Y) = widget.GetLocation();

посмотрим на сигнатуру метода GetLocation при использовании туплов.
Tuple<int, int> GetLocation();
как ты узнал, что первым компонентом тупла является x, а вторым y? В моем коде - это очевидно.

← →
Jeer © (2014-02-13 15:21) [48]

На Scala:

def func(x: Int, d: Double): (Int, Double) = (x + 1, d * 7.1)

val (x, d) = func(1, 2)

print(s"x = $x, d = $d")

← →
Kerk © (2014-02-13 15:25) [49]

> jack128_ (13.02.14 14:53) [47]

Понял о чем ты. Да, есть смысл.

Но все же считаю, что tuple - это такой компромисс между простотой и функциональностью. Это элементарный тип, не надо многого от него ждать.

Но его можно легко передать в другую функцию, не заморачиваясь названиями его элементов. А документация и всплывающие подсказки в IDE помогут не ошибиться. Ну и в конце концов, если возвращается не (int,int), а хотя бы (bool, string), то проблема исчезает сама собой.

В любом случае в языках без нормального паттерн-матчинга от туплов толку мало, одна имитация.

← →
jack128_ (2014-02-13 17:20) [50]

> Но все же считаю, что tuple - это такой компромисс между
> простотой и функциональностью.

объясни, чем туплы лучше, чем мой вариант?

← →
Kerk © (2014-02-13 17:56) [51]

> jack128_ (13.02.14 17:20) [50]
> объясни, чем туплы лучше, чем мой вариант?

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

Ну не знаю, короче. Может быть, дело привычки. Что если мне не нужен результат целиком?

int X; (X,_) = widget.GetLocation(); // Более того, это тоже будет работать: (X,_) = widget.GetSomeUnknownTupleThatStartsWithInt();

Что если у меня есть функции, принимающие кортеж с координатами? Это будет работать вообще без проблем. А результаты работы вот этих двух функций не получится так легко использовать единообразно.

public {int X, int Y} GetLocation() public {int Width, int Height} GetSize()

Можно конечно, но не так легко.

Там где поддержка кортежей встроена в язык, их использовать легко и приятно. В языках вроде C# это больше похоже на спуск по пожарной лестнице на инвалидной коляске :)

← →
jack128_ (2014-02-13 18:13) [52]

> А результаты работы вот этих двух функций не получится так
> легко использовать единообразно.
>
> public {int X, int Y} GetLocation()
> public {int Width, int Height} GetSize()

легко получится, если для них тоже реализовать pattern matching.

> Там где поддержка кортежей встроена в язык, их использовать
> легко и приятно. В языках вроде C# это больше похоже на
> спуск по пожарной лестнице на инвалидной коляске :)

их легко использовать только потому что есть PM. Будет PM для таких анонимных типов, будет и их легко использовать

← →
Kerk © (2014-02-13 18:33) [53]

> легко получится, если для них тоже реализовать pattern matching.

И работать с ними как будто это обычный кортеж? Можно конечно, почему нет :)

> а вообще такие вот кренделя с абсолютно базовым функционалом
> - когда для какой-то фички я должен найти другой класс ее
> реализующий - очень напоминает шарп. Там тоже надо не мозгом
> шевелить, а тупо знать 5000 всяких классов и классиков для
> того чтобы собрать то, что я хочу. Не мозг включить на пол
> часа, а документацию почитать пол дня чтобы использовать
> лишь то, что мне предложил производитель. Быдлокодинг какой-
> то...

Нет, быдло кодинг - это когда в класс (например, ArrayList) добавляются методы sort, binarySearch, copy, disjoint, frequency и еще 100500 методов, которые когда-то кому-то могут понадобиться.
И в LinkedList добавляются такие же метoды, и даже в HashSet, и т.д. А если нам нужен logging, пусть каждый класс тоже его изобретает, и еще каждый класс должен иметь метод saveToDatabase и loadFromRestService. Вообще, пусть каждый класс будет маленьким, но вполне законченным приложением :)

Никаких крайностей, это и есть разделение обязанностей и OOП. Если метод Collections.sort сортирует любые Collection (и List, и Set), то в какой класс его вставлять? В AbstractCollection? А если я свою реализацию Set напишу, которая вообще только от Object наследуется? Мне надо будет копировать все методы из ArrayList себе?

> Если метод Collections.sort сортирует любые Collection

забудь про сортировку, я не инвалид и сам смогу отсортировать. Мой вопрос был почему нет метода move()/exch()?

> Достаточно реализовать в ней интерфейс Comparable.

Это если есть Collections класс. Тут предлагалось, чтобы каждая реализация Collection должна была иметь метод для сортировки, а то неудобно другие классы использовать

>
> Мой вопрос был почему нет метода move()/exch()?

Наверное, потому же, почему метод remove является необязательным.
Есть
http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#swap(java.util.List, int, int)
http://docs.oracle.com/javase/6/docs/api/java/util/List.html#subList(int, int)
http://docs.oracle.com/javase/6/docs/api/java/util/List.html#toArray(T[])
Только выбирай.
При сложных операциях все равно обычно работают с массивами, для ускорения.

> Только выбирай.

ну тогда я остаюсь при [21], особенно где жирненьким выделено

добавлю так же, что в наличии insert, хотя и зачем его сделали? оставили бы лишь add()/clear() да и делов-то...

У тебя какая-то другая java, в моей у ArrayList нет insert ;)
Или ты про add c 2 параметрами?
Я думаю, дело в том, что реализация Collections.swap отлично работает с ArrayList, поэтому и не было смысла делать swap в ArrayList.
public class Collections { public static void swap(List<?> list, int i, int j) { final List l = list; l.set(i, l.set(j, l.get(i))); } } public class ArrayList { public E get(int index) { rangeCheck(index); return elementData(index); } E elementData(int index) { return (E) elementData[index]; } private void rangeCheck(int index) { if (index >= size) throw new IndexOutOfBoundsException(outOfBoundsMsg(index)); } public E set(int index, E element) { rangeCheck(index); E oldValue = elementData(index); elementData[index] = element; return oldValue; } }

А насчет [21]

а вообще такие вот кренделя с абсолютно базовым функционалом - когда для какой-то фички я должен найти другой класс ее реализующий - очень напоминает шарп. Там тоже надо не мозгом шевелить, а тупо знать 5000 всяких классов и классиков для того чтобы собрать то, что я хочу. Не мозг включить на пол часа, а документацию почитать пол дня чтобы использовать лишь то, что мне предложил производитель. Быдлокодинг какой-то...

Это называется "изобретать велосипед". Начинающий программист начинает напрягать мозг полчаса и писать свою сортировку, опытный сначала подумает, что наверное он не первый, кому такая задача поставлена и начнет искать в интернете http://lmgtfy.com/?q=java+sort+arraylist (если сразу не знает про Collections2). Хотя у меня и самого такое было много раз, что вроде бы ничего не нашел, приходится самому написать, а потом оказывается, что оно уже кем-то написано, просто искать надо было заковыристо или оно на 15 странице было. Потому что классов гораздо больше, чем 5000 :(

> Или ты про add c 2 параметрами?

да, про нее

> опытный сначала подумает, что наверное он не первый

опытный ее может написать куда быстрее чем пойдет по пути "я хочу готовое": начнет знакомиться с миром 100500 "готовых реализаций", их нюансов и примеров использования, подводными камнями, вкрячиванием в код. Да чтобы оно через два года deprecated не стало. Опять же, мне нужна была простейшая сортировка, и "пузырек" я бы сделал минут за 15 при наличии обычных возможностей типа move. Одним компактным методом у листа. А в случае коллекшенов придется воротить код (CompareTo у item и искать замену своему списку на тот, что имеет sort).

Как раз основное преимущество использования чужого - отсутствие ошибок. Знакомиться с нмиром все равно придется, иначе только велосипеды и будешь изобретать. чтобы deprecated не стало, надо open source использовать, иногда даже делаем усовершенствования для себя.
Я насчет сортировки так и не понял, чем компаратор не подходит?

> А в случае коллекшенов придется воротить код (CompareTo
> у item и искать замену своему списку на тот, что имеет sort).
>

Конкретно мне вот это совсем непонятно. Если ты написал свой список (implements List), то почему бы просто не вызвать Collection.sort(твой_список,...)?

> Если ты написал свой список

я ничего не писал, у меня arraylist, другого не дано

Меня вот это запутало "искать замену своему списку на тот, что имеет sort". Ладно, вроде понятно, что Collections решает все основные проблемы. В javadoc List даже есть ссылки на Collections, правда, про сортировку не упомянуто.

This method eliminates the need for explicit range operations (of the sort that commonly exist for arrays). Any operation that expects a list can be used as a range operation by passing a subList view instead of a whole list. For example, the following idiom removes a range of elements from a list: list.subList(from, to).clear(); Similar idioms may be constructed for indexOf and lastIndexOf, and all of the algorithms in the Collections class can be applied to a subList.

> Компромисс1 © (13.02.14 22:52) [64]
> основное преимущество использования чужого - отсутствие ошибок.

Э, нет, дружище, не скажите. Несколько раз натыкался. Свой велосипед я хотя бы отдебажить могу, а вот чужой - не всегда есть исходники. Даже когда они есть, то их еще и поизучать надо.

Нет, я, конечно, не призываю велосипеды изобретать. Но если мне нужно что-то простое и мелкое, то снова поддержу Антона - гораздо быстрее написать самому, чем рыться в Инете.

> а вот чужой - не всегда есть исходники

В яве так не принято. Либо есть исходники, либо мы не используем.

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

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

> Компромисс1 © (14.02.14 00:40) [69]

> Либо есть исходники, либо мы не используем.

А если деваться некуда? Живой пример - есть шибко специализированный и шибко низкоуровневый пакет, без которого нам не обойтись. Исходников его нет, а есть только джавадок. Вот по нему и действуем.

> пример того, что "быстрее написали сами"?

Например, разные мелкие утилитки, объединенные в один класс в виде статических методов. Скажем, strToDate(), который автоматом распознает несколько форматов даты на входе. Эти 10-15 строк пишутся за столько же минут и настолько просты, что уже после первого теста вероятность невыловленной ошибки становится ничтожной.

Юрий Зотов,
Понятно, спасибо. У нас тоже есть свой strToDate в одном из проектов, точно с таким же функционалом :)

> Как раз основное преимущество использования чужого - отсутствие
> ошибок.

в чужом могут быть ошибки (вот в дельфи 7 в модуле jpeg было обращение к scanline[0] и scanline[1], в результате чего попытка работы с картинкой высотой 1 пиксель была невозможна, модуль от производителя), чужое может быть написано неоптимально (мне сразу не понравилось что для простой операции приходится пересоздавать объекты), чужое нужно изучать и на это тратится время.
а свои велосипеды могут быть уже написаны, отлажены, и понятны

интересно, бывают ли jpeg"и размером 1х1?

привычный content-type, не сжатия ради ведь
хотя чаще gif можно встретить

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