Почему вы думаете, что пришельцы поймут вашу математику? А вдруг у них совершенно другой способ мышления?
Читал когда-то какую-то фантастическую книжку. Там в одном месте говорится, что в качестве общепринятого символа развитых цивилизаций используется графическое изображение теоремы Пифагора (то, которое «пифагоровы штаны»). Потому что геометрия на всех планетах одинаковая, а знание этой закономерности означает, что цивилизация уже вышла из первобытного состояния, и ее представители имеют некоторое абстрактное мышление и занимаются наукой. По-моему, это выглядит довольно логично.
Если кому-то надо похранить удаленные записи недельку-месяц, это явно не проблема фреймворка) Надо — делайте.
Во-вторых, это заставляет вызывающий код знать детали реализации. Да и претензия моя, собственно, не в этом, а в том, что метод all() возвращает не all(). А это, в свою очередь, заставляет программиста знать детали реализации. И это уже сложнее.
Во-первых. Это тогда не Yii2 bad behaviors, так как используемый фреймворк тут ни при чем.
Во-вторых. Если запись не удаляется из базы, значит она зачем-то нужна. Если нужна, значит где-то есть метод view или list, который такие записи получает. Если получает, значит вызывает метод findOne() или findAll() в каком-то виде. Значит переопределять их нежелательно, так как придется вводить флаг типа reallyShowAll и добавлять условие where в функцию all(). Понятно, что это все будет работать, просто код будет непонятный. Вызываем all(), а возвращается не all().
Удаление потом это неплохо, но если в базе есть удаленные и неудаленные записи, то в коде для них нужны отдельные вызовы функций. О чем я и пытаюсь сказать.
В-третьих. Если так переопределить findOne(), то восстановить удаленный коммент будет нельзя, так как вызов вернет null.
Допустим, когда-то у нас был товар «Супер-отмычка», с id=123. Сейчас он удален. У нас есть сотня выполненных заказов по этому товару, поэтому физически удалить его из базы мы не можем, хотя новые заказы мы на него не принимаем. Пользователь хочет посмотреть параметры своего заказа полугодовой давности. Пользователь открывает страницу «order/view?id=456». В заказе, в числе прочих, есть товар с id=123. По-вашему, метод findOne() должен вернуть null, а пользователь в строчке с товаром должен получить сообщение «Not found»?
Хм. Ну вообще я предлагаю в 99% случаев писать «Comment::findActive()» без всяких дополнительных стрелочек.
Про findOne().
Допустим, когда-то у нас был тариф «Супер», с id=123. Сейчас он неактивен. У нас есть сотня заказов по этому тарифу. Мы хотим посмотреть его параметры. Открываем страницу «tariff/view?id=123». По-вашему, метод findOne() должен вернуть null, а мы должны получить сообщение «Not found»?
о чем я, собственно, и говорил. Если нам нужны только активные записи, мы должны это явно указать, а не переопределять метод «все()», чтобы он возвращал не все.
А если вы приняли выражение «какой-то программист» на свой счет — что ж, значит я попал в точку. Не делайте так, это непонятно.
вы расчитываете на то, что они не будут подтягиваться в результаты любых ваших запросов: Cat::find()->all()
Ну здрасьте приехали. Если я хочу найти все записи, то ожидаю, что «find all» найдет мне все записи. Если мне надо найти только активные записи, то я сделаю метод findActive(), который будет их возвращать.
А если какой-то программист навесит на all() дополнительную логику, то надо доходчиво объяснить ему, что так делать не надо. Или, например, забрать у него проект, а потом через полгода отдать ему же обратно на длительную поддержку.
Вот чувствую провокацию на холивар, но, пожалуй, отвечу.
А если серьезно — я правда не понимаю всю суету по поводу этой темы: почему вдруг операторы ЭВМ стали настолько важными?
Я вот тоже не понимаю.
Почему ученые, совершающие открытия, стали настолько важными — это же просто ботаны или школьные учителя.
Почему настолько важны нейрохирурги — это же просто медсестры и медбратья.
Почему экономисты настолько важны — это же просто продавцы.
Почему спецназ настолько важен — это же просто солдаты.
А если серьезно.
Программисты анализируют информацию. Предметную область. Выявляют ее законы и связи. И самое главное — могут объяснить это машине. Это требует правильного понимания этой предметной области, и во многом граничит с искусством. Понял правильно и сделал правильно — проблем мало. Понял неправильно или сделал неправильно — проблем много. Особенно при внесении изменений.
Такая способность к аналитике проецируется и на остальные предметные области, которые окружают программистов. И поэтому многие программисты считают себя более умными, чем остальные. И во многих случаях это действительно так. Однако, не стоит забывать, что анализ данных основывается на знаниях о данных, но не факт, что эти знания правильные.
Из этого следует, что основная ценность программистов заключается в понимании предметной области. А если программист быстро вникает в предметную область и может сказать, как можно решить проблему — это хороший программист.
С точки зрения бизнеса — программист экономит деньги. То, что раньше делали 10 бумагоперекладывателей, может делать один компьютер. Соответственно, можно найти грамотного специалиста по компьютерам, заплатить ему 2 зарплаты и сэкономить на 8. Отсюда уровень зарплат в этой области. Хотя, конечно, в целом все сложнее.
Это, как мне кажется, полная чушь, придуманная неграмотными фантастами. Показательный пример был в фильме «Чаппи». Вот представьте, лежите вы в лаборатории, и рядом с вами ваш информационный и генетический клон. Если вы порежете палец, больно будет вам. Если в вас выстрелят, исчезнете вы и ваша информационная составляющая. А не клон.
В принципе, во многих играх используется такая механика, когда на последнем дыхании персонаж сражается яростнее
Встречал такое в игре «Проклятые земли 2», очень разочаровало. Там по сюжету полная фигня получилась. Всю игру выбираешь тактику, навыки, которые надо качать, а в конце у него умирает подружка, и у героя из-за ярости половина навыков в 2 раза увеличивается просто так. Неинтересно это.
Почитал описание — чушь собачья, как говорится. Первый момент привыкания к игре — привыкание к физике, которую придумали авторы. Когда придумают нейроинтерфейсы, которые будут обрабатывать движения персонажа на основе развития мышц игрока, тогда может это и будет иметь смысл. Сейчас нет.
Вероятность «раз в миллион лет» говорит о том, что за миллион лет событие скорее всего произойдет хотя бы один раз. Но она ничего не говорит о том, в какой день это событие произойдет. Оно может произойти в любой день, например, в первый.
Логика, верстка, и работа с БД в одном файле. В PHP за такое давно по рукам бьют.
event(logout) ->
wf:user(undefined)
...
buttons() ->
case wf:user() of
undefined
Я ошибаюсь, или это обычное императивное программирование с изменением переменной?
Еще раз отмечу, что kvs плохо подходит для постраничной навигации, и этот код просто демонстрация того, как применения несоответствующих инструментов приводит к запутыванию кода
А как все-таки сделать правильно, чтобы код не был запутанным? Спрашиваю не с целью потроллить, мне правда интересно
Давайте рассмотрим пример. Прямоугольник — плоская фигура с четырьмя прямыми углами. У него есть ширина (width) и высота (height)
Как-то раз я задумался над этим примером, после того, как прочитал его бурное обсуждение в комментах к этой статье.
Начнем с того, что двумя числами можно в общем случае задать только попарные длины отрезков, но неверно, что 4 отрезка всегда образуют прямоугольник. Если мы договорились, что у нас всегда из них получается прямоугольник, мы уже задали некоторые начальные предусловия. В такой реализации у квадрата более сильные предусловия — добавляется условие, что длины всех отрезков должны быть равны. В реализации, когда задаются длины сторон и можно изменять стороны после создания, наследование использовать нельзя.
Кстати, обычно как-то обходится стороной то, что если задать прямоугольнику одинаковую ширину и высоту, то фактически он будет квадратом, но в программе он останется прямоугольником. Если бы у нас была возможность изменить тип объекта после изменения параметров, то наследовать было бы можно. Присвоили значения width = 10, height = 10 — тип rect изменился с Rectangle на Square. Насколько это хорошо для разработки — это отдельный вопрос.
А почему мы решили, что у прямоугольника можно просто так изменять стороны? Если мы его поменяем, то это уже будет другая фигура — может прямоугольник, может квадрат. Если размеры сторон задаются только при создании, то нет особых проблем, чтобы унаследовать квадрат от прямоугольника, если это зачем-нибудь требуется. Хотя, возможно, тут я не прав.
А почему мы решили, что прямоугольник можно задавать 2 сторонами? Прямоугольник на плоскости не задается 2 сторонами, он задается 4 точками. Как и квадрат. Кроме того, это математический объект, и мы можем его только задать. Если мы его поменяем, то значит мы задали другую фигуру — может квадрат, может ромб, может просто какой-то четырехугольник. С этой точки зрения, прямоугольник и квадрат должны иметь конструкторы с одинаковым числом параметров — координаты 4 точек. При создании должно появляться исключение, если точки не образуют соответствующую фигуру. В этом случае с наследованием проблем нет.
В статье имеется уклон в сторону «используйте нативный javascript». Выскажу мнение со своей колокольни. Я ни в коем случае не против знания чистого javascipt, просто как-то так получается, что в основном занимаюсь проектами, где уже используется jquery.
Можно легко заменить селектор типа $('div, span, article'); на document.querySelectorAll('div, span, article');
И заменить 1 символ на 25. На главной Хабра обращение к $ встречается 44 раза. А сколько будет в подключаемых скриптах?
Сделать функцию-обертку? Идем дальше.
$('button').bind('click', function(e){});
$('button').bind('click', function(e){});
// 41 байт
console.log(document.querySelectorAll('button').forEach)
// undefined
// хм
// можно сделать так (83 байт)
for(var v of document.querySelectorAll('button')) {
v.onclick = function() {}
}
// или так (144 байт)
nodes = Array.prototype.slice.call(document.querySelectorAll('button'), 0);
nodes.forEach(function(v, i) {
v.onclick = function() {}
});
// или с оберткой в виде функции $ (73 байта)
$('button').forEach(function(v, i) {
v.onclick = function() {}
});
«Зачем нам нужно так усложнять себе жизнь?»
И так, иногда обертка, иногда нет, а иногда специальная обертка
Последнее особенно весело, если кто-то так назначил обработчик где-нибудь в main.js и не проверил на null, при этом unknown_id является known на 99% страниц, а unknown он только на некоторых и при определенных условиях.
Да, еще при изменении селектора с «id» на «class» мне надо не забыть поменять нативную функцию.
Я видел кучу больших проектов которые превращались в одно большое блюдо спагетти на клиентской стороне
Здесь полностью согласен, такое бывает. Но для проектов среднего уровня, где не требуется серьезная работа с фронтендом, jQuery неплохой выбор.
Это аналог книжного шифра, только в книжном шифре одна книга и разные координаты букв в сообщении, а у вас много книг и одна и та же координата. Книга в данном случае — это одна фотография кота. Вернее, коты здесь даже ни при чем, книга — это хеш передаваемого файла, а сама фотография — просто протокол передачи. Соответственно, все достоинства и недостатки книжного шифра имеют место быть.
Читал когда-то какую-то фантастическую книжку. Там в одном месте говорится, что в качестве общепринятого символа развитых цивилизаций используется графическое изображение теоремы Пифагора (то, которое «пифагоровы штаны»). Потому что геометрия на всех планетах одинаковая, а знание этой закономерности означает, что цивилизация уже вышла из первобытного состояния, и ее представители имеют некоторое абстрактное мышление и занимаются наукой. По-моему, это выглядит довольно логично.
Во-вторых, это заставляет вызывающий код знать детали реализации. Да и претензия моя, собственно, не в этом, а в том, что метод all() возвращает не all(). А это, в свою очередь, заставляет программиста знать детали реализации. И это уже сложнее.
Во-первых. Это тогда не Yii2 bad behaviors, так как используемый фреймворк тут ни при чем.
Во-вторых. Если запись не удаляется из базы, значит она зачем-то нужна. Если нужна, значит где-то есть метод view или list, который такие записи получает. Если получает, значит вызывает метод findOne() или findAll() в каком-то виде. Значит переопределять их нежелательно, так как придется вводить флаг типа reallyShowAll и добавлять условие where в функцию all(). Понятно, что это все будет работать, просто код будет непонятный. Вызываем all(), а возвращается не all().
Удаление потом это неплохо, но если в базе есть удаленные и неудаленные записи, то в коде для них нужны отдельные вызовы функций. О чем я и пытаюсь сказать.
В-третьих. Если так переопределить findOne(), то восстановить удаленный коммент будет нельзя, так как вызов вернет null.
Допустим, когда-то у нас был товар «Супер-отмычка», с id=123. Сейчас он удален. У нас есть сотня выполненных заказов по этому товару, поэтому физически удалить его из базы мы не можем, хотя новые заказы мы на него не принимаем. Пользователь хочет посмотреть параметры своего заказа полугодовой давности. Пользователь открывает страницу «order/view?id=456». В заказе, в числе прочих, есть товар с id=123. По-вашему, метод findOne() должен вернуть null, а пользователь в строчке с товаром должен получить сообщение «Not found»?
Про findOne().
Допустим, когда-то у нас был тариф «Супер», с id=123. Сейчас он неактивен. У нас есть сотня заказов по этому тарифу. Мы хотим посмотреть его параметры. Открываем страницу «tariff/view?id=123». По-вашему, метод findOne() должен вернуть null, а мы должны получить сообщение «Not found»?
о чем я, собственно, и говорил. Если нам нужны только активные записи, мы должны это явно указать, а не переопределять метод «все()», чтобы он возвращал не все.
А если вы приняли выражение «какой-то программист» на свой счет — что ж, значит я попал в точку. Не делайте так, это непонятно.
Ну здрасьте приехали. Если я хочу найти все записи, то ожидаю, что «find all» найдет мне все записи. Если мне надо найти только активные записи, то я сделаю метод findActive(), который будет их возвращать.
А если какой-то программист навесит на all() дополнительную логику, то надо доходчиво объяснить ему, что так делать не надо. Или, например, забрать у него проект, а потом через полгода отдать ему же обратно на длительную поддержку.
Я вот тоже не понимаю.
Почему ученые, совершающие открытия, стали настолько важными — это же просто ботаны или школьные учителя.
Почему настолько важны нейрохирурги — это же просто медсестры и медбратья.
Почему экономисты настолько важны — это же просто продавцы.
Почему спецназ настолько важен — это же просто солдаты.
А если серьезно.
Программисты анализируют информацию. Предметную область. Выявляют ее законы и связи. И самое главное — могут объяснить это машине. Это требует правильного понимания этой предметной области, и во многом граничит с искусством. Понял правильно и сделал правильно — проблем мало. Понял неправильно или сделал неправильно — проблем много. Особенно при внесении изменений.
Такая способность к аналитике проецируется и на остальные предметные области, которые окружают программистов. И поэтому многие программисты считают себя более умными, чем остальные. И во многих случаях это действительно так. Однако, не стоит забывать, что анализ данных основывается на знаниях о данных, но не факт, что эти знания правильные.
Из этого следует, что основная ценность программистов заключается в понимании предметной области. А если программист быстро вникает в предметную область и может сказать, как можно решить проблему — это хороший программист.
С точки зрения бизнеса — программист экономит деньги. То, что раньше делали 10 бумагоперекладывателей, может делать один компьютер. Соответственно, можно найти грамотного специалиста по компьютерам, заплатить ему 2 зарплаты и сэкономить на 8. Отсюда уровень зарплат в этой области. Хотя, конечно, в целом все сложнее.
Встречал такое в игре «Проклятые земли 2», очень разочаровало. Там по сюжету полная фигня получилась. Всю игру выбираешь тактику, навыки, которые надо качать, а в конце у него умирает подружка, и у героя из-за ярости половина навыков в 2 раза увеличивается просто так. Неинтересно это.
Я ошибаюсь, или это обычное императивное программирование с изменением переменной?
А как все-таки сделать правильно, чтобы код не был запутанным? Спрашиваю не с целью потроллить, мне правда интересно
Как-то раз я задумался над этим примером, после того, как прочитал его бурное обсуждение в комментах к этой статье.
Начнем с того, что двумя числами можно в общем случае задать только попарные длины отрезков, но неверно, что 4 отрезка всегда образуют прямоугольник. Если мы договорились, что у нас всегда из них получается прямоугольник, мы уже задали некоторые начальные предусловия. В такой реализации у квадрата более сильные предусловия — добавляется условие, что длины всех отрезков должны быть равны. В реализации, когда задаются длины сторон и можно изменять стороны после создания, наследование использовать нельзя.
Кстати, обычно как-то обходится стороной то, что если задать прямоугольнику одинаковую ширину и высоту, то фактически он будет квадратом, но в программе он останется прямоугольником. Если бы у нас была возможность изменить тип объекта после изменения параметров, то наследовать было бы можно. Присвоили значения width = 10, height = 10 — тип rect изменился с Rectangle на Square. Насколько это хорошо для разработки — это отдельный вопрос.
А почему мы решили, что у прямоугольника можно просто так изменять стороны? Если мы его поменяем, то это уже будет другая фигура — может прямоугольник, может квадрат. Если размеры сторон задаются только при создании, то нет особых проблем, чтобы унаследовать квадрат от прямоугольника, если это зачем-нибудь требуется. Хотя, возможно, тут я не прав.
А почему мы решили, что прямоугольник можно задавать 2 сторонами? Прямоугольник на плоскости не задается 2 сторонами, он задается 4 точками. Как и квадрат. Кроме того, это математический объект, и мы можем его только задать. Если мы его поменяем, то значит мы задали другую фигуру — может квадрат, может ромб, может просто какой-то четырехугольник. С этой точки зрения, прямоугольник и квадрат должны иметь конструкторы с одинаковым числом параметров — координаты 4 точек. При создании должно появляться исключение, если точки не образуют соответствующую фигуру. В этом случае с наследованием проблем нет.
И заменить 1 символ на 25. На главной Хабра обращение к $ встречается 44 раза. А сколько будет в подключаемых скриптах?
Сделать функцию-обертку? Идем дальше.
«Зачем нам нужно так усложнять себе жизнь?»
Последнее особенно весело, если кто-то так назначил обработчик где-нибудь в main.js и не проверил на null, при этом unknown_id является known на 99% страниц, а unknown он только на некоторых и при определенных условиях.
Да, еще при изменении селектора с «id» на «class» мне надо не забыть поменять нативную функцию.
Здесь полностью согласен, такое бывает. Но для проектов среднего уровня, где не требуется серьезная работа с фронтендом, jQuery неплохой выбор.