Есть такие динозавры, как я, которые помнят времена без ajax и прочих удобных механизмов подгрузки. В те ламповые времена мы делали скрытый iframe и в него загружали backend обработчик, который просто выплевывал js и делал нужную обработку на родительском фрейме. Т.е. с бэка приходили не данные, а готовые команды как поменять страницу. Это были брутальные времена, теги <font>, <object>, <frameset>, <center>, проблемы с прозрачными png... И знаете какая была проблема тогда у программистов? Как в IE сделать подгрузку в скрытом фрэйме так, чтобы небыло характерного звука, который IE добавлял при каждой перезагрузке страницы.
раскрыть ветку (74)
Вот ползаешь по сайту, свёрстанному фреймами, и в какой-то момент добавляешь закладку на интересную страницу.. думаешь ты.
раскрыть ветку (5)
раскрыть ветку (4)
В каждом фрейме почти независимые друг от друга страницы, когда тыкаешь по ссылке в одном фрейме, а страница открывается в другом фрейме. Фактически каждая из этих страниц имеет свой собственный адрес, а в строке браузера отображается адрес всего фрейма, который не меняется в процессе навигации, и закладка стаавится тоже на этот адрес.
раскрыть ветку (2)
Для тех, кто не веб-разраб, тогда уж. В мобильном UI нет такого явления, как закладки на страницы.
раскрыть ветку (1)
ммм... ностальгия
<meta http-equiv="refresh" content="1">
или
flush();
ob_flush();
sleep(1);
раскрыть ветку (9)
если уже понастальгировать про мету, то такое
<meta http-equiv="Page-Enter" content="blendTrans(Duration=0.5)">
<meta http-equiv="Page-Exit" content="blendTrans(Duration=0.5)">
Это работало только в IE (на тот момент 80% всех пользователей) и это было превосходная штука. Суть её в том, что можно управлять эффектом смены страницы. Например, можно при клике по гиперссылке текущую страницу разрушать ромбиками, а новую показывать шторками. Это все убрали ещё в IE9, но просуществовало оно прилично. Помню на форуме собственного производства применял. И... Мода, как известно, возвращается) Сейчас есть новое WebAPI , которое примерно такое же позволяет делать
document.documentTransition.prepare({...})
Вот тут подробнее https://developer.chrome.com/blog/shared-element-transitions...
раскрыть ветку (3)
раскрыть ветку (2)
а помните были карты изображений на html. можно было на картинке задать координаты, и при нажатии на ней открывалась нужная ссылка?
раскрыть ветку (1)
Еще бы! Одна из возможностей создания "кривых" интерактивных областей до полноценного появления поддержки svg, исключая, конечно, флеш и сервелат.
раскрыть ветку (4)
sleep(1); тут был необходим по двум причинам:
1) sleep не учитывается как процессорное время при исполнении скрипта, от чего он не завершался аварийно по таймауту установленному в max_execution_time (конечно можно было бы установить в рантайме set_time_limit)
2) Т.к. этот код гонялся в цикле, то опрос таблицы БД, отвечающей за последний стек обновленных данных, происходил раз в секунду, чтобы минимизировать нагрузку и не долбить запросами бессмысленно
раскрыть ветку (3)
без понимания задачи сложно судить.
так понимаю, там не было возможности один раз опросить БД, получить все данные, в цикле отрисовать что нужно.. и один раз выплюнуть результат?
раскрыть ветку (2)
Если кратко, то это был чат и таким образом в нем была реализована возможность вывода сообщений фактически в реалтайме (с делейем в 1 секунду конечно).
Это сейчас можно сказать, что нечего колхозить, а используй: jquery+ajax с интервалом, лонг полинг, socket.io с вебсокетами, pub\sub'ы, feather, derby, meteor, grpc, graphql и всякие другие названия и аббревиатуры.
Но это был год, эдак 2005-2006, и реализовано это было на стеке php4.4.x + mysql с упором на IE (в фоксе, вроде, не работала такая реализация)
А суть проста, главный фрейм висел постоянно в состоянии загрузки, за счет конструкции
flush();php скрипт в цикле опрашивал таблицу с последними сообщениями и осуществлял вывод, за счет ob_implicit_flush была возможно осуществлять сброс вывода буфера сразу после ob_flush, таким образом новые сообщения моментально отображались в данном фрейме (за каждую итерацию цикла).
ob_flush();
sleep(1);
раскрыть ветку (1)
понял.
в таком стеке работать не приходилось. я развращён php7.4 Yii2 + ajax.
за что люблю разработку... каждый раз начиная таску разрабы говорят "это не возможно"... а потом как то да реализуют.
Изображения, свёрстанные таблицами из кусков. Платформозависимый CSS, платформозависимые скрипты, платформозависимое всё. «А ты точно везде включил поддержку юникода? У меня тут кракозябры какие-то» Поворот GIF на 90 градусов, чтобы уменьшить его размер. ActiveX, Flash, Java Applet.
Господи, как это было… хуёво!
раскрыть ветку (51)
Ну вот Flash чем же хуево? Он был отличной штукой. Сейчас ему до сих пор нет адекватной замены. Все то WebAPI, что предлагают браузеры во-первых сложнее в применении (тот же WebSocket vs Socket в AS3, или HTMLCanvasElement vs Sprite, или банально фоновый звук воспроизвести c loop в html без костыля нельзя), а во-вторых flash очень хорошо все оптимизировал и в итоге ресурсов требовалось меньше, не нужно было заботиться о кроссбраузерности. Короче я как AS2/AS3 Flash разработчик в прошлом категорически не согласен, что это было хуево )
раскрыть ветку (50)
раскрыть ветку (43)
и чем проприетарность мешала, например, вам лично? Я вот сколько себя помню сижу на проприетарном Windows и не сказал бы, что мне от этого плохо.
А по поводу дырявости - любой популярный продукт подвержен такому, но flash регулярно обновлялся и уязвимости закрывались.
раскрыть ветку (42)
Коллега, не спора ради выскажу Вам своё мнение. Если у Вас нет ни тени сомнения в себе, то не стоит дальше читать.
Чем глуше закрыта и уже локализована разработка API, тем выше в нём уровень абстракций ввиду специализации под нужды конкретных компаний-заказчиков. В открытых свободных системах задача проектирования абстракций передаётся пользователям API, ограничивая спецификацию до минимума, максимально приближая её к железу.
Таким образом, от открытых API получают выигрыш разработчики кроссплатформенных систем, потому что сокращаются затраты на оборачивание внешних API в собственные абстракции. В частности, тут и есть мой личный профит.
Проблема дырявости Flash была в том, что он везде был дырявый одинаково, а у разрабов-пользователей не было возможности самостоятельно убедиться в его надёжности. В противовес, сейчас каждый браузер дыряв по-своему, а его исходный код можно свободно читать. Спецификация одна, а реализовывает её каждый по-своему. Такой вот уход от монополии.
раскрыть ветку (41)
звучит все разумно) Со своей стороны мне было безразлично проприетарный flash или нет, у него хорошая документация, багов было не много, разрабатывать было комфортно. Конечно если вспомнить, то flash плеер нужно было устанавливать (как и для других подобных вещей, типа Silverlight или Java Applet) и это сильно мешало, но множество других плюсов перевешивало этот недостаток. Да и не только разработка на флеше была крутой, ещё ведь на нем делали мульты, различные полуигровые баннеры и кучу всего. Поэтому я вспоминаю эпоху флэша как нечто хорошее, точно не как "хуевое" :D
раскрыть ветку (40)
А я на перле в детстве хуи в консоли рисовал и друзьям показывал. Было весело. Однако, это хуёвейший язык «общего» назначения, что я осознал гораздо позже.
Абстракции вечны, реализации сменяют друг друга. Концентрируя внимание на высоком уровне, на философии, и используя низкий уровень лишь в качестве инструмента, можно сохранить здравый рассудок в калейдоскопе прогресса техники.
Тот факт, что я когда-то писал на хуёвых языках и платформах, не делает меня хуёвым человеком. Отрицание факта хуёвости этих решений по сравнению с новыми альтернативами делает меня человеком, отрешённым от настоящего, живущего прошлым. Подобный расклад лично меня не устраивает, но я никому не навязываю своё мнение.
Абстракции вечны, реализации сменяют друг друга. Концентрируя внимание на высоком уровне, на философии, и используя низкий уровень лишь в качестве инструмента, можно сохранить здравый рассудок в калейдоскопе прогресса техники.
Тот факт, что я когда-то писал на хуёвых языках и платформах, не делает меня хуёвым человеком. Отрицание факта хуёвости этих решений по сравнению с новыми альтернативами делает меня человеком, отрешённым от настоящего, живущего прошлым. Подобный расклад лично меня не устраивает, но я никому не навязываю своё мнение.
раскрыть ветку (39)
Какой-то философский шум, с которым так и хочется поспорить. Особенно та часть про абстракции вечны) Но толку спорить нет. Тут каждый со своего опыта и мировоззрения смотрит. Я тоже программировал на многих ужасных языках, то же семейство Basic, начиная с QBasic, Real Basic, VB, VBS, VB for DOS. Да и из свежих выученных языков тоже к говну отнесу Rust по ряду причин. Однако я полностью объективно заявляю, что до сих пор, со всеми прелестями js на свежих ES стандартах, или TypeScript - AS3 (Adobe Flash 8+) был отличным языком того времени, в котором было то, что многие другие языки до сих пор не применили. Поэтому абстракции и их реализации - это все просто красивые философские речи про архитектуры, а по факту загубили отличный язык, жаль он помер вместе с flash)
раскрыть ветку (38)
Спрошу интереса ради, что такого было в AS3 по сравнению с TypeScript, если говорить о языках в отрыве от сред исполнения?
раскрыть ветку (37)
ну первое, что на ум приходит - область видимости internal. Т.е. я мог объявить класс или метод класса видимостью internal и его могли вызывать все, кто в том же пакете классов. Штука реально полезная, когда хочешь иметь чистый интерфейс публичных классов, но при этом позволять внутри пакета классам общаться между собой без преград.
Если конкретно с TS сравнивать, то например в AS было четко с примитивными типами string и number, а в TS, как известно, типы string и String - это разные типы.
Ну а все остальное - это уже набор возможностей самого языка, это нельзя сравнивать с TS, так как по сути TS не является языком, а лишь сахар для JS.
раскрыть ветку (36)
Что ж, internal действительно звучит полезно. Как friend в C++. Хороший инструмент в умелых руках.
Тип String в JS — анахронизм, живущий за счёт того, что у JS до сих пор всего одна мажорная версия. За полную обратную совместимость приходится платить.
Всё-таки, TS, по определению — язык программирования. Транспилятор вместо компилятора не меняет этого факта.
По моему личному мнению, любой язык без АТД однозначно проигрывает языку с АТД по выразительности.
Тип String в JS — анахронизм, живущий за счёт того, что у JS до сих пор всего одна мажорная версия. За полную обратную совместимость приходится платить.
Всё-таки, TS, по определению — язык программирования. Транспилятор вместо компилятора не меняет этого факта.
По моему личному мнению, любой язык без АТД однозначно проигрывает языку с АТД по выразительности.
раскрыть ветку (35)
Всё-таки, TS, по определению — язык программирования. Транспилятор вместо компилятора не меняет этого факта.
тогда раз это язык, почему не работает такое
interface Foo {}
someVar instanceof Foo
Потому что Foo - это нечто, его нет, не существует. Поэтому его и нельзя оператором сравнивать. Все же TS не язык, а просто синтаксис, который нужен для типизации JS, не более того.
раскрыть ветку (34)
А почему не работает new 1? Потому что я это только что придумал, наплевав на язык. Интерфейс на то и интерфейс, что задаёт контракт на этапе компиляции. Типы в рантайме в принципе не существуют, будучи абстракцией в мозгу программиста. Последнее — не мои слова, а Бьёрна Страуструпа.
Почитайте определение ЯП. Там нет ничего о том, что любая сущность обязана существовать в рантайме. C++ без RTTI помните?
Почитайте определение ЯП. Там нет ничего о том, что любая сущность обязана существовать в рантайме. C++ без RTTI помните?
раскрыть ветку (33)
мдя... Тогда зачем нужен оператор instanceof? В нормальных языках где он есть и есть интерфейсы, он проверяет принадлежность объекта некому типу интерфейсу или классу. Оператор теряет смысл если есть в языке интерфейс, но он не может на него проверить.
Это я к тому, что в JS нет интерфейсов, и TS никак их не создает. Оператор instanceof - это не TS, это JS, поэтому и не может сравнивать интерфейсы. А то, что ты привел пример new 1 - это нахрен никому не сдалось, а вот проверять принадлежность класса конкретному интерфесу - очень важная задача. Наприер
function test(a IFoo | IBar) {
if (a instanceof IFoo) {
}
}
C++ без RTTI помните?
я C/C++ только в универе на первом курсе чуть-чуть нюхал, так что его я не знаю
раскрыть ветку (32)
раскрыть ветку (31)
Просто ты не пользуешься оператором этим, вот и не видишь необходимость. Я часто на собесах слышал, что операторы побитовые не нужны и они в языках как архаизмы, мол, сейчас зачем побитовое ИЛИ в современных программах. Но вот сейчас примерно то же самое слышу и про instanceof.
Реальный пример:
class User extends AbstractEntity implements CanBreath, CanMove, CanSpeak {}
есть некая функция, которая принимает AbstractEntity и в зависимости от принадлежности сущности к какому-либо интерфейсу применяет соответствующие обработки
func process(AbstractEntity entity) {
if (entity instanceof CanMove) {
move(entity)
}
}
function move(CanMove entity) {
}
это язык с АТД. Мы не знаем какая реализация придет в эти функции, мы работаем только с представлениями (абстрактный класс или интерфейс).
раскрыть ветку (30)
это язык с АТДКакой это язык с алгебраическим типом данных? ActionScript не поддерживает АТД.
раскрыть ветку (3)
АТД я думал ты про Абстрактный Тип Данных. Ты же до этого говорил про абстракции.
https://ru.wikipedia.org/wiki/Абстрактный_тип_данных
а причем тут вообще алгебраический тип тогда?
раскрыть ветку (2)
Алгебраический тип позволяет вывести твой любимый instanceof из implicit операции в explicit, чтобы ты сам управлял признаком принадлежности значения к типу. instanceof в AC3, Java и подобных не бесплатен по памяти: каждый объект хранит метаинформацию о своём типе. С АТД этой информацией управляешь ты сам, затачивая типы под свои частные задачи.
Я не пользуюсь instanceof, потому что это такое же зло, как и typeof. Я знаю некоторые классические ООП языки без АТД. Ты же, очевидно, совсем не знаком с АТД. Даже если знаком, ты не дал шанса этой идее войти в твою голову. Заблокировал собственное восприятие, как утёнок.
В твоём примере ты принимаешь на вход AbstractEntity, который не имеет никакого отношения к упомянутым интерфейсам, но ты всё равно проводишь проверки типов в рантайме в надежде встретить там левый интерфейс. Это очень серьёзный звоночек.
Побитовые операции — это совершенно другой вопрос: нет пользы в отказе от них.
В твоём примере ты принимаешь на вход AbstractEntity, который не имеет никакого отношения к упомянутым интерфейсам, но ты всё равно проводишь проверки типов в рантайме в надежде встретить там левый интерфейс. Это очень серьёзный звоночек.
Побитовые операции — это совершенно другой вопрос: нет пользы в отказе от них.
раскрыть ветку (11)
Да, я с АТД не знаком и пока что не вижу зачем мне это знать. Я активно пользуюсь typeof и instanceof и не считаю это чем-то плохим.
Это очень серьёзный звоночек.
Только для тех, кто избегает возможностей языка) Ничего плохого в моем примере кода нет. Интерфейсы нужны для нескольких задач
1. определить публичный набор методов классса
2. определить класс к какой-то группе. При этом интерфейс может быть пустым.
То, что на вход в метод у меня общий абстрактный класс и то, что внутри я проверяю на принадлежность класса к какой-то группе - это нормально и не нарушает никаких принципов нормального проектирования систем.
Это как спор с поклонником ФП и противником ООП, не вижу смысла дальше продолжать :P Хорошего дня
раскрыть ветку (10)
А при чём тут ФП? Я не умею в ФП. Я умею только в ООП. Твой пример плох с точки зрения как раз ООП, потому что такая небрежная работа с типами сродни каста чего угодно к чему угодно. Многие в ООП воспринимают объект, как что-то магическое, позволяя себе везде передавать ничего не значащий базовый объект, проверяя потом его на принадлежность к любым классам или интерфейсам. Оператор instanceof из AC3 можно реализовать средствами TS. Из этой реализации будет очевидно, что это очередной typeof со свистелками. Не бесплатный, что важно. Средствами AC3 никак нельзя реализовать или имитировать статические алгебраические типы из TS, что какбэ намекает.
Ты только кандидату на собесе ничего такого про instanceof не говори: разочаруешь человека в компании навсегда. Модные молодёжные программисты всегда умнее предыдущего поколения. Ну, я про нормальных пацанов и девчонок, а не выпукников курсов.
Открой свой разум для АТД. Это сильно меняет представление о программировании и жизни. Делюсь с тобой не спора ради, а просветления для. Иду иногда по улице и думаю: «А ведь эти люди могли бы знать об АТД и быть чуть счастливее»
Хорошего дня.
Ты только кандидату на собесе ничего такого про instanceof не говори: разочаруешь человека в компании навсегда. Модные молодёжные программисты всегда умнее предыдущего поколения. Ну, я про нормальных пацанов и девчонок, а не выпукников курсов.
Открой свой разум для АТД. Это сильно меняет представление о программировании и жизни. Делюсь с тобой не спора ради, а просветления для. Иду иногда по улице и думаю: «А ведь эти люди могли бы знать об АТД и быть чуть счастливее»
Хорошего дня.
раскрыть ветку (9)
ФП я привел как пример бесполезного спора, конкретно к теме треда не относится.
Ты только кандидату на собесе ничего такого про instanceof не говори:
Спасибо за совет, но, к счастью, у меня своя голова и я считаю у меня достаточно опыта, чтобы выбирать как и что использовать в программировании. Я с тобой не согласен и мы не найдем общий язык. Мы бы не сработались вместе, поэтому все же я буду на собесах говорить про instanceof и отсеивать таких, как ты) Извини за прямоту
Это сильно меняет представление о программировании и жизни. Делюсь с тобой не спора ради, а просветления для.
Спасибо) Как минимум я запомню про такое понятие, как АТД. Мне менять представление о жизне и программировании не за чем. У меня в компании что в текущей, что в прошлой все работали без АТД и все понимали друг друга, строили хорошие системы (конечно не сразу, после кучи проб и ошибок). Поэтому АТД как бы хорошо ты не рекламировал, пока что выглядит просто очередным мнением как лучше строить системы... Таких мнений полно.
раскрыть ветку (8)
Мы с тобой бы отсеяли друг друга на собесе, однако я познал АТД, а ты — нет. В AS3 нет ничего прорывного по сравнению с Java и C++. Я не писал на AS3, но преимуществ в упор не вижу. Flash — просто окружение. Как можно быть фанатом окружения?
Возможно, я задел тебя своей категоричностью, называя хуёвыми вещи, которые имеют недостатки наряду с достоинствами. Извини, я подло сэкономил своё личное время.
Возможно, я задел тебя своей категоричностью, называя хуёвыми вещи, которые имеют недостатки наряду с достоинствами. Извини, я подло сэкономил своё личное время.
раскрыть ветку (6)
Ну, ты конечно крут что познал что-то хорошее, но ранее ты написал вот так
но я никому не навязываю своё мнение.
однако выглядит все так, что ты навязываешь )
AS3 был простой удобный язык. Мне нравилось на нем работать. Сейчас я активно работаю с TS, он мне тоже нравится, но это не язык, это все тот же JS, в котором нет OOП и в котором нормально применять typeof и eval и многие другие вещи, от которых некоторые разработчики в писают в штаны от ужаса, когда слышат :D А в AS3 был полноценный ооп и дерьма в нем почти не было. Да и сравнивать его с C++ и Java неверно, его лучше сравнивать с JS, так как они оба на ECMA стандартах, но при этом AS3 был почти полноценным языком со всеми прелестями.
раскрыть ветку (5)
раскрыть ветку (4)
раскрыть ветку (3)
Разочарование. Я зря понадеялся на твоё уважение к собеседнику: риторический вопрос не требует ответа. Я не глупее тебя. Я знаю, как завершается фраза.
раскрыть ветку (2)
раскрыть ветку (1)
Сорян, не догнал про твои добрые намерения. Я просто так устал от одинаковых ответов на Пикабу, что оставляю только упоминания мемов.
Я отпишу тебе по коду чуть позже, чтобы у тебя тоже была возможность критиковать меня по фактам. Иначе нечестно получается.
Я отпишу тебе по коду чуть позже, чтобы у тебя тоже была возможность критиковать меня по фактам. Иначе нечестно получается.
Хотя знаешь, нет. Я бы тебя не отсеял на собесе. Я бы тебя принял и показал АТД. Да.
Я считаю, что окружать себя людьми только своего мнения — удел слабых. Хочешь работать у нас и хорошо знаешь ООП — клёво, а мы тебя ещё научим АТД.
Я считаю, что окружать себя людьми только своего мнения — удел слабых. Хочешь работать у нас и хорошо знаешь ООП — клёво, а мы тебя ещё научим АТД.
Вот код, как и обещал. Можно написать короче, но старался писать на TS так, чтобы это было максимально близко к ActionScript 3 или любому другому языку с ООП и интерфейсами.
Ссылка: short тут ничего, просто слитно url точка at слеш asIJV.
раскрыть ветку (13)
раскрыть ветку (12)
раскрыть ветку (11)
спасибо) Если честно, мне такой способ не нравится. Во-первых композиция лишает возможности управлять объектом User, и по сути делегирует на другой класс задачу, а это не всегда удобно и создает кучу бойлерплейта, чтобы передавать состояние. Во-вторых если будет не 3 интерфейса, а 10, то чтобы их в разных композициях иметь потребуется создать уйму классов типа Being с разным набором геттеров. Либо ты предлагаешь один такой класс с кучей геттеров для всех интерфейсов, и если нет реализации, то просто null возвращать? Если так, то это совсем ахтунг будет, так у классов будут методы, которые ему не нужны.
раскрыть ветку (10)
Почти все проблемы, что ты описал, решаются inline типами (inline class, inline type). Подклассы могут управлять состоянием класса, их содержащего, и даже иметь доступ к его приватным полям, если будут объявлены в теле этого класса. Хотя даже наличие как таковых классов не обязательно, потому что любой объект может удовлетворить интерфейс при правильной типизации. Вместо геттеров с `null` можно решить проблему простым отсутствием значения через объявление поля `some?: Some`, но я тебя предупредил, что решаю проблему инструментами, близкими к AS3.
Да, типы всегда увеличивают объём кода. Однако, они в разы улучшают качество кода, которое особенно важно при активной командной разработке. Короткий код не есть хороший код в общем случае.
раскрыть ветку (7)
Как раз моя команда бы наоборот сказала, что код усложнился на ровном месте и нарушает прицип KISS. Если нет возможности instnaceof для интерфейса применять, как это можно много где (php, java, as и прочие языки, где есть интерфейсы и instanceof), то смысла выручиться так нет, только все усложнится. В js нет интерфейсов, а TypeScript всего лишь сахар для JS, поэтому в TS интерфейсы не применить, как в полноценных языках, увы.
раскрыть ветку (6)
Так ведь ровно наоборот, повторюсь, на TS можно описать instanceof из AS3, а на AS3 нельзя сделать почти ничего из TS. Пересмотри своё понимание полноценности.
Я тебе привёл объективную причину, почему твой код надо переписать. Был бы другой код — был бы другой разговор.
Я тебе привёл объективную причину, почему твой код надо переписать. Был бы другой код — был бы другой разговор.
раскрыть ветку (5)
сорри, я так и не понял как ты описал instanceof, ты предложил просто замену простой композицией, которая раздувает код в данном случае. И не нужно все так сравнивать с AS3, сравни с java и php, там instanceof отлично интерфейсы проверяет. Проблему с интерфейсами и instanceof я не приводил как сравнение с AS3, а это был ответ на твое утверждение, что TS - это язык программирования #comment_238610662
Я тебе привёл объективную причину, почему твой код надо переписать
имхо, субъективную. Мой код, даже тот для примера, особо не вызывает проблем. Он не нарушает никакого принципа в современных подходах в программировании ООП, не создает проблем в будущем и использует то, что дает ООП - интерфейсы.
раскрыть ветку (4)
Я не описывал instanceof в своём примере. Я обошёлся без него классическим ООП. Я могу описать аналог твоего кода на TS с instanceof Interface, который ты так любишь, но не хочу и неоднократно заявлял, что так нельзя делать. TS умеет проверять интерфейсы. Он умеет в рантайме проверять что угодно, сохраняя при этом преимущества АТД, но не надо так делать.
Твой код плох, потому что нельзя только по сигнатуре функции понять, что ей нужно подать на вход и что она мутирует.
Кроме всего прочего, твой код нарушает принцип D из SOLID: нельзя строить зависимости на реализациях, можно только на абстракциях, то есть хотя бы на интерфейсах. Твой process зависит от AbstractEntity, то есть от класса, то есть от реализации.
раскрыть ветку (2)
AbstractEntity - это не реализация все же) Это такой же интерфейс, на то он и abstract . или ты скажешь абстрактные классы использовать нельзя , потому что SOLID?)))
В любом случае как ранее писал, это такой же бессмысленный спор, как и со сторонниками ФП. Поэтому нам особо смысла нет автора поста тревожить нашими комментами) Давай в другом посте где-нибудь на другую тему продолжим, а пока что пусть все останутся при своем мнении)
раскрыть ветку (1)
При условии единственности родительского класса, AbstractEntity — вполне себе реализация вне зависимости от слова abstract. Есть языки, где вместо интерфейсов используются виртуальные классы, но это не AS3 и TS.
Самое главное забыл сказать, коллега. К твоему коду у меня была одна главная претензия: отсутствие контракта в сигнатуре функции process. Туда можно было любую хрень передать, а узнать, что же она ждёт на самом деле, можно было только прочитав её реализацию. Это неправильно. В идеале любая реализация при достаточной компетенции разработчика пишется лишь один раз и никогда не читается: пользователи функционала читают только сигнатуры. Чёрные ящики -- это хорошо. Вне зависимости от общественного мнения или мнения каких-то отдельных людей, разработчики хотят работать с чёрными ящиками. И они должны, чтобы быть продуктивными. Отсутствие комментариев в коде -- признак выразительности языка программирования и хорошего кода.
раскрыть ветку (1)
тот код я привел как пример проблемы.. В реалии метод process был бы с другой сигнатурой, понятной и однозначной.
раскрыть ветку (5)
Ок, уязвимости были, как собственно везде они есть. Но это не мешало флешу (flex, air) быть отличным популярным (при наличии конкуренции) инструментом и не отменяет того, что AS3 был классным языком (по сравнению с JS) :P Мне флеш запомнился только хорошим, так что не буду позволять "переписывать историю", как это модно сейчас говорить, и всем внушать, что он был "хуевым" :D
раскрыть ветку (4)
Нет, не везде. Столько дыр, сколько в продуктах Адобе, не было нигде) Конкуренция какая? Сильверлайт, который был еще дерьмовей?)
JS норм, если Тайпскрипт брать, а не оригинал.
раскрыть ветку (3)
js норм конечно, но AS3 круче :P Заявляю как разработчик и JS, и AS3. Но все вкусовщина, а ней не спорят, кому-то действительно flash и as не нравился
Столько дыр, сколько в продуктах Адобе, не было нигде)
видимо про IE вы ничего не слышали...
раскрыть ветку (2)
Слышал. Только там один IE. При чем проблема была с ним не в количестве багов, а в том, что юзеры его не обновляли. У Адобе же критические уязвимости находились постоянно, по несколько штук за год. При том не только во Флеше, но и во всех возможных плагинах типа Акробата.
Если взять любую связку эксплоитов начала 10-х годов, там будет 1-2 устаревших эксплоита для IE, пара для Явы и штук 10 для продукции Адоба, из которых пара будет вполне свежих 1-day)
раскрыть ветку (1)
тем не менее уязвимости не повод считать продукт говном, имхо. Если бы были кучу багов - да, глюков, неудобств и тд - это повод. Мне как и разработчику, и как пользователю флеш (и air) очень нравились.
Как уже выше написал - это было удобно и просто. Сейчас на js сложнее делать многие фичи, которые на flash в три клика делалсиь
IT-юмор
7.5K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору