История изменений
Исправление www_linux_org_ru, (текущая версия) :
Это кретинизм - у одного объекта этого класса оператор работает так а у объекта этого класса - иначе. Те кто с головой дружит знает что такие вещи разрешаются через наследование. Скажите пожалуйста, вы че, реально такими вещами занимаются? (если да - то напомните мне что ВЫ СЧИТАЕТЕ быдлокодом).
это хороший вопрос, на который отвечать полностью долго, и поэтому вот для начала краткий ответ — такая ситуация получается не потому, что «я этими вещами занимаюсь», а потому, что «этими вещами» практически гарантированно займутся два или более *независимых* автора библиотек (речь идет о написании своего objectizer-а, а не о перегрузке оператора >)
именно поэтому имеет смысл обеспечить для них класс, который как бы ничего и не переопределяет сам, но дает возможность переопределить *независимо* друг от друга
(кроме того, в с++ тип Object будет параметризованный, так что «у одного объекта этого класса оператор работает так а у объекта этого класса - иначе» скорее неверно)
Те кто с головой дружит знает что такие вещи разрешаются через наследование.
это опять хороший вопрос
разрешать такие вещи через наследование — это устаревшая и не очень удобная практика; более того, здесь как раз возможно и проявляется преимущество статики над динамикой
когда программист А пишет «asdf» > «/path/to/file», а программист В пишет if( «7» > «123» ), то они пользуются разными *системами обозначений*, или просто разными *обозначениям*; тот смысл, который они вкладывают в оператор >, совершенно различен, и это одна из особенностей разработки, которую *должна* поддерживать модульность (и совсем другой вопрос, в каких рамках такое надо сознательно применять)
подход прогеров на динамически типизированных языках примерно таков: «>» это ключ (единого для всех объектов типа «строка») хэша, существующего в рантайме, а значение хэша — это операция, которую надо вызвать; перезаписать это значение можно только через наследование (реально перезаписывается конечно не значение, а тайптег или адрес того самого хэша, в котором ищутся операции)
это все хорошо только до тех пор, пока обозначения прогеров А и В совпадают, а различаться они могут, и достаточно тонко
пример тонких различий в обозначениях: прогер А рассчитывает, что (NaN==NaN) вычисляется как true, а прогер В рассчитывает, что (NaN==NaN) вычисляется как false
Исправление www_linux_org_ru, :
Это кретинизм - у одного объекта этого класса оператор работает так а у объекта этого класса - иначе. Те кто с головой дружит знает что такие вещи разрешаются через наследование. Скажите пожалуйста, вы че, реально такими вещами занимаются? (если да - то напомните мне что ВЫ СЧИТАЕТЕ быдлокодом).
это хороший вопрос, на который отвечать полностью долго, и поэтому вот для начала краткий ответ — такая ситуация получается не потому, что «я этими вещами занимаюсь», а потому, что «этими вещами» практически гарантированно займутся два или более *независимых* автора библиотек (речь идет о написании своего objectizer-а, а не о перегрузке оператора >)
именно поэтому имеет смысл обеспечить для них класс, который как бы ничего и не переопределяет сам, но дает возможность переопределить *независимо* друг от друга
(кроме того, в с++ тип Object будет параметризованный, так что «у одного объекта этого класса оператор работает так а у объекта этого класса - иначе» скорее неверно)
Те кто с головой дружит знает что такие вещи разрешаются через наследование.
это опять хороший вопрос
разрешать такие вещи через наследование — это устаревшая и не очень удобная практика; более того, здесь как раз возможно и проявляется преимущество статики над динамикой
когда программист А пишет «asdf» > «/path/to/file», а программист В пишет if( «7» > «123» ), то они пользуются разными *системами обозначений*, или просто разными *обозначениям*; тот смысл, который они вкладывают в оператор >, совершенно различен, и это одна из особенностей разработки, которую *должна* поддерживать модульность (и совсем другой вопрос, в каких рамках такое надо сознательно применять)
подход прогеров на динамически типизированных языках примерно таков: «>» это ключ (единого для всех объектов типа «строка») хэша, существующего в рантайме, а значение хэша — это операция, которую надо вызвать; перезаписать это значение можно только через наследование
это все хорошо только до тех пор, пока обозначения прогеров А и В совпадают, а различаться они могут, и достаточно тонко
пример тонких различий в обозначениях: прогер А рассчитывает, что (NaN==NaN) вычисляется как true, а прогер В рассчитывает, что (NaN==NaN) вычисляется как false
Исходная версия www_linux_org_ru, :
Это кретинизм - у одного объекта этого класса оператор работает так а у объекта этого класса - иначе. Те кто с головой дружит знает что такие вещи разрешаются через наследование. Скажите пожалуйста, вы че, реально такими вещами занимаются? (если да - то напомните мне что ВЫ СЧИТАЕТЕ быдлокодом).
это хороший вопрос, на который отвечать полностью долго, и поэтому вот для начала краткий ответ — такая ситуация получается не потому, что «я этими вещами занимаюсь», а потому, что «этими вещами» практически гарантированно займутся два или более *независимых* автора библиотек (речь идет о написании своего objectizer-а, а не о перегрузке оператора >)
именно поэтому имеет смысл обеспечить для них класс, который как бы ничего и не переопределяет сам, но дает возможность переопределить *независимо* друг от друга
(кроме того, в с++ тип Object будет параметризованный, так что «у одного объекта этого класса оператор работает так а у объекта этого класса - иначе» скорее неверно)
Те кто с головой дружит знает что такие вещи разрешаются через наследование.
это опять хороший вопрос
разрешать такие вещи через наследование — это устаревшая и не очень удобная практика; более того, здесь как раз возможно и проявляется преимущество статики над динамикой
когда программист А пишет «asdf» > «/path/to/file», а программист В пишет if( «7» > «123» ), то они пользуются разными *системами обозначений*, или просто разными *обозначениям*; тот смысл, который они вкладывают в оператор >, совершенно различен, и это одна из особенностей разработки, которую *должна* поддерживать модульность (и совсем другой вопрос, в каких рамках такое надо сознательно применять)
подход прогеров на динамически типизированных языках примерно таков: «>» это ключ (единого для всех объектов типа «строка») хэша, существующего в рантайме, а значение хэша — это операция, которую надо вызвать; перезаписать это значение можно только через наследование
это все хорошо только до тех пор, пока обозначения прогеров А и В совпадают, а различаться они могут, и достаточно тонко
пример: прогер А рассчитывает, что (NaN==NaN) вычисляется как true, а прогер В рассчитывает, что (NaN==NaN) вычисляется как false