- 1
- 2
- 3
- 4
- 5
- 6
- 7
for (var i = 0; i < result.Results.length; i++) {
data = result.Results;
if (i == 0) {
$calendarPins = jQuery.parseJSON(data[i].Markers);
GoogleMapsInitialization();
}
}-
JavaScript / Говнокод #17425
+169
Аж за душу взяло...
Запостил:
zloynightmare,
09 Января 2015
Follow us!
Даёт всем подряд?
Простите, не удержался.
http://4.bp.blogspot.com/_YtxGNf8GgRA/TOXLQN3-j0I/AAAAAAAAFUI/e1g0DOEKhv8/s1600/make_tea_not_love.png
Надо что бы статический анализатор шел сразу в комплекте с компилятором/интерпретатором. Так же кроме Error, Warning, Notice ввести уровень сообщений KillItWithTheFire как раз для таких случаев. После вывода сообщения - удалять файл с исходниками.
ECMA-script
Более того, из современных языков ECMA-скрипт самое дерьмовое дерьмо. Даже пыхпых в сравнении с ним кажется просто шедевром архитектуры.
- И ЧТО И ЧТО В ПИТОНЕ ТОЖЕ ЕСТЬ И ИМИ ДАЖЕ ПОЛЬЗУЮТСЯ!
- В питоне есть какая-то пародия, сделанная через жопу
- А ЧТО ТЫ ХОТЕЛ ОТ ЯЗЫКА С ДИНАМИЧЕСКОЙ ТИПИЗАЦИЕЙ? ИНТЕРФЕЙСЫ НЕ НУЖНЫ!
у меня другой вопрос: вы-то вдвоем что хотели доказать?
Есть. ABCMeta.
>> ни неймспейсов
Есть. Пекеджи и модули..
>> ни абстрактных классо
Есть. ABCMeta.
>>это надстройки библиотеки, к которым еще надо обращаться
Разумеется. Как и в любом языке без *статической* проверки типов.
Хорошо или плохо не иметь статическую проверку -- вопрос для дискуссии.
Но в пайтоне это сделано честно и внятно. А в ПХП через жопу и местами.
Потому что у пайтновца в голове ясная картина (хотя и спорная конечно), а у ПХПиста каша. Как в языке, каша в голове, каша в библиотеке.
Потому что ты так сказал, ага.
Это вообще нихуя не про конкретный язык. Это про модульность, совместимость, тестирование и все прочее веселье, от которого большинство добровольно отказывается.
А в чем проблема с модульностью в Питоне? Там контракты можно выразить по-другому. Более того, изначально речь шла не об интерфейсах, как механизме взаимодействия, а как элементе языка. В чем проблема в Питное предоставить свою реализацию с тем же интерфейсом?
Оох блядь.
Еще раз: мне нужно просто, легко и из коробки задавать контракты для реализаций, не трогая реализации вообще.
Это и есть интерфейс, откуда ты яву взял - я хуй знает, я понял бы если бы мы про аннотации говорили, которые в пыхе сделаны так же, как интерфейсы и абстрактные классы в питоне.
Да пусть он хоть валяется рядом текстовым файлом с аналогичным названием, но иным расширением.
> А в чем проблема с модульностью в Питоне?
В невозможности по-человечески сделать хотя бы более-менее защищенный механизм замены одной реализации другой, не залезая в клоаку zope.interfaces. Всегда придет еще один питонщик, нихуя не поймет, навертит свою реализацию, на половину багов он скажет, что в питоне так принято, на вторую - что писавший приложение, принимающее этот модуль, мудак и слегка гей.
> Там контракты можно выразить по-другому.
Да, мы это уже выяснили. Через клоаку стандартной библиотеки. Чтобы получить ровно тот же результат, что и в яве.
> Более того, изначально речь шла не об интерфейсах, как механизме взаимодействия
Ты мне рассказываешь, о чем я изначально имел в виду, когда писал первый комментарий? Ну охуеть теперь.
Да, я тебе рассказываю, что ты имел в виду, потому что ты намеренно сменил тему разговора, и втираешь какую-то хуйню, которая только похожа на то, что ты говорил раньше, но на самом деле не имеет к этому отношения, тем самым запутываешь и себя и других.
При чем тут клоака стандартной библиотеки? Сама по себе возможность отложить проверку типов, в любом языке, позволяет элементарно решить задачу контрактов. Это на столько тривиально, что обычно никто себя не утруждает объяснениями очевидных вещей.
Последнее изменение этой страницы: 01:03, 30 октября 2014.
Текст доступен по лицензии Creative Commons Attribution-ShareAlike, в отдельных случаях могут действовать дополнительные условия. Подробнее см. Условия использования.
Аналогичная проблема есть в крестах - там типы в шаблонах ничем не ограничены, у них "компайл-тайм утиная типизация". Это с одной стороны гибко, с другой - большая проблема, т.к. требования к интерфейсу можно описать только в документации, и в случае проблем компилятор выдаст ошибку где-то в кишках чужого кода.
Для решения этой проблемы, собственно, и продвигают "концепты".
Ну и понятно, что если, например, интерфейс обещает, что откроет файл, а вместо этого станет загружать его из интернета, то как бы тоже лажа получится: формально он вроде делает что-то похожее, но на самом деле скорее всего делает что-то не просто бесполезное, а еще и опасное. (Непридуманый случай).
То, что решение о соответствии интерфейсу можно отложить до момента когда это взаимодействие понадобится - это плюс, ради этого все и делалось, ради этого объекты, например, и задумывались - чтобы можно было во время выполнения кода принять более правильное решение, а не опираться на устаревшие данные.
тогда регистрируй ник ТупизатионГовно и больше не тупи
Что мне блядь придется лезть куда-то и читать этот ебаный интерфейс, вместо того чтобы написать implements XXX и смотреть в подсказки IDEшки.
Изоляция, single responsibility principle, отделение интерфейса от реализации, слышал о чем-нибудь таком? Все _нормальное_ программирование построено на атомарности и убийстве взаимосвязей между разными кусками кода, и сам программист тоже не должен думать о разнице между urllib, urllib2 и urllib3 (к слову о модульности в питоне), пока я пишу какой-то кусок кода, у меня должен быть просто HTTP-транспорт, который принимает на вход Х, а на выходе дает Y. Я не должен сверяться с какой-то спекой, пока пишу реализацию, мне не нужно лезть в какой-то охуевший браузер, мне нужно здесь и сейчас, прямо в этом файле видеть то, что я реализую, и если я охуенный программист, у меня все должно работать при первом же подключении модуля.
Каким образом типизация запрещает задать требования к чему-либо на уровне языка - я не знаю.
1. предполагать, что реализован интерфейс с тем же именем, но другими методами.
2. предполагать вещи никак не связаные с интерфейсом. (Пример - сериализация в Яве, другой пример: укажи в интерфейсе необходимость того, чтобы передаваемый список был отсортированым, или чтобы функция всегда завершалась).
С другой стороны, возможность интерактивно посмотреть то, как используется мой код другим кодом дает мне больше уверенности в том, что то, что я пишу таки соответствует желаниям другого человека.
Хуйню про ХТТП транспорт читать не стал: много буков и ноль смысла.
ой пиздец
Возникает она очень просто - кто-то решил улучшить интерфейс и что-то в него добавил (менять и удалять мало кто решится, а вот добавить - решаются).
К слову urllib2.urlopen вполне себе интерфейс - он возвращает "file-like object" - это универсальный интефейс к любому потоку - то же самое при вызове file() или использовании stringio. В PHP gzopen и fwrite несовместимы между собой (это конечно решаемая проблема, но никакими интефейсами не пахнет)
>> вместо того чтобы написать implements XXX и смотреть в подсказки
>> IDEшки.
ну откройте же для себя ABCMeta и @abstractmethod наконец!
Вам PyCharm подстветит если Вы не реализовали нужный метод, и даже поможет реализовать его!
2. Jetbrains, конечно, молодцы, но это а) абстрактный класс, а не интерфейс и б) нахуй мне писать что-то длинее, чем слово abstract перед объявлением класса?
А что близко, кстати,
>> абстрактный класс, а не интерфейс
Никакой разницы нет совершенно в данном случае. Абстрактный класс позволяет задать проверяемый статически контракт, равно как и интерфейс.
>> нахуй мне писать что-то длинее, чем слово abstract
А нахуй в других языках скобочки писать? Или слово function вместо def?
В Python и правда с ООП не всё хорошо, но так ведь у других скриптовых языков еще хужее (ну разве что руби у него выигрывает, не знаю).