- 1
- 2
- facade.registerCommand(<enterprise>Constants.CUT_PUST_TRACKS_COMMAND, CutPustTracksCommand);
+ facade.registerCommand(<enterprise>Constants.CUT_PUST_TRACKS_COMMAND, CutPasteTracksCommand);-
ActionScript / Говнокод #17295
−93
Ну, почти.
Запостил:
wvxvw,
11 Декабря 2014
Follow us!
Последнее время при виде мвц фреймворков меня начинает колбасить. Такая штука чтобы отключить мозг и срать кодом.
пс, разглядела константу
Это зеленный или я что то пропустил.
ЗЫ сейчас работаю над проектом. в нем кстати нет не одного сингелтона, конфиг к примеру выгружается из бД каждый раз когда нужно чего нить в нем узнать. причем каждый раз когда это нужно есть конечно местами обходные маневры типа funct($config) или global $config но это редкость. Когда я спросил у автора, что за нех? он ответил пока работает ничего менять не буду.
Проект на PHP?
В php синглтоны настолько одиноки, что умирают от одиночества по окончании обработки запроса.
А по поводу фасада - в этом проекте много смешного. Фасад - это как бы не обязательно синглтон, но для начинающих удобнее думать о программе как просто о большом списке задач, которые нужно как-то решить, и строительные блоки-классы используются поэтому не по назначению, а просто для того, чтобы разбить эти задачи на части. При этом классы теряют смысл как классы. Т.е. это не фасад, так как он задумывался, а просто "то место, куда складывается весь код, который выполняется при инициализации приложения. Естесственно, при таком подходе фасадов не может быть два - во втором просто нечего делать будет.
Еще из смешных вещей. Вот не знаю, откуда оригинальные афторы почерпнули:
Т.е. задумка-то была сделать так, чтобы можно было заменить один медиатор другим, чтобы не создавать зависимости. Но дурак с иконой...
это тот же jQuery...
Насчет синглтонов: пусть у нас будут фабрики, и пофигу, синглтон отдается или у нас там пул
Начнет творить чудеса, если foo() поменяет что-то у одного из объектов, но на второй вызов getInstance() нам дадут не поменяный, а новый.
Рамки - это же не цель, и даже не инструмент. Вот тот же всем надоевший MVC - его нельзя получить из ограничений. Его можно только сконструировать, и фреймворк тут не помощник. Перефразируя: нет возможности создать такой фреймворк, который бы гарантировал, что при его использовании в приложении появится MVC. Вотличие, например, от возможности создать библиотеку для операций с разными типами данных, врезультате использования в которой обязательно в приложении будут использованы операции над типами данных.
Это довольно странно. А если я буду использовать эту библиотеку из машинного кода - в машинном коде появятся операции с различными типами данных и сами типы данных?
Использование процессора накладывает на меня определенные ограничения: я могу пользоваться лишь тем, что представляет ассемблер этого процессора, потому использование процессора не всегда является благом.
Использование одежды накладывает на меня определенные ограничения: например я не могу помочиться когда захочу: для этого мне нужно снять трусы, так что одежду нельзя использовать без ограничений
Именно так, и поэтому существуют програмы, которые не пользуются операционной системой.
> Использование процессора накладывает на меня определенные ограничения
Нет, не накладывает ограничения (т.как не известно, что такое процессор). Но если говорить о конкретном процессоре, или типе процессоров - то, конечно накладывает, именно поэтому есть програмы которые не работают на всех процессорах.
То же самое по поводу одежды. (Но пример херовый, т.как одежда не мешает мочиться когда хочется, мешает система правил принятая в обществе).
Естесственно так же, что ограничения могут ограничивать в разной степени. Например, ограничение, что на ноль делить нельзя очень слабо оганичивает деление в поле. В группе целых деление более ограничено, и можно найти такие множества, где деление вообще неприменимо.
Как и во всех примерах выше, нужно так же понимать разницу между определением, конкретными явлениями, и контекстами в которых они рассматриваются. Например, таже конкретная операционная система может рассматриваться в двух контекстах: как набор ограничений, и как набор утилит. Естесственно, во втором контексте глупо говорить об ограничениях. Точно так же и с фреймворками: конкретные фреймворки могут содержать утилиты, о которых нельзя сказать, что они в чем-то ограничивают, т.как контекст будет выбран неправильно.
Но речь не о конкретных фреймворках (тут ни один не упоминался), а о том, что под собой подразумевает это понятие. А так же об обычной ошибке, когда набор правил пытаются реализовать как набор утилит (MVC - это набор требований к системе вобщем, который не получится удовлетворить добавляя части к системе, если какие-то другие ее части этому требованию уже не удовлетворяют).
> Процессор может быть абстракцией..
Когда на этом сайте употребляется слово процессор, то имеется ввиду конкретное устройство, установленное в гнездо процессора на материнской плате. Какие еще абстракции, зачем тут все эти темы, я не могу понять, почему Вы вечно наравите от коекретики перейти к каким то абстрациям, говоря о том, что никто ничего не понимает кроме Вас, делая это в тех местах где это вообще не нужно.
Может тогда будем вести все разговоры оперируя только абстрациями? Простите конечно, но Вы какой то философией занимаетесь.
> И в чем противоречие?
> framework - рамка, ограничение
> slovari.yandex.ru/framework/en-ru/ -> framework - каркас, скелет
Просто Вы так говорите, как будто люди специально занимаются тем, что придумывают ограничения для себя, но ведь фреймворки делаются не ради ограничений, а ради предоставления определенного функционала, ограничения появляются как следствие. Использование фреймворка, есть использование того функционала, который был заложен в этот фреймворк, ведь он не может содеражать все на свете и на все случаи жизни, отсюда и ограничения, плюс сама реализация этого функционала так же накладывает ограничения, ведь могут не все учесть при реализации.
Смылс фреймворка в добавлении правил, это эквивалентно более строгому ограничению. А вот представьте, есть такой язык Пролог, например, и в нем все - правила. Т.е. что-бы ни написали на прологе - все ограничивает, и как так жить?
Почему люди придумывают себе ограничения - вот это интересный вопрос, но на него есть ответ! Это следствие frame problem! Которая, если по-простому, говорит нам о том, что мир бесконечен, возможности бесконечны, и если мы их постараемся победить дедукцией, то мы никогда не сдвинемся с мертвой точки, потому, что дедукция работает только в мирах Хербранда, т.е. в конечных мирах.
А люди-то как с этим справляются? - Правильно, ограничивают себя, создают конечные модели, которые позволяют к ним применить дедукцию, чтобы получить какие-то универсальные знания о мире.
А еще с ограничениями связано много парадоксов, в том числе и в информатике, вот, например, Буриданов осел: чем больше осел знал о двух разных копнах сена, тем сложнее ему было выбрать лучшую копну.
Вы же доказывали что типов не существует, они уже появились?
Кроме того, типы данных и програмные типы - это совсем разные вещи, которые описывают разные аспекты програм. Первые описывают сложность операций с данными, а вторые - правила логики первого порядка доказывающие возможность композиции функций.
Сложность? А может все таки они показывают объем памяти, выделяемый под хранение этого типа данных в ОЗУ? Другими словами говорят о том, как представляются эти данные в памяти.
Более обобщенно, это нарушение (или соблюдение) правила субструктурной логики (логики не соблюдающей всех требований классической логики), а именно обмена (пермутации).