- 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
Map<String, TrainingDataLine> trainingMap;
public class TrainingDataLine {
Integer v;
List<RelationSourceBean> r;
public class RelationSourceBean {
Integer e;
Integer n;
public Integer getE() {
return e;
}
public void setE(Integer e) {
this.e = e;
}
public Integer getN() {
return n;
}
public void setN(Integer n) {
this.n = n;
}
}
public Integer getV() {
return v;
}
public void setV(Integer v) {
this.v = v;
}
public List<RelationSourceBean> getR() {
return r;
}
public void setR(List<RelationSourceBean> r) {
this.r = r;
}
}
Follow us!
В пхп, например, заводишь массив и заебись.
даже не статик
но я тебе этого не говорил
лямбды это хорошо, но запутывает нить исполнения, а кложи создают неявные захваты сцылок
В джаве еще не так все плохо ибо GC
Вот в ObjC блоком можно ой налажать (см, например, strong weak dance)
Джава.
въебал плюс
а потом LinQ
А потом вывод типов
А потом dynamic
а потом нул/не нул контракты прямо в язык
а потом генерики в рантайм
а потом получится язык, у которого ключевых слов больше чем пользователей на говнокодике
>а потом Y введут
> ...
>а потом получится язык
С++
Еще есть Scala, но там хотя бы идеи функцианальные как-никак.
>а потом кортежи введут
http://govnokod.ru/12153
Когда б вы знали, из какого кала, растут они не ведая стыда.
в пистончике есть туплы, и это хорошо и математiчно же.
Правда уроды все равно используют их как рид-онли листы. Я бы вообще запретил бы итерироваться по картежам
Но туплы размерностью >3 НЕ НУЖНЫ в принципе.
Тем более гордить вот это вот.
http://reflector.webtropy.com/default.aspx/4@0/4@0/untmp/DEVDIV_TFS/Dev10/Releases/RTMRel/ndp/clr/src/BCL/System/Tuple@cs/1305376/Tuple@cs
ну типа (вася, пупкин, валенки, 25 лет, трактарист)
очень хорошо - очень плохо?
Но почему? Ты прагматичный немец и экономишь электричество?
ты наверное хотел сказать "придумали структуры"
но я как я уже писал ниже, иногда создавать класс ради одного кейса -- глупо
ну вот нахуй тут класс-то?
а если у меня один метод на один случай?
преоптимизация?
>> get_sex()
охуеть, дайте два
age: 30
nationality: Russian
sex: every day
Знаешь как прикольно делать класс, особенно наприер в шестой джаве?
берем данные, засовываем в тайпл, передаем, достаем данные из тайпла....
а в самом коде не проще вызвать get_login() и get_name()?
Тайпл - это костыль в хуевой архитектуре
Смотри: допустим у меня есть три приватных функции, и я между ними должен передавать какую-то свою структуру данных. Вот она мне только вот тут нужна, и больше нигде.
Это не часть API и у нее нет своего поведения и она может вообще выглядеть глупо и не иметь даже внятного имени.
Зачем тут класс?
Кроме того иногда правда треба вернуть 2 значения. Я конечно понимаю что в языках, содержащих в названии букву C для этого можно спровайдить указатель или ссылку, но во-первых в жабе так нельзя, во-вторых передавать их дальше все равно сложно.
А кроме того: тупла в ЯП со стат. типизацией сосет ибо проебывается типизация, а например в пистончике не сосет ибо типизации статической и так нет.
Но я согласен с тем, что кортежи длиной в 20 символов бесят, а кроме того это не замена же классам.
Хуевая архитектура
>> Смотри: допустим у меня есть три приватных функции, и я между ними должен передавать какую-то свою структуру данных. Вот она мне только вот тут нужна, и больше нигде.
Почему не сделать это через побочные эффекты?
Приведи адекватный пример, на словах ниче не понятно
Хуевая если это экспортируется в public api, а внутри модуля нормально.
>>Почему не сделать это через побочные эффекты?
какие эффекты, если это обычная функция и питон, например?
>>Приведи
ну вот что тут делать? класс ``UserWithScore`` с двумя полями? класс ``CompetitionParticipantInfo``?
Мне кажется что это дискуссия из серии нужно-ли всегда делать максимально круто, или нет
Например нужно-ли всегда иметь Service Layer, ORM, MVC итд
я знаю что send_email_to_winners можно сократить через filter или list comprehision
я для наглядности, вдруг кегги пистона не знает
Видимо для тебя и в жопу ебаться нормально, главное что бы никто не видел
Ладно, не суть
Ну, питон на то и питон. Он и прочие скриптовые языки поощряют кортежи сахарком, угу, говноязыки поощряют говнопарадигмы
Но почему не создать класс, который содержит в себе имя, очки, toString и т.д?
А потом функции, работающие с конкретным типом данных, и объединенные конкретной логикой размазаны по галактике
весна чтоли?
Я действительно считаю что публичный API в тысячу раз важнее кишок модуля
>>Но почему не создать класс, который содержит в себе имя, очки, toString и т.д?
Потому что:
1) много буков
2) как его назвать?
Так что тульпы - зло. Даже если ими не злоупотреблять. Пусть лучше будет новый класс (структура) где-нибудь в сторонке, в котором поля по-человечьи названы.
не пробовали ее читать?
Кстати, замечательная цитата:
если в тупле 2 члена, и все ее использование ограничено одним модулем то проблем с чтением не возникает
а вот проблемы с пониманием класса с невнятным именем точно будут)
А потом ещё следить за тем, чтобы она соответствовала реальному коду! После каждого изменения, КАРЛ! Ну и нахуя такая еботня, если можно делать код самодокументированным?
будет либо класс с невнятным именем, либо тупла
тупла проще
читать доку придется и так и так
публичные API, кстати, надо документировать
нормальные API тем и отличаются от говна, что у них есть мануал
Невозможно сделать самодокументированным, если ты хуёвый программер. Это обычная инженерная задача - написать код так, чтобы документация на банальные конструкции (не бизнес-логику) была не нужна.
> будет либо класс с невнятным именем, либо тупла
Что понятнее? Мне лично за вторую конструкцию хочется убить. И потом уже закопать, когда из тульпы item1 & item2 извлекаются.
из его названия следует что он представляет очки пользователя, а не пользователя и его очки
чтобы это понять, мне придется пойти и посмотреть на сырцы класса, где меня встретят много ненужных букв
а в случае джавы так еще и геттер и конструктор
(и еще .class файл, бугага)
А вот IEnumerable<Tuple<User,int>>GetTopUserAn dScore() выглядит достаточно годно
Если в тупле будет хотя бы 3 поля или если это будет публичное API, то тогда я конечно сделаю класс
Ну да, оооочень сложно. Без бутылки не разберёшься.
Это в идеальном случае, когда внутри тела метода три точки, нужно только передать параметры и принять их. Если про реальный код говорить, то тут может быть айди вместо юзера (как у меня в коде), нужно будет эти данные собрать, сложить, отсортировать. Вот в класс я возьму и воткну компаратор по Score. А потом Equals по userId, хэшкод туда же. Куда ты это всё засунешь в тапл? В очко ей?
> из его названия следует что он представляет очки пользователя, а не пользователя и его очки
"Мартышка и очки", бгггг! Ну всё правильно, в первую очередь очки интересуют, у нас же топ.
Кстати, я советую код писать в IDE, а не блокноте.
потому что у тебя bulb paradox
Шобля?
Они уже тыщу лет в шарпе. И пара лет уж точно прошло, как я за "передовыми" мартышками переделывал говно вроде такого: http://govnokod.ru/19815
> и через пару лет сам будет вещать тут об их преимуществах
Да щаз.
Это я сначала был рад такому нововведению. Теперь, по прошествию пары лет, я это закопать хочу там, откуда это выползло.
> потому что у тебя bulb paradox
Парадокс Блаба, же, а не лампы, идиота кусок. Хоть проверяй, чем подъебать собрался.
Макрософт, вы там охуели? Ну, всмысле, больше обычного
А с таким критическим отношением можно на брейнфаке писать. И если 99% программистов не умеют писать программы, то не надо пенять на C++ и php и стараться ограничивать язык до пары фраз, чтоб уж точно не ошибиться, надо программировать учиться и других учить.
В шарпе нахуй не нужны элементы скриптового языка. Если майкрософт хочет скриптовый язык - пусть делает новый скриптовый язык с ноля, а не шарп уродует ИМХО
Или создаст себе метаинструменты, которые кроме него никто не понимает. (Пример метаинструмента - операция умножения в Brainfuck)
А бородатые админы пусть продолжают страдать. Не поняли, что 4 языка в одном - преимущество - значит пусть используют только царские массивы. Массивов хватит всем.
сомнительное преимущество.
Такой язык превращается в раскрытый швейцарский нож - вроде все есть, а пользоваться неудобно
"Пусть функция делают одну вещь, но делает ее хорошо"
А потом народ тихо пилит всякие синглтоны и статические функции. ООП, да не ООП. Процедурный подход, но крашеный.
И ещё то, на что пирфоманса не хватило, переписывают на другом языке. Потом важные куски по сшиванию этих модулей суют как метакод во всякие мэйкфайлы и проую питушню, нужно устанавливать сразу компилятор сишки, питон и .NET фреймворк нужной версии.
Вместо туплы можно сделать hash:
а потом сказать "да это же объект! ооп!" и ведь это будет правдой!!
Плюсы всяко не хуже перла в плане читаемости, и при всей их мерзости, однако, это редкий ЯП где есть с одной стороны прямой доступ к памяти, а с другой ООП и шаблоны, и в это его сила
кортеж это легкая альтернатива классам для создания записи. Но если в ЯП есть способ сделать класс в три строки (как в котлине например, да и в C# это просто) и не компилиться в отдельный .class файл (привет, jvm) то конечно туплы нужны почти никогда
dynamic нужен для скриптовых языков в clr;) А в шарпике он нужен для очень волшебной магии тоесть практически никогда в обычном коде
null/notnull лучше разделить на уровне типов(как в приснопамятном котлине) ну или сделать паттерн матчинг