например, поле «получатель» при отправке email-сообщения
От того, что оно полежит на полочке изначальная цель (отправка сообщения) выполнена не будет. Да, это дополнительное удобство для пользователя, что он может сохранить промежуточный результат. Но когда он захочет отправить сообщение от обязательности поля «получатель» никуда не деться. Следуя вашей логике можно, например, при регистрации сделать поля ФИО обязательным, а промежуточные даннные записывать в сессию пользователю. Например, пользователь вбил только фамилию (разумеется этого не достаточно чтобы закончить регистрацию) и ушел со страницы, на следующей день зашел опять в регистрацию, а там значение поля «фамилия» сохранилось с прошлого раза, он вбил недостающие «имя» и «отчество» и закончил регистрацию. Только, как ни крути, эти поля все равно обязательны к заполнению для завершения действия, потому как пока он не введет все необходимые данные он не выполнит необходимое ему действие, в данном случае — регистрацию.
1. Когда в интерфейсе присутствуют обязательные поля, которые по логике никак не должны влиять на функционирование системы (например, требование ввести ФИО при регистрации на форуме). Тут я с вами согласен.
2. Поля, без которых вводимая информация не имеет смысла (например, поле «получатель» при отправке email-сообщения).
Left join — это ещё ничего, а вот когда налепят восемь inner join-ов — вот это да
А чем плохо 8 inner join'ов?
Или того хлеще, просто перечислят таблицы во from через запятую.
Сам факт еще ни о чем не говорит. Если в where указаны условия пересечения этих таблиц, то это равносильно inner join, иначе cross join. Поэтому с таким же успехом вы можете негодовать по поводу использования join'ов вообще.
В quake 3 расположение объекта в пространстве пересчитывается в момент смены кадра и в совокупности с тем, что там координаты при расчетах округляются мы имеем накапливающиеся ошибки округления, зависящие от fps. Т.е. там некоторые физические расчеты напрямую зависят от fps. Собственно, именно по-этому в quake при 125 fps получаются наиболее (в сравнении со значениями из диапазона 1-124) длинные прыжки.
Хотя обычно мы говорим «переменные» в Python (потому что это общепризнанная терминология), мы в действительности имеем в виду «имена» или «идентификаторы». В Python «переменные» — это ссылки на значения, а не именованные ячейки.
Во многих языках есть возможность управлять этим поведением, т.е. передавать переменные либо по ссылке, либо по значению. В питоне переменная содержащая, например, объект типа int по-умолчанию будет передана по значению, а переменная содержащая объект типа list — по ссылке. В данном случае мне не понятны мысли автора о том, что работа с переменными в питоне как-то принципиально отличается в сравнении с другими языками.
От того, что оно полежит на полочке изначальная цель (отправка сообщения) выполнена не будет. Да, это дополнительное удобство для пользователя, что он может сохранить промежуточный результат. Но когда он захочет отправить сообщение от обязательности поля «получатель» никуда не деться. Следуя вашей логике можно, например, при регистрации сделать поля ФИО обязательным, а промежуточные даннные записывать в сессию пользователю. Например, пользователь вбил только фамилию (разумеется этого не достаточно чтобы закончить регистрацию) и ушел со страницы, на следующей день зашел опять в регистрацию, а там значение поля «фамилия» сохранилось с прошлого раза, он вбил недостающие «имя» и «отчество» и закончил регистрацию. Только, как ни крути, эти поля все равно обязательны к заполнению для завершения действия, потому как пока он не введет все необходимые данные он не выполнит необходимое ему действие, в данном случае — регистрацию.
2. Поля, без которых вводимая информация не имеет смысла (например, поле «получатель» при отправке email-сообщения).
А чем плохо 8 inner join'ов?
Сам факт еще ни о чем не говорит. Если в where указаны условия пересечения этих таблиц, то это равносильно inner join, иначе cross join. Поэтому с таким же успехом вы можете негодовать по поводу использования join'ов вообще.
В quake 3 расположение объекта в пространстве пересчитывается в момент смены кадра и в совокупности с тем, что там координаты при расчетах округляются мы имеем накапливающиеся ошибки округления, зависящие от fps. Т.е. там некоторые физические расчеты напрямую зависят от fps. Собственно, именно по-этому в quake при 125 fps получаются наиболее (в сравнении со значениями из диапазона 1-124) длинные прыжки.
Т.е. вы утверждаете, что:
выведет 2? Если нет, то что это если не передача по значению?
Во многих языках есть возможность управлять этим поведением, т.е. передавать переменные либо по ссылке, либо по значению. В питоне переменная содержащая, например, объект типа int по-умолчанию будет передана по значению, а переменная содержащая объект типа list — по ссылке. В данном случае мне не понятны мысли автора о том, что работа с переменными в питоне как-то принципиально отличается в сравнении с другими языками.