- 1
- 2
- $pending = $this->$tag['callback']($open['data'], $open['option']);
+ $pending = $this->{$tag['callback']}($open['data'], $open['option']);
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−1
- $pending = $this->$tag['callback']($open['data'], $open['option']);
+ $pending = $this->{$tag['callback']}($open['data'], $open['option']);
Копаюсь в сорцах говнокода.
В PHP 7 поменяли приоритет, пол часа не мог понять что за хуйня.
SemaReal 08.03.2018 00:10 # +2
Ку вот зачем тут стрелочка? this может быть не указателем? Точечка вообще существует?
Зачем тут ДВА доллара: $this->$tag ?
Почему все юзают дикты? Потому что нет лёгкого способа описать объект как в JS (где хеш есть объект) или как OpenStruct в Ruby?
Тогда почему не разрешить нормальный синтаксис через точку?
Семантический мусор же.
inho 08.03.2018 00:13 # 0
/fixed
SemaReal 08.03.2018 00:14 # 0
inho 08.03.2018 00:25 # +1
PHP7 -> JS:
PHP5 -> JS:
(ЕМНИП)
SemaReal 08.03.2018 00:29 # +1
1024-- 08.03.2018 13:07 # 0
А потом пердолить этим людей не хуже, чем сишным int *a[10] vs int (*p)[].
SemaReal 08.03.2018 01:22 # 0
Я считаю что разделять структуры/записи (ну классы без методов) и дикты (они же мэпы они же хеши они же ассоциативные массивы) в ЯПах без обязательной стат типизации смысла нет, то-есть в JS сделано правильно.
Вот нуб пришел на работу и не знает как передать 20 параметров: ассоциативным массивом или классом?
Старый жабист говорит: "коненчно классом, так ты не опечатаешься и в рантайме узнаешь если ошибся".
Старый, не знаю, перловик говорит: "конечно хешем, не выябывайся".
В результате получается и так и сяк.
Q: что лучше: $petushok['age'] или $petushok->age?
A: ахуйегознает
3.14159265 08.03.2018 03:20 # +1
>в рантайме узнаешь если ошибся
Не-не-не, жабисты так точно не говорят.Только те что на спринг expression-language пишут.
> то-есть в JS сделано правильно
Вот. Но не совсем.
1024-- как-то говорил что еще кошернее и в духе доброго похуистичного js, было бы сделать чтоб цепочки свойств не падали.
user['pituh']['age'] //undefined, если питуха нет
SemaReal 08.03.2018 03:49 # 0
в ObjC (и думаю что в swift) вызов метода у nil (посылка месседжа nil) всегда приводит к возвращению nil, так что можно делать длиные цепочки первый вызов из которых вернет nil, и все будет ок
В котлине тоже так можно.
Жаба:
Petuh p = user.getPetuh();
if (p != null) {
Kurochka k = p.kurochka;
if (k != null){..}
}
котлин
val k = user?.petuh?.kurochka
roman-kashitsyn 08.03.2018 12:46 # +1
Desktop 08.03.2018 17:20 # 0
CHayT 11.03.2018 16:18 # +2
SemaReal 11.03.2018 16:35 # 0
3.14159265 09.03.2018 04:13 # 0
С одной стороны достаточно полезно было бы иметь, с другой в мерзком ECMA-2015 можно запилить
Думаю и в js можно через proxy добиться такого поведения.
Fike 08.03.2018 06:08 # 0
ты походу не дебажил случаи, когда у тебя один из этих параметров в конце длинной цепочки преобразований почему-то undefined, а посередине сплошное жонглирование с Object.keys и прочим весельем
bormand 08.03.2018 07:14 # 0
Так что я тут согласен с SemaReal.
roman-kashitsyn 08.03.2018 11:27 # 0
A: (:age petushok)
1024-- 08.03.2018 13:17 # 0
В JS сделано отчасти хорошо (читай: плохо).
Хорошо сделано в Lua, где есть метатаблицы, из-за которых можно отличить, где у тебя в ассоциативном массиве лежит ключ (данные), а где - его поле или метод.
Иначе общение с ассоциативным массивом превращается в пердолинг. Если кто-то добавил в Object.prototype что-то полезное (те же полифиллы), in для всех ассоциотивных питухов уже будет срабатывать на это полезное. На hasOwnProperty рассчитывать нельзя, т.к. его могли добавить как ключ. Брать hasOwnProperty надо из другого, чистого объекта. И прочая питушня. В старых версиях языка наверно легче было к каждому ключу добавлять префикс, с которого с большой вероятностью не будут начинаться поля и методы. Сейчас в JS встроили специально написанные мапы, но их просто так не задашь литералом.
syoma 08.03.2018 14:42 # 0
1024-- 08.03.2018 15:22 # 0
Тут и без __ __ всё работает. В JS бы в аналогичном примере была ошибка вызова числа как функции.
syoma 08.03.2018 16:40 # 0
Не понял
1024-- 08.03.2018 16:44 # 0
syoma 08.03.2018 17:10 # 0
В питоне тоже случается как за нехуй.
Вылетит при вызове obj.login() догадайся почему
1024-- 08.03.2018 17:22 # 0
В моём примере данные переписали метаданные. В нормальном коде такое возможно, если в пользовательском вводе встретилась подходящая питушня.
syoma 08.03.2018 17:35 # 0
1024-- 08.03.2018 17:45 # +1
Запрещать присваивать что-то в динамическом массиве - тоже не вариант, пользователь имеет полное право вставить __питушню__, невставка __питушни__ будет эквивалентна вставке питушни, перетирающей поля и методы: проверять всё равно придётся.
А вот подход Lua - наверно то, что нужно.
syoma 08.03.2018 18:00 # +1
1024-- 08.03.2018 18:18 # +2
1024-- 08.03.2018 18:29 # +1
vistefan 08.03.2018 02:10 # +2
Потому что $foo->bar — это поле bar объекта foo
А $foo->$bar — это поле объекта foo, имя которого будет взято из переменной bar во время вполнения.
Та же залупа, что и с $$var.
Понятное дело, любая ide пойдёт нахуй от такого кода.
SemaReal 08.03.2018 02:27 # +2
Тогда я целиком и полностью за
$foo->{$bar}
Fike 08.03.2018 06:05 # +2
Da!
Для конкатенации строк.
SemaReal 08.03.2018 07:02 # +3
Зачем?
Fike 08.03.2018 07:42 # +1
syoma 08.03.2018 14:49 # 0
В жаве тоже?
Soul_re@ver 08.03.2018 14:55 # +2
syoma 08.03.2018 17:13 # 0
bormand 08.03.2018 17:17 # 0
А оно надо?
syoma 08.03.2018 17:18 # −1
1024-- 08.03.2018 17:29 # 0
Знать об этом нужно только компилятору, чтобы выделить кусок памяти под новый объект при вызове. Если функция f была описана как конструктор выше по коду, компилятор знать будет.
SemaReal 08.03.2018 17:31 # 0
в питончике очень часто этим пользуются: ты можешь и не знать что вчера ты вызывал функцию, а теперь конструктор
Soul_re@ver 08.03.2018 17:19 # +1
И вообще, можно пойти по крестопути и сделать
Foo foo(12);
SemaReal 08.03.2018 17:32 # 0
Может отличаться в япах с полуручным управлением памятю, когда ты должен вручную делать(или не делать) release объекту (так было в objc до arc)
Soul_re@ver 08.03.2018 17:34 # 0
SemaReal 08.03.2018 17:40 # 0
смешно, но в Core foundation и Foundation у яблов был код стайл.
Типа если функция называется так, но она сама отвечает за обхект, а если этак -- то ты.
Я не шучу, погугли "Memory Management Programming Guide for Core Foundation" и там ownership policy
roman-kashitsyn 08.03.2018 17:33 # +2
Конструкторы — в принципе нинужное говно. Даже жависты это поняли. Функций хватит всем.
Foo.of(12)
Soul_re@ver 08.03.2018 17:36 # +1
Foo foo = Foo.Create(12)
Foo foo = Foo.CreateFromDouble(12)
3.14159265 09.03.2018 04:26 # +3
Причём помнится без малого 10 лет назад Тарас всё это уже обосновывал. Но тогда его минусовали, считая трололо/поехавшим.
vistefan 09.03.2018 04:59 # 0
3.14159265 09.03.2018 05:56 # +1
Крестушки наконец стали осозновать что добрая часть хвалёного С++ — «нинужное говно». Ну речь о крестовиках с богатым кругозором.
Ведь какой язык изначально назывался C With Classes?
Это ж ведь не создатели жабы сочинили new, class, static, private, public, наследование и остальной ООП-кал.
Создатели жабы просто заимствовали фичи (вплоть до синтаксиса) из модных тогда крестов, пытаясь сделать из них хоть что-то приличное.
Увы, безуспешно.
3.14159265 09.03.2018 05:59 # 0
Объявление типа, например
Foo foo
var foo : Foo = ...
Только в новомодных языках конца 00х-10х (go, rust, scala, kotlin, younameit) стали отказываться от сишной традиции делать типы спереди.
roman-kashitsyn 09.03.2018 12:44 # 0
bormand 08.03.2018 17:37 # +5
Да и классы — тоже. "Конструктор" возвращает приватный ADT, "методы" умеют с ним работать. Ничего нового классы не дают, только зачем-то разделяют функции/методы/статические методы (и это заканчивается ёблей и унынием).
roman-kashitsyn 08.03.2018 17:42 # +2
Аминь. My point of view exactly.
SemaReal 08.03.2018 17:43 # 0
bormand 08.03.2018 17:45 # +2
Desktop 08.03.2018 18:29 # 0
3.14159265 09.03.2018 04:34 # +3
Жаль wvxvw ушёл, он бы мог вписаться, создав длинный пост о том что: "вы обсираете неправильное ООП,
а в правильном всё по-другому"
К сожалению я так не умею.
roman-kashitsyn 09.03.2018 12:51 # +3
ООП в Common Lisp действительно менее убогое, потому что оно реально делает язык более выразительным (добавляет multiple dispatch). Плюс, основой ООП в CL является функция, а не класс. Можно использовать "generic functions", ни написав вообще ни одного класса, и определять их реализации ("методы") для примитивных типов.
Есть ещё довольно занятная идея комбинаторов методов.
3.14159265 09.03.2018 13:59 # 0
А в кресты его еще не завезли?
>Можно использовать "generic functions", ни написав вообще ни одного класса, и определять их реализации ("методы") для примитивных типов
Это когда для флоата, инта и комплексоного, например, можно по-разному определить арифметику?
>занятная идея комбинаторов методов
Можно поподробнее?
Desktop 09.03.2018 14:04 # 0
roman-kashitsyn 09.03.2018 14:55 # +1
Вкратце: "методы" — это (куски) реализации generic функций. На методах определена операция "сравнения", т.е. из двух методов всегда можно выбрать "более специальный".
Комбинаторы являются атрибутами этих методов у определают, как из списка подходящих "методов" собирается "эффективный метод".
Если комбинатор не указан, т.е. просто типичная "перегрузка", aka primary method.
Kомбинатор :before/:after означает, что текущий метод нужно выполнить ДО/ПОСЛЕ подходящей primary-реализации. :around означает, что нужно обернуть primary-реализацию и вставить что-то до и после (базовая форма АОП).
Есть ещё более эзотерические кобенаторы, вроде "сложи все результаты от всех определённых методов" (как число/список), но на практике я их ни разу не видел.
За детальной информацией прошу сюда
Desktop 09.03.2018 15:11 # 0
roman-kashitsyn 09.03.2018 15:30 # +3
Нет, больше похоже на обычные тайпклассы, как, впрочем, и traits в Rust.
Я понимаю, что соблазн сказать "а, это тоже самое, что X" велик (ведь тогда ни в чём разбираться не надо, типа всё уже знаешь), но нет, не тоже самое.
Desktop 09.03.2018 15:49 # 0
Просто семантически оно вроде похоже (что, видимо, играет злую шутку)
roman-kashitsyn 09.03.2018 16:02 # +2
Сами generic functions тоже не похожи. В CL они не привязываются к одному конкретному типу. Например, можно определить функцию (defgeneric intersects (a b)) и написать методы для случаев (defmethod intersects ((a rectangle) (b circle))), (defmethod intersects ((a circle) (b circle))), (defmethod intersects ((a interval) (b point)))…
В рантайме будет выбран наиболее подходящий эффективный метод. Т.е. это настоящие мультиметоды.
Desktop 09.03.2018 16:07 # 0
Спасибо за ликбез
roman-kashitsyn 09.03.2018 16:11 # +1
В сишарпах это обычно решается через тучу перегруженных функций в интерфейсе, которые знают о всех остальных классах. В CL можно наопределять структур в N разных модулях, которые ничего друг о друге не знают, а потом в N+1 модуле запилить обобщённую функцию, которая определяется для разных кобенаций входных параметров. М — Модульность.
bormand 09.03.2018 16:14 # +2
То же отношение между виджетами и событиями на таких generic'ах прикольно формулируется. Без всяких свичей, визиторов и прочего одномерного говна.
3.14159265 09.03.2018 16:18 # 0
>Без всяких свичей, визиторов и прочего одномерного говна.
А в кресты ничего лучше полиморфизма так и не завезли?
bormand 09.03.2018 16:20 # +1
Ну есть предложение с open method'ами. Но ему ещё далеко до стандарта.
З.Ы. Под полиморфизмом ты же имел в виду убогую но простую и эффективную реализацию через таблицы виртуальных методов? Так то это всё проявления полиморфизма.
3.14159265 09.03.2018 16:27 # +1
Так точно.
http://govnokod.ru/23894#comment407449
Как под ООП все по дефолту подразумевают убогую, но простую реализацию его в крестах и жабах :)
Desktop 09.03.2018 16:23 # 0
3.14159265 09.03.2018 16:25 # 0
Поскольку полиморфизм, то бишь выбор из таблицы виртуальных функций можно свести к свитчу.
Выбор подходящей функции для мультиметода можно сделать через pattern matching, передав туда кортеж из типов. Не?
roman-kashitsyn 09.03.2018 16:42 # 0
Можно. Основная проблема в том, что такой подход сложно расширить на новые типы, см. Expression problem.
Проблема расширения на новые типы в функциональных языках решаема, но нужно заранее структурировать код определённым образом.
3.14159265 09.03.2018 16:42 # +2
Эээ, по-моему конкретно в сишарпах это уже есть, лет 10 как, благодаря кейворду dynamic.
https://ideone.com/ef75t6
roman-kashitsyn 09.03.2018 16:44 # 0
Ок, не знал, спасибо. Расширить табличку можно только через partial-классы, конечно?
3.14159265 09.03.2018 16:57 # 0
Скорость исполнения падает в тысячи раз: до интерпретаторных значений.
Думаю в той же жабе такое можно замутить, через рефлексию, полным перебором сигнатур.
>Расширить табличку можно только через partial-классы, конечно?
Не совсем понял вопрос.
roman-kashitsyn 09.03.2018 16:59 # 0
Если захочется добавлять новые пары для новых типов, придётся править оригинальный .cs-файл.
3.14159265 09.03.2018 17:18 # 0
Но как мне объясняли, их делали для других целей.
Там же для ololo-linq-to-sql запилены генереции DTO из таблиц в базе.
Естественно в автогенерированный код вносить изменения бессмысленно.
Но иногда хочется что-то переопределить, потому сделали частичные классы.
PS> Решил проверить ambiguous-случай, С# стрельнул рантайм-исключением. Как в CL разруливают diamond-проблемы?
http://govnokod.ru/23905
https://ideone.com/Jm5LJA
Desktop 09.03.2018 17:29 # 0
Но они в вашем случае мало помогут, потому что все куски partial class'а должны быть описаны в одном неймспейсе. Короч, либу не расширишь
roman-kashitsyn 09.03.2018 17:35 # 0
Эту проблему решают тем самым сравнением методов. Первые аргументы важнее последующих, более специальный первый аргумент выиграет.
3.14159265 09.03.2018 20:04 # 0
Ну да в традициях функциональных языков принято применять аргументы по одному.
Но я хотел спросить про классический diamond, когда множественное наследование, как тогда дуплить?
(defclass A (object B C) ())
Пишут что CLOS приоритизирует типы в порядке перечисления в defclass.
roman-kashitsyn 09.03.2018 20:11 # 0
Ну у тебя теперь есть отправная точка для экспериментов, проверь :)
vistefan 09.03.2018 04:50 # +1
Давайте я зайду за ООП. Ну почти.
Я думаю ООП — это что-то вроде школы. В школе тебе говорят, что, когда ты вырастешь, ты сможешь стать кем угодно, хотя в общем-то почти сразу понятно, что не так уж и кем угодно. Но главное — учиться на пятёрки.
Так же и в ООП. Это замечательный полигон и точка входа в программирование, которое обещает тебе настолько райскую жизнь, что в погоне за ним, тебе хватает сил перебраться из внешнего мира сюда к нам, в программирование. Плевать, что потом оказывается, что все мечты были несбыточными. Ты уже в деле.
После школы тоже выбор между армией и институтом, а после институда — в сварщики или танцоры, или работники сферы услуг, или офисный планктон, или, в хорошем случае, в талантливые мастера какого-нибудь благородного не подлого и не паразитского дела.
Ведь мы все любим программировать и начали этим заниматься, не потому, что хотели работать на такой работе. Это просто само по себе чудесно.
syoma 08.03.2018 18:00 # 0
Soul_re@ver 08.03.2018 18:02 # +3
> Да и классы — тоже
> класс смешивает в себе кучу ортогональных вещей
1024-- 08.03.2018 17:52 # 0
Самое печальное - что статические поля отличаются от обычных полей, а статические методы не отличаются от обычных методов.
В C++ вообще нет методов, которые относятся к объекту. Самое большое, что реализовали - методы, разделяемые кучей объектов (виртуальные питухи). Методы объекта там могут только эмулироваться громоздкими указателями на функции, но this в них приходится передавать явно и терпеть отсутствие private/protected-членов.
roman-kashitsyn 08.03.2018 17:56 # 0
Отличаются. Их нельзя переопределить в подклассе.
> нет методов, которые относятся к объекту
То ли дело «Common Lisp».
bormand 08.03.2018 18:00 # +1
syoma 08.03.2018 18:02 # 0
Понял что написал херню и потер?
bormand 08.03.2018 18:04 # +3
Да. Но синглтон от этого полезным не стал.
syoma 08.03.2018 18:05 # 0
bormand 08.03.2018 18:10 # +1
И в чём польза синглтона? Какую проблему он решает?
Абсолютно та же хуйня, что и глобалки. Только в красивой обёртке.
bormand 08.03.2018 18:13 # +3
Soul_re@ver 08.03.2018 18:14 # 0
bormand 08.03.2018 18:15 # +1
…которая прибивает к нему гвоздями всех клиентов.
subaru 08.03.2018 18:24 # +5
Другой пример говнобиблиотеки - либкурл, все те же грабли.
Только что характерно, все это говно написано на "няшной" сишочке, а не на джаве. Что подтверждает, что синглтоны изобрели очень давно, но раньше их называли глобальными переменными.
syoma 08.03.2018 18:36 # 0
Млять. Я не предлагал же их пихать везде. Они *могут* быть полезны. Неужели непонятно?
bormand 08.03.2018 18:36 # 0
Где и чем? В чём преимущество перед обычными функциями.
Soul_re@ver 08.03.2018 18:37 # +4
syoma 08.03.2018 18:39 # 0
syoma 08.03.2018 18:38 # 0
Soul_re@ver 08.03.2018 18:40 # +1
syoma 08.03.2018 18:41 # 0
Soul_re@ver 08.03.2018 18:45 # +1
Классическое определение синглтона: это класс, который не даёт возможности создать больше одного экземпляра ("сингл"), созданием которого сам и управляет, и даёт возможность доступа к этому экземпляру.
syoma 08.03.2018 18:52 # −1
Soul_re@ver 08.03.2018 18:56 # +3
Объект существующий в единичном экземпляре ≠ класс, который следит, чтобы больше одного экземпляра не было создано.
syoma 08.03.2018 19:16 # 0
это класс, который не даёт возможности создать больше одного экземпляра ("сингл"),
Чувствуешь разницу?
subaru 08.03.2018 19:19 # +3
мне нравится такое название
syoma 08.03.2018 21:33 # 0
bormand 08.03.2018 18:50 # +1
ООПшники всегда любят себе создать одну из нескольких проблем… Даже на таком простом примере какую-то неюзабельную хуйню надизайнили. А если я захочу ошибки писать на экран, а подробные логи — в файл? Или иметь по логгеру на тред?
syoma 08.03.2018 18:53 # 0
bormand 08.03.2018 18:58 # 0
Ты про logging.debug() без запиливания своего инстанса логгера? Ну дык это обычные функции, внутри синглтон там может и есть, но это деталь реализации этих функций.
subaru 08.03.2018 19:05 # 0
syoma 08.03.2018 19:15 # 0
1024-- 08.03.2018 18:54 # 0
SemaReal 10.03.2018 15:18 # 0
Такой объект лениво создается, считает всякое разное, сохраняет во внутреннем состоянии эти расчеты, и может передаваться в разные функции как стратегия.
Его конечно можно заменить лямбдой со static переменной(или структурой из пачки таких лямбд), но ООПетушкам всё таки приятнее общаться с классами и интефейсами.
В жырном энтерпрайзе в DI на спринге часто бывают сервисы с лайфтаймом singleton. У некоторых IDE бывают всякие application service которые живут пока живо приложение итд
А вот когда вместо функции fuu делают класс-синглтон (Со всей говномашинерией, ибо в жабе нативной поддержки оных нет) ради одной функции это правда смешно.
bormand 11.03.2018 05:12 # 0
Но там же сам класс не завязан на то, что контейнер запилит ровно один его инстанс. И его клиенты об этом не знают. Так что это всё-таки не классический говносинглтон.
SemaReal 11.03.2018 05:13 # 0
bormand 11.03.2018 05:16 # 0
Меня бесит, когда код завязывается на то, что инстанс будет ровно один.
Да и сам способ получения через какой-нибудь getInstance().
subaru 08.03.2018 18:46 # +2
SemaReal 08.03.2018 19:08 # +1
лол, в процедурном подходе это как-то не так?
1024-- 08.03.2018 19:14 # +1
3.14159265 09.03.2018 04:24 # 0
>Да и классы — тоже.
Внезапно выяснилось что паскальный подход был логичнее.
А крестобляди 90х и последовавшие за ними жависты, шарперы, опять обосрались.
SemaReal 08.03.2018 17:41 # 0
roman-kashitsyn 08.03.2018 17:48 # +1
>> в языках где программист не управляет расположением объекта
Да даже в каких-нибудь крестах можно было обойтись, просто "волшебные" функции иметь, на наличие которых полагается компилятор.
SemaReal 08.03.2018 17:30 # 0
неймспейс создает именно "new", регистр в джаве на это не влияет (это не ruby, где UPPERCASE всегда R/O), но можно было изначально не делать new и не писать одинаковых методов и иннер классов (напомню что в жабе топ-лепел функций нет)
SemaReal 08.03.2018 17:11 # +5
в колине его нет
"new" значит "создать объект в динамической памяти". Лол! Будто-бы в жабе я могу этим управлять.
dm_fomenok 09.03.2018 11:08 # 0
"new" обычно значит "создать объект и вызвать конструктор"
SemaReal 11.03.2018 15:32 # 0
Интуитивно должно быть так:
Foo foo = Foo(); //Foo на стеке
Foo* foo = new Foo(); //Foo на куче
Так как в жабе, JS, C#, и прочей автоматически работающией с памятью питушне пользователь не управляет выбором места (он как-бы думает что объект всегда на куче, хотя это не так на самом деле) то смысла в слове new нет
dm_fomenok 12.03.2018 17:49 # 0
А теперь отличи это от malloc
SemaReal 12.03.2018 17:51 # 0
3.14159265 09.03.2018 14:08 # +1
В жабе new они сделали больше из соображений читабельности и чтобы народу с крестов было проще пересаживаться.
>Лол! Будто-бы в жабе я могу этим управлять.
Изначально все объекты действительно тупо плодились на куче. Спустя годы хотспот обучили новым трюкам (сугубо из соображений оптмизиации).
А рудименты от крестов остались:
int[] a={1,2,3,4};
int[] a=new int[10];
int[] a=new int[]{1,2,3,4};
SemaReal 11.03.2018 15:37 # 0
(кстати, в Питоне его не было изначально)
>> Спустя годы хотспот обучили новым трюкам
Под капотом JVM имеет право создать объект на стеке если понимает что ты указатель на него никуда не передаешь и не возвращаешь, но думать об этом ты не должен;)
>>int[] a=new int[]{1,2,3,4};
м-да, вербозненько
3.14159265 12.03.2018 19:08 # +1
В яве нет указателей, только ссылки.
>[new] Изначально для читабельности
Налицо полное непонимание. Когда делали яву, постоянно оглядывались на С++. А там при присваивании стековых объектов, они копируются.
dm_fomenok 09.03.2018 10:57 # 0
subaru 09.03.2018 11:40 # +1
dm_fomenok 09.03.2018 11:55 # 0
subaru 09.03.2018 12:02 # 0
SemaReal 11.03.2018 15:41 # +2
dm_fomenok 12.03.2018 17:48 # 0
SemaReal 12.03.2018 17:51 # 0
зачем мне лишние буквы в коде?
dm_fomenok 12.03.2018 17:54 # 0
Зачем тебе вообще код?
SemaReal 12.03.2018 18:05 # +1
В котлине я пишу
val foo = Foo();
foo.bar();
Это точно так же понятно как и
$foo = new Foo();
$foo->bar();
хотя букв меньше
vistefan 12.03.2018 18:08 # +2
dm_fomenok 12.03.2018 18:49 # +1
bormand 12.03.2018 18:51 # 0
SemaReal 12.03.2018 18:54 # 0
bormand 12.03.2018 19:01 # +1
vistefan 12.03.2018 19:40 # +2
bormand 12.03.2018 19:06 # 0
SemaReal 12.03.2018 19:09 # 0
в Django есть User.objects.get_or_create() :)
dm_fomenok 09.03.2018 11:12 # 0
docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-7-2#private-protected-access-modifier
SemaReal 11.03.2018 15:38 # 0
Спецификация C# пока не дотягивает по размерам до спеки C++, но ребята работают.
Скоро c# станет сложнее крестов
3.14159265 12.03.2018 19:04 # +1
bormand 12.03.2018 19:18 # 0
З.Ы. "Предварительная спецификация C# 6.0", время чтения: 2 минуты.
bormand 12.03.2018 19:22 # +2
3.14159265 12.03.2018 20:04 # 0
bormand 12.03.2018 20:09 # 0
SemaReal 12.03.2018 21:57 # 0
bormand 12.03.2018 21:59 # 0
SemaReal 12.03.2018 22:35 # +2