Мне кажется, считать адрес объектом-значением можно, если он нужен только для информации и выводится один раз где-нибудь в профиле пользователя, а реальность адреса не имеет значения. Но фактически это самостоятельная сущность, никак не связанная с пользователем, и она может изменяться. Например, переименование улицы. Местоположение на карте осталось то же самое, этажность и номер дома те же, люди и организации из этого дома никуда не переехали, а текстовое представление адреса изменилось. Это аналогично изменению фамилии у человека.
С адресом плохой пример. Дом снесли — адрес исчез, ну или «стал неактивен». А например цифру 2 отменить нельзя. Кроме того, у человека или организации может быть несколько адресов.
Простите, а причем здесь программирование? Вы предлагаете ввести изучение 3D, при этом на вопрос «зачем?» начинаете уходить от ответа и тыкать пальцем в другие предметы. Я вот считаю, что в школе и без того слишком много информации, которую нужно изучить, особенно в старших классах. И для введения дополнительных предметов нужны очень веские причины. А у вас в разделе «Зачем» только домыслы в стиле «я так хочу». Так что присоединяюсь к вопросу — зачем это надо, что это дает?
Не с каждой программой так получится. В Windows 7 немного другая структура взаимодействия DLL, или что-то в этом роде. Пробовал так перенести на XP игру в шахматы Chess Titans, не получилось.
Начало вроде нормальное, но потом куда-то не в ту степь. Ни разу не сталкивался, чтобы под full-stack разработчиком понимали специалиста с доскональным знанием технологий от ассемблера до фотошопа и менеджмента. Обычно имеется в виду конкретный стек (например, веб), и специалист на все руки, который знает всего понемногу (PHP и верстку) на нормальном уровне, чтобы не нанимать 2 или 3 разных специалистов.
Люди, которые «знают всё» на профессиональном уровне, тоже бывают, но я бы не стал называть full-stack разработчиками только их.
Обработка данных не происходит мгновенно. Между вводом данных и выводом результата всегда проходит какое-то время.
Обработка данных не происходит сама по себе. Для получения результата из входных данных нужно совершить некоторые действия.
Соответственно, некоторые действия будут выполнены раньше по времени, некоторые позже.
Описание может быть декларативным, выполнение — нет.
В аналоговых устройствах тоже есть задержка на распространение и преобразование сигнала. Если взять 2 рации, то звук из второй появится не одновременно с тем, как мы скажем что-то в первую. При проектировании устройств учитывается направление и движение тока.
У нас был Turbo-Prolog, в нем можно было включить пошаговый trace режим. Помнится, это сильно помогло мне разобраться в его работе. Не сказал бы, что совсем все по-другому, все сводится к последовательному перебору вариантов и возможных веток.
Скрытый текст
У меня была такая история с лабораторкой.
Нужно было выбрать тему, я выбрал игровые алгоритмы. Хотел написать игру в дурака. И написал, с графическим режимом, с управлением через клавиатуру. Первая сложность была хранить номер текущей выделенной карты. Делать UI на прологе — то еще удовольствие.
Преподаватель оказался странный, с первого раза никогда не принимал. Отправил меня обратно, сказал добавить на каждом шаге вывод процесса принятия решения в текстовом виде, причем обязательно на русском, так как английский он не знал. Программа keyrus в BGI-графике не работала; функций для работы с двоичными данными, чтобы вручную загрузить русский шрифт по нужному адресу, я в этой версии пролога не нашел. Мысленно послал преподавателя подальше вместе с его требованиями и прологом. Переписал все на C++ (оказывается, это так удобно, когда переменные можно изменять), добавил русский шрифт, скомпилировал exe, в программе на прологе поставил штук 300 пробелов и написал «system(»fool.exe"), exit(0)". Сдал без проблем.
Немного не понял. А чем это отличается в плане хранения состояния от обычной авторизации, например, в PHP? При логине выдаем клиенту идентификатор сессии, клиент хранит его у себя и при каждом запросе отправляет на сервер. Сервер может проверить валидность этого идентификатора, потому что хранит сессии у себя.
Почему вы думаете, что пришельцы поймут вашу математику? А вдруг у них совершенно другой способ мышления?
Читал когда-то какую-то фантастическую книжку. Там в одном месте говорится, что в качестве общепринятого символа развитых цивилизаций используется графическое изображение теоремы Пифагора (то, которое «пифагоровы штаны»). Потому что геометрия на всех планетах одинаковая, а знание этой закономерности означает, что цивилизация уже вышла из первобытного состояния, и ее представители имеют некоторое абстрактное мышление и занимаются наукой. По-моему, это выглядит довольно логично.
Если кому-то надо похранить удаленные записи недельку-месяц, это явно не проблема фреймворка) Надо — делайте.
Во-вторых, это заставляет вызывающий код знать детали реализации. Да и претензия моя, собственно, не в этом, а в том, что метод 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. Отсюда уровень зарплат в этой области. Хотя, конечно, в целом все сложнее.
Люди, которые «знают всё» на профессиональном уровне, тоже бывают, но я бы не стал называть full-stack разработчиками только их.
Обработка данных не происходит сама по себе. Для получения результата из входных данных нужно совершить некоторые действия.
Соответственно, некоторые действия будут выполнены раньше по времени, некоторые позже.
Описание может быть декларативным, выполнение — нет.
В аналоговых устройствах тоже есть задержка на распространение и преобразование сигнала. Если взять 2 рации, то звук из второй появится не одновременно с тем, как мы скажем что-то в первую. При проектировании устройств учитывается направление и движение тока.
Нужно было выбрать тему, я выбрал игровые алгоритмы. Хотел написать игру в дурака. И написал, с графическим режимом, с управлением через клавиатуру. Первая сложность была хранить номер текущей выделенной карты. Делать UI на прологе — то еще удовольствие.
Преподаватель оказался странный, с первого раза никогда не принимал. Отправил меня обратно, сказал добавить на каждом шаге вывод процесса принятия решения в текстовом виде, причем обязательно на русском, так как английский он не знал. Программа keyrus в BGI-графике не работала; функций для работы с двоичными данными, чтобы вручную загрузить русский шрифт по нужному адресу, я в этой версии пролога не нашел. Мысленно послал преподавателя подальше вместе с его требованиями и прологом. Переписал все на C++ (оказывается, это так удобно, когда переменные можно изменять), добавил русский шрифт, скомпилировал exe, в программе на прологе поставил штук 300 пробелов и написал «system(»fool.exe"), exit(0)". Сдал без проблем.
Читал когда-то какую-то фантастическую книжку. Там в одном месте говорится, что в качестве общепринятого символа развитых цивилизаций используется графическое изображение теоремы Пифагора (то, которое «пифагоровы штаны»). Потому что геометрия на всех планетах одинаковая, а знание этой закономерности означает, что цивилизация уже вышла из первобытного состояния, и ее представители имеют некоторое абстрактное мышление и занимаются наукой. По-моему, это выглядит довольно логично.
Во-вторых, это заставляет вызывающий код знать детали реализации. Да и претензия моя, собственно, не в этом, а в том, что метод 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. Отсюда уровень зарплат в этой области. Хотя, конечно, в целом все сложнее.