Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
// 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;
}
}
Тут человек изменяемый булеан сделал, что думаете? Функциональное программирование уже проиграло ООП?
Что такого плохого в Смешариках? У них там упоминаются разные полезные факты из физики и экономики, а у самих героев можно учиться социальному взаимодействию (что полезно для программиста).
Тут уже от друзей зависит. Если они за чашкой пива обсуждают ООП и первый канал, то лучше Смешариков посмотреть.
А зачем это реально нужно кроме сомнительных конструкций? В с# знаю что есть всякие методы вроде Try... которые возвращают флаг успешности и принимают out параметры но мне всегда казалось это какой-то хуйней которая пришла из с
У меня есть ровно одна проблема с этим - в некоторых си подобных языках можно объявить переменную прямо в условии ифа, но при этом нельзя выделить память и оставить референс себе в вызове функции. То есть в условном с++ можно написать(я его не знаю, не бейте)
В дотнете так действительно нельзя, там только для out подобные вещи разрешены, но это имеет свой смысл, ибо предполагается, что в качестве ref параметра будет передаваться заранее инициализированная переменная.
В плюсах, насколько я помню, нет строгого деления между ref/out, там есть просто передача по константной/неконстантной ссылке, поэтому вполне разумно требовать наличия ранее объявленной переменной, ибо ссылка, в отличие от указателя, сама по себе не может существовать.
Пытаться как-то обойти это ограничение, значит придумывать какой-то специальный сахар для таких параметров, который бы неявно создавал переменную в куче или на стеке и отдавал методу ссылку на неё.
Не знаю, очень не хватает, конечно. С другой стороны, даже если добавят, вряд ли кто-то будет потом перелопачивать всю BCL, чтобы заменить методы вроде FirstOrDefault(), чтобы вместо null возвращался Option/Result/Maybe.
Я соглашусь с предыдущим комментатором.
Тут, на самом деле, есть несколько проблем.
1) Интеграция таких вещей со стандартной библиотекой настоящая боль. Приходится писать много бойлерплейта не ради реальных фич, а просто ради попытки обеспечить консистентность кода.
2) Интерфейс всех этих реализаций отличается между библиотеками существенно, то есть, если тот же linq является стандартом де факто при разработке, и все его более-менее знают, и код с ним не выглядит загадочно, то тот же Optional обладает весьма специфическим интерфейсом, малопонятным даже для человека, который работал с другой реализацией подобной библиотеки, а уж для человека, не знакомого с такими вещами, это вообще будет brainfuck поначалу.
На мой взгляд, это слишком низкоуровневая и завязанная на дизайне языка вещь, чтобы доверять её реализацию сторонним библиотекам.
А я и не говорю, что его не должно быть в стандартной библиотеке.
Я говорю, что такие вещи должны быть выражены существующими средствами языка, а не синтаксическим сахаром или ботвой, зашитой в компилятор.
Тогда, даже если этого нет в стандартной библиотеке, реализации будут возможны и будут проще. Дальше решит "рынок".
Пример: в Свифте Optional это по сути обычный enum с двумя состояниями. Это не спецконструкция языка и это хорошо.
Но при этом нельзя заиметь свой более лучший enum с поддержкой записи типа Int?, потому что это синтаксический сахар для Optional<Int>. И это уже не так круто.
В некоторых случаях это может быть полезно. Стандартные обертки то иммутабельны, и если нужно менять значение, скажем, int, которое лежит в виде объекта(в коллекции, например), то использовать мутабельную обертку гораздо удобнее и производительнее. То ли создать 1кк новых объектов на каждое изменение значения, то ли просто увеличить int поле у одного объекта.
> производительнее
> То ли создать 1кк новых объектов на каждое изменение значения
что?
> гораздо удобнее
есть AtomicReference, который и так позволяет все это делать, и не заботиться даже о параллельных стримах.
если у вас там совсем критично с производительностью и боксинг / cas являются большой проблемой, то эта хуйня вам не потребуется, т.к. вы будете сами писать более подходящие вещи.
Если у тебя объект немутабельный, то единственный способ изменить его -- это создать новый объект.
Просто товарищ не знает, что в джаве True это (слава яхве) -- синглтон
На зачем atomicReference когда можно просто MutableBoolean/Int и т д? Так же будет даже удобнее изменять значение. С AtomRef будет странная череда де1ствий
Достать, изменить, установить. А с MutableInt со стороны разработчика - просто increment/add и т д.
Если приложение однопоточное, то нет причин использовать StringBuffer вместо StringBuilder. Тут я считаю так же - нет смысла использовать Atomic*** вместо Mutable*** из Apache.
То же самое - HastTable/HashMap, Random/ThreadLocalRandom
Но у AtomicBoolean похоже, но все же другое предназначение. В первую очередь оно спроектировано для многопоточной среды. Для однопоточной есть реализации в apache commons.
Это как StringBuilder и StringBuffer
Я хочу пить пиво и пиздеть с друзьями, а мне аниматор говорит: "да тебе со взрослыми будет скучно, давай лучше смешариков смотреть"
Сука блядь, в джаве ничего нельзя, чтобы программист-дебил случайно себе в ногу не поранил
С джаве надо выдавать слюнявчик, блядь, и тихий час делать
Тут уже от друзей зависит. Если они за чашкой пива обсуждают ООП и первый канал, то лучше Смешариков посмотреть.
http://govnokod.ru/16233
Так что ни Scala, ни Kotlin тут не помогут.
Хотя разумеется они в миллион раз лучше Джавы
то вот так же сделать с ref параметром не объявляя его заранее нельзя ни в каком языке, насколько я знаю
В дотнете так действительно нельзя, там только для out подобные вещи разрешены, но это имеет свой смысл, ибо предполагается, что в качестве ref параметра будет передаваться заранее инициализированная переменная.
В плюсах, насколько я помню, нет строгого деления между ref/out, там есть просто передача по константной/неконстантной ссылке, поэтому вполне разумно требовать наличия ранее объявленной переменной, ибо ссылка, в отличие от указателя, сама по себе не может существовать.
Пытаться как-то обойти это ограничение, значит придумывать какой-то специальный сахар для таких параметров, который бы неявно создавал переменную в куче или на стеке и отдавал методу ссылку на неё.
по типу аргумента функции, глупый вопрос задал, сори
Видите, как удобно? Джависты даже не подозревают, как их язык убог
Пффь, подумаешь, проблема
Там дефикации не нужно
то-есть дефиниции
без деклареции в c# уже нельзя
Или это тупо нереально?
Для C# есть библиотека Optional (https://github.com/nlkl/Optional), использую её в ряде проектов как замену возврата null, если нет значения.
UPD:
Эх
Нужно иметь возможность выразить его средствами языка.
Либо будет 978 не совместимых друг с другом реализаций.
Наример в котлине можно его сделать , но в библиотеке егонет
В С++ тоже можно написать string, но хорошо же, что он есть
Тут, на самом деле, есть несколько проблем.
1) Интеграция таких вещей со стандартной библиотекой настоящая боль. Приходится писать много бойлерплейта не ради реальных фич, а просто ради попытки обеспечить консистентность кода.
2) Интерфейс всех этих реализаций отличается между библиотеками существенно, то есть, если тот же linq является стандартом де факто при разработке, и все его более-менее знают, и код с ним не выглядит загадочно, то тот же Optional обладает весьма специфическим интерфейсом, малопонятным даже для человека, который работал с другой реализацией подобной библиотеки, а уж для человека, не знакомого с такими вещами, это вообще будет brainfuck поначалу.
На мой взгляд, это слишком низкоуровневая и завязанная на дизайне языка вещь, чтобы доверять её реализацию сторонним библиотекам.
Я говорю, что такие вещи должны быть выражены существующими средствами языка, а не синтаксическим сахаром или ботвой, зашитой в компилятор.
Тогда, даже если этого нет в стандартной библиотеке, реализации будут возможны и будут проще. Дальше решит "рынок".
Пример: в Свифте Optional это по сути обычный enum с двумя состояниями. Это не спецконструкция языка и это хорошо.
Но при этом нельзя заиметь свой более лучший enum с поддержкой записи типа Int?, потому что это синтаксический сахар для Optional<Int>. И это уже не так круто.
П.С. в Apache commons есть MutableInt и т д
> То ли создать 1кк новых объектов на каждое изменение значения
что?
> гораздо удобнее
есть AtomicReference, который и так позволяет все это делать, и не заботиться даже о параллельных стримах.
если у вас там совсем критично с производительностью и боксинг / cas являются большой проблемой, то эта хуйня вам не потребуется, т.к. вы будете сами писать более подходящие вещи.
Если у тебя объект немутабельный, то единственный способ изменить его -- это создать новый объект.
Просто товарищ не знает, что в джаве True это (слава яхве) -- синглтон
Достать, изменить, установить. А с MutableInt со стороны разработчика - просто increment/add и т д.
Если приложение однопоточное, то нет причин использовать StringBuffer вместо StringBuilder. Тут я считаю так же - нет смысла использовать Atomic*** вместо Mutable*** из Apache.
То же самое - HastTable/HashMap, Random/ThreadLocalRandom
Думаю что ему делать нехуй.
Это как StringBuilder и StringBuffer