- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
// https://cdn.staticaly.com/gh/landawn/abacus-util/master/docs/MutableBoolean_view.html
// https://github.com/landawn/abacus-util/blob/76cb7c712d4ce2d167f9170f8d92fd9857db8f99/src/main/java/com/landawn/abacus/util/MutableBoolean.java
public final class MutableBoolean implements Mutable, Serializable, Comparable<MutableBoolean> {
/**
* Constructs a new MutableBoolean with the default value of false.
*/
MutableBoolean() {
super();
}
/**
* Constructs a new MutableBoolean with the specified value.
*
* @param value the initial value to store
*/
MutableBoolean(final boolean value) {
super();
this.value = value;
}
/**
*
* @param value
* @return
*/
public static MutableBoolean of(final boolean value) {
return new MutableBoolean(value);
}
/**
*
* @return true, if successful
*/
public boolean value() {
return value;
}
/**
* Sets the value.
*
* @param value the value to set
*/
public void setValue(final boolean value) {
this.value = value;
}
}
Тут человек изменяемый булеан сделал, что думаете? Функциональное программирование уже проиграло ООП?
Follow us!
Тут уже от друзей зависит. Если они за чашкой пива обсуждают ООП и первый канал, то лучше Смешариков посмотреть.
http://govnokod.ru/16233
то вот так же сделать с ref параметром не объявляя его заранее нельзя ни в каком языке, насколько я знаю
В дотнете так действительно нельзя, там только для out подобные вещи разрешены, но это имеет свой смысл, ибо предполагается, что в качестве ref параметра будет передаваться заранее инициализированная переменная.
В плюсах, насколько я помню, нет строгого деления между ref/out, там есть просто передача по константной/неконстантной ссылке, поэтому вполне разумно требовать наличия ранее объявленной переменной, ибо ссылка, в отличие от указателя, сама по себе не может существовать.
Пытаться как-то обойти это ограничение, значит придумывать какой-то специальный сахар для таких параметров, который бы неявно создавал переменную в куче или на стеке и отдавал методу ссылку на неё.
Пффь, подумаешь, проблема
без деклареции в c# уже нельзя
Или это тупо нереально?
Для C# есть библиотека Optional (https://github.com/nlkl/Optional), использую её в ряде проектов как замену возврата null, если нет значения.
UPD:
Нужно иметь возможность выразить его средствами языка.
Тут, на самом деле, есть несколько проблем.
1) Интеграция таких вещей со стандартной библиотекой настоящая боль. Приходится писать много бойлерплейта не ради реальных фич, а просто ради попытки обеспечить консистентность кода.
2) Интерфейс всех этих реализаций отличается между библиотеками существенно, то есть, если тот же linq является стандартом де факто при разработке, и все его более-менее знают, и код с ним не выглядит загадочно, то тот же Optional обладает весьма специфическим интерфейсом, малопонятным даже для человека, который работал с другой реализацией подобной библиотеки, а уж для человека, не знакомого с такими вещами, это вообще будет brainfuck поначалу.
На мой взгляд, это слишком низкоуровневая и завязанная на дизайне языка вещь, чтобы доверять её реализацию сторонним библиотекам.
Я говорю, что такие вещи должны быть выражены существующими средствами языка, а не синтаксическим сахаром или ботвой, зашитой в компилятор.
Тогда, даже если этого нет в стандартной библиотеке, реализации будут возможны и будут проще. Дальше решит "рынок".
Пример: в Свифте Optional это по сути обычный enum с двумя состояниями. Это не спецконструкция языка и это хорошо.
Но при этом нельзя заиметь свой более лучший enum с поддержкой записи типа Int?, потому что это синтаксический сахар для Optional<Int>. И это уже не так круто.
П.С. в Apache commons есть MutableInt и т д
> То ли создать 1кк новых объектов на каждое изменение значения
что?
> гораздо удобнее
есть AtomicReference, который и так позволяет все это делать, и не заботиться даже о параллельных стримах.
если у вас там совсем критично с производительностью и боксинг / cas являются большой проблемой, то эта хуйня вам не потребуется, т.к. вы будете сами писать более подходящие вещи.
Достать, изменить, установить. А с MutableInt со стороны разработчика - просто increment/add и т д.
Если приложение однопоточное, то нет причин использовать StringBuffer вместо StringBuilder. Тут я считаю так же - нет смысла использовать Atomic*** вместо Mutable*** из Apache.
То же самое - HastTable/HashMap, Random/ThreadLocalRandom
Думаю что ему делать нехуй.
Это как StringBuilder и StringBuffer