// Описание свойства только для записи
template<class owner_t, class value_t>
struct domen_write_only_t
{
typedef void (owner_t::*set_method_t) (const value_t &);
template<set_method_t set_method>
class property_write_only_t
{
owner_t& m_owner;
public:
property_write_only_t(owner_t& a_owner) : m_owner(a_owner) { ; }
const value_t& operator = (const value_t& a_value)
{
(m_owner.*set_method)(a_value);
return a_value;
}
};
};
class sample_t
{
private:
double m_val;
public:
void set_value(const double& a_val)
{
m_val = a_val;
}
domen_write_only_t<sample_t, double> ::
property_write_only_t <set_value> val;
sample_t(): m_val(0.), val(*this)
{
}
};
Можно ли реализовать свойства шаблонного класса?
Вот пример обычного описания свойства для записи и использование его в тестовом классе sample_t.
Здесь для простоты приведен пример свойства, реализующего только запись.
Возможно ли реализовать подобные свойства для шаблонного класса?
Например для класса sample2_t:
Код:
Здесь для простоты приведен пример свойства, реализующего только запись.
Возможно ли реализовать подобные свойства для шаблонного класса?
Например для класса sample2_t:
Код:
template<class T>
class sample2_t
{
private:
T m_val;
public:
void set_value(const T& a_val)
{
m_val = a_val;
}
sample2_t(): m_val(0)
{
}
};
class sample2_t
{
private:
T m_val;
public:
void set_value(const T& a_val)
{
m_val = a_val;
}
sample2_t(): m_val(0)
{
}
};
2Green
Ё-мое, я не призываю добавить свойства в stl и не доказываю что свойства это хорошо.
Я не вижу как, если их реализуют и добавят в stl, это может свести на нет саму stl. А ты показать не можешь и предлагаешь какие-то эксперименты с std::min. Объясни подробнее, что мне нужно с ней сделать, чтобы я убедился, что свойства сводят на нет stl.
Добавлено:
А, собственно, что ты подразумеваешь под "сведут на нет"?
Ё-мое, я не призываю добавить свойства в stl и не доказываю что свойства это хорошо.
Я не вижу как, если их реализуют и добавят в stl, это может свести на нет саму stl. А ты показать не можешь и предлагаешь какие-то эксперименты с std::min. Объясни подробнее, что мне нужно с ней сделать, чтобы я убедился, что свойства сводят на нет stl.
Добавлено:
А, собственно, что ты подразумеваешь под "сведут на нет"?
Цитата: Zorkus
Господа, just FYI:
http://www.javalobby.org/java/forums/t90756.html
Может, кому то будет любопытно. Обсуждение свойств в (будущей) Java 1.7.
http://www.javalobby.org/java/forums/t90756.html
Может, кому то будет любопытно. Обсуждение свойств в (будущей) Java 1.7.
.NET конечно форева :p, но я рад что в Java всетаки решили внедрить свойства.
Замечу еще раз. Свойства, реализованные на уровне языка не тоже самое, что и "свойства" (Грин их специально в кавычках пишет), реализованные через механизм шаблонов. Для полноценной и безопасной реализации "свойств" требуются средства метапрограммирования, коих нету в C++.
Цитата: Nixus
А, собственно, что ты подразумеваешь под "сведут на нет"?
STL "сломается".
Цитата: Nixus
2Green
Ё-мое, я не призываю добавить свойства в stl и не доказываю что свойства это хорошо.
Ё-мое, я не призываю добавить свойства в stl и не доказываю что свойства это хорошо.
Уже хорошо.
Цитата: Nixus
А, собственно, что ты подразумеваешь под "сведут на нет"?
Ещё лучше.
Ещё раз и по-порядку.
1. "Свойства" не будут работать с текущей реализацией STL.
2. "Свойства" нельзя просто добавить к STL, придется перерабатывать весь STL.
3. "Свойства" могут быть связаны только с простыми типами, поэтому пропадает сама суть использования шаблонов.
4. Размер самих классов свойств будут монстроидальными,
5. Количество перерабатываемых мест в STL и количество этих переработок просто огромно.
6. Эти особенности придется учитывать не только в самой STL, но и в коде её использующем, а т.к. этих нюансов будет много, то и использовать библиотеку станет очень сложно.
7. Использование свойств в некоторых случаях может нарушить принципы ООП, например инкапсуляцию. Т.к. прокси является самостоятельным объектом, я могу обратиться к полям хостового объекта, минуя сам этот объект.
8. "Свойства" запутывают код, делая его не интуитивно понятным и даже вообще непонятным, что приводит к различного рода серьезным багам (уже показывал каким).
Вывод: даже если такую библиотеку-монстр можно будет реализовать, то пользоваться ей надо будет с такой осторожностью, а ошибки находить на столько сложно, что это сведет на нет все преимущества STL.
Цитата: Nixus
Я не вижу как, если их реализуют и добавят в stl, это может свести на нет саму stl.
Я доходчиво объяснил?
Ещё раз повторю: просто реализовать и добавить не получится, придется перерабатывать ВСЁ! И ещё не понятно реально ли это возможно, но точно понятно, что это ОЧЕНЬ усложнит использование STL и сделает код с её применением наполненным кучей скрытых багов.
Цитата: Nixus
А ты показать не можешь и предлагаешь какие-то эксперименты с std::min. Объясни подробнее, что мне нужно с ней сделать, чтобы я убедился, что свойства сводят на нет stl.
Тебе показать на примере? Как можно показать на примере того, чего нет?
Или ты хочешь, чтоб я реализовал такого рода STL, чтоб доказать тебе что-то? :)
Давай тогда поступим по-другому, ты реализуешь и покажешь этим, что я неправ.
А эксперименты не какие-то, а вполне определенные. Попытайся поприменять эту функцию с различными входными параметрами, которыми будут и "свойства".
Например:
Код:
min(s.Value, 5);
Каким должно быть "свойство", чтоб такой код работал нормально?
Сколько специализаций одной только ф-ции min потребуется определить?
Цитата: Green
Уже хорошо.
Ты только что это понял?
Цитата: Green
Ещё раз и по-порядку.
1. "Свойства" не будут работать с текущей реализацией STL.
2. "Свойства" нельзя просто добавить к STL, придется перерабатывать весь STL.
3. "Свойства" могут быть связаны только с простыми типами, поэтому пропадает сама суть использования шаблонов.
4. Размер самих классов свойств будут монстроидальными,
5. Количество перерабатываемых мест в STL и количество этих переработок просто огромно.
6. Эти особенности придется учитывать не только в самой STL, но и в коде её использующем, а т.к. этих нюансов будет много, то и использовать библиотеку станет очень сложно.
7. Использование свойств в некоторых случаях может нарушить принципы ООП, например инкапсуляцию. Т.к. прокси является самостоятельным объектом, я могу обратиться к полям хостового объекта, минуя сам этот объект.
8. "Свойства" запутывают код, делая его не интуитивно понятным и даже вообще непонятным, что приводит к различного рода серьезным багам (уже показывал каким).
Вывод: даже если такую библиотеку-монстр можно будет реализовать, то пользоваться ей надо будет с такой осторожностью, а ошибки находить на столько сложно, что это сведет на нет все преимущества STL.
Я доходчиво объяснил?
Ещё раз повторю: просто реализовать и добавить не получится, придется перерабатывать ВСЁ! И ещё не понятно реально ли это возможно, но точно понятно, что это ОЧЕНЬ усложнит использование STL и сделает код с её применением наполненным кучей скрытых багов.
Тебе показать на примере? Как можно показать на примере того, чего нет?
Или ты хочешь, чтоб я реализовал такого рода STL, чтоб доказать тебе что-то? :)
Давай тогда поступим по-другому, ты реализуешь и покажешь этим, что я неправ.
А эксперименты не какие-то, а вполне определенные. Попытайся поприменять эту функцию с различными входными параметрами, которыми будут и "свойства".
Например:
Код:
min(s.Value, 5);
Каким должно быть "свойство", чтоб такой код работал нормально?
Сколько специализаций одной только ф-ции min потребуется определить?
Это все свойства твоей реализации свойств (Вот такой вот каламбур). Кто сказал что их нельзя реализовать по другому? Если ты не знаешь как совместить твою реализацию с stl, это не значит, что свойства нельзя реализовать совместимо в stl.
Цитата: Nixus
Ты только что это понял?
Интересный вопрос. А из чего и что я должен был понять ранее?
Извини, что надломал твое высокое мнение обо мне, но я не телепат.
Цитата: Nixus
Это все свойства твоей реализации свойств (Вот такой вот каламбур). Кто сказал что их нельзя реализовать по другому? Если ты не знаешь как совместить твою реализацию с stl, это не значит, что свойства нельзя реализовать совместимо в stl.
М-да...
Ты пытаешься вогнать мои рассуждения в свою жизненную позицию: "если я этого не умею, то это ещё не значит, что такого нет, а сл-но возможно все".
"Если ещё никто не создал вечный двигатель, то это ещё не значит, что его нельзя создать". :D
Ты апеллируешь к опыту, при этом совершенно забываешь про логику и научный подход.
Ты наверное не знаешь, но у языка С++ есть некоторые ограничения, которые не позволяют делать некоторые вещи. Исходя из них я и сделал эти выводы. И для этого мне не пришлось наворачивать классы "свойств".
К примеру, я четко знаю, что оператор точка не перегружается, а сл-но "свойства" будут работать только с простыми типами.
Для того, чтобы "свойства" были удобоваримыми нужно будет перегрузить ВСЕ возможные операторы и основные конструкторы. Поэтому их размер будет большим.
Т.к. "свойства" должны иметь связь с абстрагируемым их объектом и/или связанными с ними полями, и связь эта внешняя по отношению к "свойствам", то вся ответственность за поддержание этой связи будет возложена на пользователя, а сл-но увеличивает возможность ошибок. А т.к. связь эта динамическая, то ошибки будут возникать в run-time, что усложняет их поиск.
Шаблонные функции и методы инстанируются типом передаваемого аргумента, а сл-но std::min и пр. подобные функции <algorithm> работать в связке "prop<int>, int" не будут. А уже достаточно, чтоб говорить, что свойства (какими они не были бы) не совместимы с текущими версиями STL.
Хоть внешне "свойства" и похожи на поля класса, они таковыми не являются, т.к. у них совершенно иной способ доступа. А сл-но код будет запутываться, т.к. туда, куда можно передать обычные переменные и поля классов, нельзя передавать "свойства", хоть они и являются представителями ("proxy") этих полей.
Наверное, для тебя это удивительно, но для того, чтобы доказать невозможность чего-то не обязательно перебирать все возможные варианты.
Как пример, найти минимальный элемент в не отсортированном массиве нельзя быстрее, чем за O(n). И здесь не имеет значения, чья это реализация.
Цитата: Green
Интересный вопрос. А из чего и что я должен был понять ранее?
Извини, что надломал твое высокое мнение обо мне, но я не телепат.
Извини, что надломал твое высокое мнение обо мне, но я не телепат.
А из чего тогда ты сделал вывод, что я защищаю свойства или ратую за их включение в stl? Или вообще призываю их использовать?
Твои логические рассуждения базируются на том, что все реализации, которые ты придумал не укладываются в stl, но эта логика никак не распространяется на общий случай возможности включения свойств в stl.
ЗЫ. Ура, мне снова минус поставили, вот только зачем сообщение удалили. Опять обвиняют в хамстве, красота. ))
Цитата: Nixus
А из чего тогда ты сделал вывод, что я защищаю свойства или ратую за их включение в stl? Или вообще призываю их использовать?
А с чего ты взял, что у меня были такие выводы?
Цитата: Nixus
Твои логические рассуждения базируются на том, что все реализации, которые ты придумал не укладываются в stl, но эта логика никак не распространяется на общий случай возможности включения свойств в stl.
Ты глух или слеп?
Я четко описал на чем базируются мои выводы (см. хотя бы предыдущий пост). И, пожалуйста, не нужно их перебазировать под свою "теорию возможности существования Дедов Морозов". А то у меня складывается впечатление, что я разговариваю с сектантом: "Пути господни неисповедимы. И смертному не дано понять и предвидеть возможности включения свойств в stl. Аминь!"
Проанализировать возможные реализации "свойств" не ахти какая сложная задача. Человечество решало задачи и посложнее.
И моей компетентности вполне хватает, чтоб провести такой анализ.
Если с чем-то не согласен, обоснуй и докажи. Только учти, здесь собрались (в основном) инженеры, а не духовенство.
До сих пор я не увидел от тебя ни одного логичного обоснования. И (заметь!) ни одного ответа на мои вопросы.
Цитата: Nixus
ЗЫ. Ура, мне снова минус поставили, вот только зачем сообщение удалили. Опять обвиняют в хамстве, красота. ))
Зачем удалили сообщение, четко написано.
А на счет хаства...
Если ты не видишь хамства, то это ещё не значит, что его нет. :D
Цитата: Green
А с чего ты взял, что у меня были такие выводы?
Сужу по твоим сообщениям (где ты меня убеждал что свойства кривы и содержат ошибки) и по ответу на "Ты только что это понял?"
Цитата: Green
Ты глух или слеп?
Я четко описал на чем базируются мои выводы (см. хотя бы предыдущий пост). И, пожалуйста, не нужно их перебазировать под свою теорию возможности существования Дедов Морозов. А то у меня складывается впечатление, что я разговариваю с сектантом: "Пути господни неисповедимы. И смертному не дано понять и предвидеть возможности включения свойств в stl. Аминь!"
Я четко описал на чем базируются мои выводы (см. хотя бы предыдущий пост). И, пожалуйста, не нужно их перебазировать под свою теорию возможности существования Дедов Морозов. А то у меня складывается впечатление, что я разговариваю с сектантом: "Пути господни неисповедимы. И смертному не дано понять и предвидеть возможности включения свойств в stl. Аминь!"
Каким сектантом? Твои фантазии оставь себе.
Я до сих пор не увидел сведения на нет stl свойствами. При чем тут тот факт, что свойства сдержат трудноуловимые ошибки? При чем тут невозможность передачи свойств в стандартные функции? Что с того что stl придется переписать? Интерфейс останется старым и тебя как апологета "мышления на уровне языка, а не реализации" это вообще не долно смущать.
Наличие свойств в stl никак не скажется на остальных компонентах stl в плане совместимости с версией без свойств. Так почему их введение долно свести на нет всю stl?
Если ты хотел сказать что свойства не укладываются в концепцию stl, т.к. слишком кривы и содержат потенциальные ошибки, то я соглашусь, однако их наличие там не сломет (как утверждают некоторые) и не сведет на нет саму билиотеку.
Цитата: Green
Зачем удалили сообщение, четко написано.
А на счет хаства...
Если ты не видишь хамства, то это ещё не значит, что его нет. :D
А на счет хаства...
Если ты не видишь хамства, то это ещё не значит, что его нет. :D
Если тебе показалось хамство, это не значит что оно там было. Для меня не понятно, что движет человеком, когда тот отвечает на вопрос, адресованный не ему. Поэтому я и задал тот вопрос. Тем более если человек уже несколько раз демонстрировал свою неадекватность к теме в которую влезает.
Цитата: Nixus
Сужу по твоим сообщениям (где ты меня убеждал что свойства кривы и содержат ошибки) и по ответу на "Ты только что это понял?"
Ну какие-то непонятные у тебя суждения, но я оставлю это за рамками этого обсуждения.
Цитата: Nixus
Я до сих пор не увидел сведения на нет stl свойствами.
При этом я считаю, что я их привел, но ты их просто не увидел.
Если учесть, что другие наблюдатели их увидели, считаю, что "проблемы не на моей стороне".
Цитата: Nixus
При чем тут тот факт, что свойства сдержат трудноуловимые ошибки? При чем тут невозможность передачи свойств в стандартные функции? Что с того что stl придется переписать?
С того, что это и сделает библиотеку, мягко говоря, неоднозначной и очень сложной в использовании и поддержке. Что я считаю и сведет её на нет.
Цитата: Nixus
Интерфейс останется старым и тебя как апологета "мышления на уровне языка, а не реализации" это вообще не долно смущать.
А почему ты уверен, что он останется прежним?
На чем основана твоя уверенность?
Интерфейс как минимум придется расширять (я это уже показывал), а возможно и изменять.
Цитата: Nixus
Наличие свойств в stl никак не скажется на остальных компонентах stl в плане совместимости с версией без свойств. Так почему их введение долно свести на нет всю stl?
Никак не скажется в идеальном варианте, когда "свойства" идеально вписываются в концепцию.
А в неидеальном варианте? В варианте со сломанной концепцией?
Цитата: Nixus
Если ты хотел сказать что свойства не укладываются в концепцию stl, т.к. слишком кривы и содержат потенциальные ошибки, то я соглашусь, однако их наличие там не сломет (как утверждают некоторые) и не сведет на нет саму билиотеку.
Ты противоречишь сам себе.
Свойства не укладываются в концепцию, но при этом их введение никак не отразится на реализацию этой концепции?
Или нарушение концепции не сведет на нет библиотеку реализованную по этой концепции?
Реализация и концепция взаимосвязаны. Нарушаешь концепцию, нарушается реализация. Это и есть - свести библиотеку на нет.
Опять же о каких "свойствах" ты говоришь? Совсем недавно ты заверял, что в мире возможны реализации совместимые с stl.
Объясни, как могут быть вещи совместимые, но не укладывающиеся в концепцию?
Как вещь несовместимая с концепцией может быть частью этой концепции?
Цитата: Green
Ну какие-то непонятные у тебя суждения, но я оставлю это за рамками этого обсуждения.
Ну да, убеждал в глючности свойств ты меня только потому что я с этим был согласен. :)
Цитата: Green
При этом я считаю, что я их привел, но ты их просто не увидел.
Если учесть, что другие наблюдатели их увидели, считаю, что "проблемы не на моей стороне".
Если учесть, что другие наблюдатели их увидели, считаю, что "проблемы не на моей стороне".
Мягко говоря, не все наблюдатели их увидели. Увидел кажется только один, точнее он попытался перевести мне что ты подразумевал под "сведет на нет".
Ты привел доказательства ошибок в твоей реализации свойств и проблемы использования твоей реализации свойств в текущей реализации stl. С этим я вообще не спорил. Но это никак не относится к возможности включения свойств в stl.
Цитата: Green
С того, что это и сделает библиотеку, мягко говоря, неоднозначной и очень сложной в использовании и поддержке. Что я считаю и сведет её на нет.
Т.е. библиотека будет работать, но будут потенциальные ошибки только у свойств.
Цитата: Green
А почему ты уверен, что он останется прежним?
На чем основана твоя уверенность?
На чем основана твоя уверенность?
Потому что уже написана куча кода с использованием stl и разработчики вынуждены будут обеспечить обратнуюсовместимость или отказатся от внесения изменений.
Цитата: Green
Интерфейс как минимум придется расширять (я это уже показывал), а возможно и изменять.
Дополнительные декларации, если таковые понадобятся, не вызовут проблем с обратной совместимостью. Но и появится новый инструмент, который будет обладать ограничениями.
Цитата: Green
Никак не скажется в идеальном варианте, когда "свойства" идеально вписываются в концепцию.
Т.е. такая ситуация возможна, если кто-то реализует свойства лишенные описанных тобой недостатков?
Цитата: Green
А в неидеальном варианте? В варианте со сломанной концепцией?
Мне не понятно что значит сломаной? Не все инструменты в stl ведут себя идеально там есть подводные камни и без свойств. Но это все укладывается в концепцию. Тут вопрос компромиса.
Цитата: Green
Ты противоречишь сам себе.
Свойства не укладываются в концепцию, но при этом их введение никак не отразится на реализацию этой концепции?
Или нарушение концепции не сведет на нет библиотеку реализованную по этой концепции?
Реализация и концепция взаимосвязаны. Нарушаешь концепцию, нарушается реализация. Это и есть - свести библиотеку на нет.
Свойства не укладываются в концепцию, но при этом их введение никак не отразится на реализацию этой концепции?
Или нарушение концепции не сведет на нет библиотеку реализованную по этой концепции?
Реализация и концепция взаимосвязаны. Нарушаешь концепцию, нарушается реализация. Это и есть - свести библиотеку на нет.
Нарушена концепция, если и будет, то только по отношениюк свойствам, остальные компоненты останутся такими же какие были. Т.е. не сведутся на нет и не сломаются. Ведь даже в текущей версии stl не все ее компоненты дружат друг с другом. Так почему свойства должны будут дружить со всеми компонетами если их введут?
Цитата: Green
Опять же о каких "свойствах" ты говоришь? Совсем недавно ты заверял, что в мире возможны реализации совместимые с stl.
Объясни, как могут быть вещи совместимые, но не укладывающиеся в концепцию?
Как вещь несовместимая с концепцией может быть частью этой концепции?
Объясни, как могут быть вещи совместимые, но не укладывающиеся в концепцию?
Как вещь несовместимая с концепцией может быть частью этой концепции?
В данном случае я говорил о твоей реализации свойств с присущими ей недостатками.
Цитата: Nixus
Ну да, убеждал в глючности свойств ты меня только потому что я с этим был согласен. :)
Мягко говоря, не все наблюдатели их увидели. Увидел кажется только один, точнее он попытался перевести мне что ты подразумевал под "сведет на нет".
Ты привел доказательства ошибок в твоей реализации свойств и проблемы использования твоей реализации свойств в текущей реализации stl. С этим я вообще не спорил. Но это никак не относится к возможности включения свойств в stl.
Т.е. библиотека будет работать, но будут потенциальные ошибки только у свойств.
Потому что уже написана куча кода с использованием stl и разработчики вынуждены будут обеспечить обратнуюсовместимость или отказатся от внесения изменений.
Дополнительные декларации, если таковые понадобятся, не вызовут проблем с обратной совместимостью. Но и появится новый инструмент, который будет обладать ограничениями.
Т.е. такая ситуация возможна, если кто-то реализует свойства лишенные описанных тобой недостатков?
Мне не понятно что значит сломаной? Не все инструменты в stl ведут себя идеально там есть подводные камни и без свойств. Но это все укладывается в концепцию. Тут вопрос компромиса.
Нарушена концепция, если и будет, то только по отношениюк свойствам, остальные компоненты останутся такими же какие были. Т.е. не сведутся на нет и не сломаются. Ведь даже в текущей версии stl не все ее компоненты дружат друг с другом. Так почему свойства должны будут дружить со всеми компонетами если их введут?
В данном случае я говорил о твоей реализации свойств с присущими ей недостатками.
Мягко говоря, не все наблюдатели их увидели. Увидел кажется только один, точнее он попытался перевести мне что ты подразумевал под "сведет на нет".
Ты привел доказательства ошибок в твоей реализации свойств и проблемы использования твоей реализации свойств в текущей реализации stl. С этим я вообще не спорил. Но это никак не относится к возможности включения свойств в stl.
Т.е. библиотека будет работать, но будут потенциальные ошибки только у свойств.
Потому что уже написана куча кода с использованием stl и разработчики вынуждены будут обеспечить обратнуюсовместимость или отказатся от внесения изменений.
Дополнительные декларации, если таковые понадобятся, не вызовут проблем с обратной совместимостью. Но и появится новый инструмент, который будет обладать ограничениями.
Т.е. такая ситуация возможна, если кто-то реализует свойства лишенные описанных тобой недостатков?
Мне не понятно что значит сломаной? Не все инструменты в stl ведут себя идеально там есть подводные камни и без свойств. Но это все укладывается в концепцию. Тут вопрос компромиса.
Нарушена концепция, если и будет, то только по отношениюк свойствам, остальные компоненты останутся такими же какие были. Т.е. не сведутся на нет и не сломаются. Ведь даже в текущей версии stl не все ее компоненты дружат друг с другом. Так почему свойства должны будут дружить со всеми компонетами если их введут?
В данном случае я говорил о твоей реализации свойств с присущими ей недостатками.
на украине в таких случаях говорят - "Не вмер Даныло, а болячка задавыла".
Аргументы абсолютно "ни о чем". В чем необходимость введения каких то идеальных "свойств" в стандартную библиотеку? Зачем? Речь в теме идет о конкретной реализации - если есть какое то решение не содержащее указаных Green недостатков (или хотя бы обладающее массой достоинств ) - так не проще ли привести его?
Стандартной библиотека потому и называется - что ее концепция позволяет работать с ней стандартно - и какая разница в отношении чего концепция будет нарушена?
Цитата: kot_
на украине в таких случаях говорят - "Не вмер Даныло, а болячка задавыла".
Ты теперь в любой моей дисскусии с Green'ом будешь писать эту фразу? :)
Да, кстати, что там с борландовскими свойствами, ты согласен, что был неправ?
Цитата: kot_
Аргументы абсолютно "ни о чем". В чем необходимость введения каких то идеальных "свойств" в стандартную библиотеку? Зачем?
Покажи, где я ратую за их введение в stl? Опять что-то привиделось на ночь глядя?
Цитата: kot_
Речь в теме идет о конкретной реализации - если есть какое то решение не содержащее указаных Green недостатков (или хотя бы обладающее массой достоинств ) - так не проще ли привести его?
В сообщение Green'а, в объективности которого я засомневелся, говорится не о конкретной реализации, а о ненативных свойствах вообще. Если там речь шла об этой кривой реализации, то я кажется уже согласился, что ее не нужно включать в stl. Однако, повторюсь, это никак не сведет на нет оставшуюся часть библиотеки.
Цитата: kot_
Стандартной библиотека потому и называется - что ее концепция позволяет работать с ней стандартно - и какая разница в отношении чего концепция будет нарушена?
Что значит работать стандартно, сам понял что сказал? :)
Цитата: Nixus
Ты теперь в любой моей дисскусии с Green'ом будешь писать эту фразу?
Да, кстати, что там с борландовскими свойствами, ты согласен, что был неправ?
Да, кстати, что там с борландовскими свойствами, ты согласен, что был неправ?
ну так я ж не виновать что товй стиль аргументации никак не меняется и больше ничего сказать не остается? :)
По поводу борландовских свойств я действительно был не прав. Компилятор похоже просто разворачивает их в вызовы функций - но это мое предположение - все никак руки не дойдут посмотреть.
Цитата: Nixus
Покажи, где я ратую за их введение в stl? Опять что-то привиделось на ночь глядя?
ну например здесь.
Цитата:
Ты привел доказательства ошибок в твоей реализации свойств и проблемы использования твоей реализации свойств в текущей реализации stl. С этим я вообще не спорил. Но это никак не относится к возможности включения свойств в stl.
Цитата: Nixus
В сообщение Green'а, в объективности которого я засомневелся, говорится не о конкретной реализации, а о ненативных свойствах вообще. Если там речь шла об этой кривой реализации, то я кажется уже согласился, что ее не нужно включать в stl. Однако, повторюсь, это никак не сведет на нет оставшуюся часть библиотеки.
Что значит работать стандартно, сам понял что сказал? :)
я честно говоря с трудом понимаю что ты хотел сказать - например:
Цитата:
Т.е. библиотека будет работать, но будут потенциальные ошибки только у свойств.
зачем включать нечто в библиотеку - о чем заранее известно что это будет глючно? :)
может быть тебе стоит остановиться и все таки четко описать о чем ты споришь с Green? А то вроде как вы оба согласны с тем - что свойства это источник дополнительных ошибок - но ты продолжаешь зачемто отстаивать что в принципе возможна ситуация, что если вдруг свойства будут введены в stl - то даже если они будут глюкавы - то библиотеке это не повредит, а только пойдет на пользу? :)
поэтому я и привожу эту поговорку - потому что как раз она и описывает твою аргументацию - ты вроде в частном согласен - но в целом отвергаешь.
Цитата: Green
Кто ещё невнимательный?
Пальцем показывать не хорошо, но ты один из них:) Здесь :)
"...я их НЕ ИСПОЛЬЗУЮ, и никому не советую"
т.е. все таки получается твои заявления о карявости касаются - как св-в реализованных через шаблоны, так и св-в C++Builder? Так чем тебе не нравится мой кусочек кода:)
Цитата: Green
До твоего первого поста, который на первой странице, борландовское расширение вообще не упоминалось.
В моем посте на первой странице нет такого упоминания, они появляются на странице 2 и то не у меня и на странице 3 см. выше у тебя (при чем до упоминания в явном виде у меня) и т.о. ты сам явился пособником путаницы:)
Ну в итоге я формально и слив себе засчитать не могу ведь факт обсуждения св-в ВСВ присутствует (при чем и с твоей стороны в том числе).
Цитата: kot_
ну например здесь.
И где я там призываю что-то добавить в стандартную библиотеку?
Цитата: kot_
я честно говоря с трудом понимаю что ты хотел сказать - например:
зачем включать нечто в библиотеку - о чем заранее известно что это будет глючно? :)
зачем включать нечто в библиотеку - о чем заранее известно что это будет глючно? :)
При чем тут причины добавления? Мы рассматриваем что случится с библиотекой если в нее добавят свойства, так? У нас 2 варианта:
1) добавят глючные свойства.
2) добавят неглючные свойства (идеальный вариант, как назвал его Green)
В обоих случаях вся библиотека, кроме свойств, как работала так и будет работать и ничего с ней не случиться. Код, использующий stl, как работал так и будет работать. Т.о. библиотека не свидется на нет.
Цитата: kot_
может быть тебе стоит остановиться и все таки четко описать о чем ты споришь с Green?
Во первых, я не спорю. Я выразил сомнение по поводу одной фразы "сведут на нет". Из этого все сделали вывод что я:
1) защищаяю свойства
2) призываю их использовать
3) призываю их добавить в stl
чего я не делаю. И начали меня переубеждать.
Цитата: kot_
А то вроде как вы оба согласны с тем - что свойства это источник дополнительных ошибок - но ты продолжаешь зачемто отстаивать что в принципе возможна ситуация, что если вдруг свойства будут введены в stl - то даже если они будут глюкавы - то библиотеке это не повредит, а только пойдет на пользу? :)
Я не утверждаю, что это пойдет на пользу, не перевирай. В данном случае с библиотекой ничего трагического не произойдет, она будет работать как работала.
Цитата: kot_
поэтому я и привожу эту поговорку - потому что как раз она и описывает твою аргументацию - ты вроде в частном согласен - но в целом отвергаешь.
Что именно я отвергаю? Может стоит разобраться прежде чем опять вступать в спор?
Цитата:
В обоих случаях вся библиотека, кроме свойств, как работала так и будет работать и ничего с ней не случиться. Код, использующий stl, как работал так и будет работать. Т.о. библиотека не свидется на нет.
почему? Введение свойст кардинально изменит библиотеку.
Цитата: kot_
почему? Введение свойст кардинально изменит библиотеку.
Каким образом введение, например, std::property кардинально изменит тот же std::vector? Хоть убей не вижу.
Зы. А что постеснялся остальное откомментировать, особенно первый самый вопрос? :)
опять "за рыбу гроши" - тебе же ответили один раз:
Я не знаю реализации std:: property, т.к. это несуществующий (в stl) класс.
Поэтому не могу сказать, как несуществующий класс может помешать вектору.
Но это никак не относится к возможности включения свойств в stl.
Цитата:
Я не знаю реализации std:: property, т.к. это несуществующий (в stl) класс.
Поэтому не могу сказать, как несуществующий класс может помешать вектору.
что я могу сказать по данному поводу - "давайте обсуждать вкус устриц с теми кто их не ел" (с)
а что самый первый вопрос - ты же сам и отставивашь возможность добавления свойств в std - что и присуствует в цитате:
Цитата:
Но это никак не относится к возможности включения свойств в stl.
какая возможность - зачем их туда включать - я допустим хз.
какие проблемы связаны с предложенной реализацией - ты вроде и сам согласился что в таком виде свойства реализованы быть немогут. Потом предложил гипотетический класс - и хочешь что бы тебе показали как он "сведет на нет" stl. Но дело в том что в том виде как ты его предложил вообще непонятно - зачем он нужен - как же можно что либо на нем показать? При такой постановке вопроса - ну да вектор конечно мало изменится. еще бы - при такой постановке и вобще по сути мало что изменится - так как не понятно что реализует твой класс и нафига он нужен :)
З.Ы. Я тут вотку пью и читаю на нове дисскусию "сша глазами форумчан" - там 44 страницы уже - во де страсти :)
Цитата: kot_
опять "за рыбу гроши" - тебе же ответили один раз:
Так на каком основании делается предполодение что std::property сведет на нет stl? То ты утверждаешь что stl предется переделать, если в нее добавять std::property, а теперь ты не знаешь ее реализации, чтобы понять как она повлияет на stl. Демагогия одна.
Цитата: kot_
что я могу сказать по данному поводу - "давайте обсуждать вкус устриц с теми кто их не ел" (с)
а что самый первый вопрос - ты же сам и отставивашь возможность добавления свойств в std - что и присуствует в цитате:
а что самый первый вопрос - ты же сам и отставивашь возможность добавления свойств в std - что и присуствует в цитате:
Для тебя возможность эквивалентна необходимости?
Я говорю, что если свойства введут в stl ничего c stl не случится. Ты же сам не зная что произойдет с stl, утверждаешь что она сведется на нет.
Цитата: kot_
какая возможность - зачем их туда включать - я допустим хз.
Опять этот зачем? Кто тут призывает их включить? Это было не мое предложение включить свойства в stl, если ты не заметил.
Цитата: kot_
какие проблемы связаны с предложенной реализацией - ты вроде и сам согласился что в таком виде свойства реализованы быть немогут. Потом предложил гипотетический класс - и хочешь что бы тебе показали как он "сведет на нет" stl. Но дело в том что в том виде как ты его предложил вообще непонятно - зачем он нужен - как же можно что либо на нем показать? При такой постановке вопроса - ну да вектор конечно мало изменится. еще бы - при такой постановке и вобще по сути мало что изменится - так как не понятно что реализует твой класс и нафига он нужен :)
Что тут не понятного? std::property - это "свойство". Предложи реализацию свойства (абсолютно любую), при котором придется изменить вектор?
демагогия - это с твоей стороны - ты придумал абстрактное "свойство" - а теперь всем предлагаешь признать либо твою правоту либо "показать" и "предложить" нечто - что может вызвать какие либо проблемы в классах стандартной библиотеки. Т.е. это ты считаешь верхом дисскусионной культуры? В процессе обсуждения был сделан вывод, что введение "свойств" в том виде, который предложил автор топика способно привести к проблемам, особенно если пытаться реализовать их в шаблонах. При этом была высказана мысль что попытка реализовать "свойства" в предложенном виде в стандартной библиотеке способны свести на нет все ее достоинства и усложнить работу с ней. С этим ты вроде согласен?
Но невозможно даже пытаться описать проблемы в отношении чего либо, если нет внятной и четкого описания - что такое твои "свойства", зачем они должны быть включены в стандартную библиотеку, что они будут реализовать и каким образом. Не ужели так сложно это понять? Или вопрос задается только ради того что бы поспорить и доказать что ты прав? "Не умножай сущности сверх необходимости" - ты предлагаешь добавить - сущность? алгоритм? метод? - хз - и при этом ты нам же предлагаешь описать возможное влияние того что ты сам не всостоянии сформулировать.
Но невозможно даже пытаться описать проблемы в отношении чего либо, если нет внятной и четкого описания - что такое твои "свойства", зачем они должны быть включены в стандартную библиотеку, что они будут реализовать и каким образом. Не ужели так сложно это понять? Или вопрос задается только ради того что бы поспорить и доказать что ты прав? "Не умножай сущности сверх необходимости" - ты предлагаешь добавить - сущность? алгоритм? метод? - хз - и при этом ты нам же предлагаешь описать возможное влияние того что ты сам не всостоянии сформулировать.
это напоминает детскую игру - "Купи слона..." где вместо слона "свойства", а вместо "купи" - "покажи как они сведут на нет"
Цитата: kot_
демагогия - это с твоей стороны - ты придумал абстрактное "свойство" - а теперь всем предлагаешь признать либо твою правоту либо "показать" и "предложить" нечто - что может вызвать какие либо проблемы в классах стандартной библиотеки.
Ну ты же утверждаешь, что не зависимо от реализации проблемы у stl возникнут. А какие именно показать не можешь. Значит утверждение Green'а не очевидно, о чем я и сказал. Не больше, не меньше. Остальное это твои фантазии и фантазии Green'а. При чем единственное доказательство проблем - это невозможность использовать подобные свойства в текущей версии stl и только лишь с некоторой ее частью.
Как это доказывает что свойства в общем виде сведут на нет stl, я не понимаю.
Цитата: kot_
Т.е. это ты считаешь верхом дисскусионной культуры?
Что именно?
Цитата: kot_
При этом была высказана мысль что попытка реализовать "свойства" в предложенном виде в стандартной библиотеке способны свести на нет все ее достоинства и усложнить работу с ней.
В процессе обсуждения был сделан вывод, что введение "свойств" в том виде, который предложил автор топика способно привести к проблемам, особенно если пытаться реализовать их в шаблонах.
В процессе обсуждения был сделан вывод, что введение "свойств" в том виде, который предложил автор топика способно привести к проблемам, особенно если пытаться реализовать их в шаблонах.
Где там говорится про тот вид, который предложил автор топика? Прочитай, если еще этого не сделал, или перечитай, если уже читал, про что говорил oxotnik333 и на что отвечал Green.
Цитата: kot_
С этим ты вроде согласен?
С тем что свойства которые предложил автор темы глючны согласен. Но как это оносится к свойствам в общем виде? Ведь утверждается что любая реализация свойств сведет на нет stl. И доказательство основывается на глючных свойствах приведенных автором.
Цитата: kot_
Но невозможно даже пытаться описать проблемы в отношении чего либо, если нет внятной и четкого описания - что такое твои "свойства", зачем они должны быть включены в стандартную библиотеку, что они будут реализовать и каким образом. Не ужели так сложно это понять?
Еще раз (почему именно тебе прихдиться так часто разжевывать?) Я не призваю что-либо включать в stl! Покажи где я призываю это сделать? Хватит приписывать мне то, чего я не делаю.
Цитата: kot_
Или вопрос задается только ради того что бы поспорить и доказать что ты прав?
Я кажется уже достаточно внятно показал что мне не нравится в том утверждении.
Цитата: kot_
"Не умножай сущности сверх необходимости" - ты предлагаешь добавить - сущность? алгоритм? метод? - хз - и при этом ты нам же предлагаешь описать возможное влияние того что ты сам не всостоянии сформулировать.
Где я что либо предлагаю добавить? Покажи мне? Ты в очередно раз приписываешь мне то, чего я не делаю.
2 Nixus
Вопрос к размышлению по поводу целесообразности и возможности введения свойств в STL. А как вы думаете, почему разработчики STL не добавили свойства в свою реализацию? Явно не потому, что им было лень.
[OFFTOP]
З.Ы. Я тут вотку пью и читаю на нове дисскусию "сша глазами форумчан" - там 44 страницы уже - во де страсти :)
Вопрос к размышлению по поводу целесообразности и возможности введения свойств в STL. А как вы думаете, почему разработчики STL не добавили свойства в свою реализацию? Явно не потому, что им было лень.
[OFFTOP]
Цитата: kot_
З.Ы. Я тут вотку пью и читаю на нове дисскусию "сша глазами форумчан" - там 44 страницы уже - во де страсти :)
Если не сложно, оставишь ссылку. Спасибо.
[/OFFTOP]
Цитата: nikitozz
2 Nixus
Вопрос к размышлению по поводу целесообразности и возможности введения свойств в STL. А как вы думаете, почему разработчики STL не добавили свойства в свою реализацию? Явно не потому, что им было лень.
Вопрос к размышлению по поводу целесообразности и возможности введения свойств в STL. А как вы думаете, почему разработчики STL не добавили свойства в свою реализацию? Явно не потому, что им было лень.
скорей всего они не нашли ответ на вопрос "А зачем?"... и вообще они легко заменяются методами get_.../set_...
ЗЫ:
Цитата:
...про что говорил oxotnik333...
пацаны, да я ж войны то не хотел...
Цитата: nikitozz
2 Nixus
Вопрос к размышлению по поводу целесообразности и возможности введения свойств в STL. А как вы думаете, почему разработчики STL не добавили свойства в свою реализацию? Явно не потому, что им было лень.
Вопрос к размышлению по поводу целесообразности и возможности введения свойств в STL. А как вы думаете, почему разработчики STL не добавили свойства в свою реализацию? Явно не потому, что им было лень.
Ёлки-палки. Я не говорю что нужно что-то в stl включать и не доказываю целесообразность этого. Еще раз, я не вижу каким образом введение свойств в stl сведет ее на нет. Не больше, не меньше.
Цитата: Nixus
Я не говорю что нужно что-то в stl включать и не доказываю целесообразность этого.
Так ведь я вас в этом и не "обвиняю".
Цитата: Nixus
Еще раз, я не вижу каким образом введение свойств в stl сведет ее на нет.
Я просто хочу сказать, что одной из возможных причин отказа разработчиков STL от свойств является тот факт, что использование свойств если и не "сведет ее на нет", то может по крайней мере лишить части существующих положительных черт.
Цитата: nikitozz
Я просто хочу сказать, что одной из возможных причин отказа разработчиков STL от свойств является тот факт, что использование свойств если и не "сведет ее на нет", то может по крайней мере лишить части существующих положительных черт.
Возможная причина что может случиться что-то. Это все сильно надумано. Нет причин утверждать, что добавление свойств сведет на нет stl.
Цитата: Nixus
Нет причин утверждать, что добавление свойств сведет на нет stl.
Как и нет причин утверждать обратное. Хотя это уже дейсвительно получается демагогия. :)
Вообщем, я хочу сказать, что аргументы, доказывающие, что свойства могут сказаться на STL отрицательно были уже приведены неоднократно (такие как потенциальная багоопасность, излишняя сложность и пр., не буду повторяться), а вот аргументы (такие как скажем пример кода), доказывающее обратное, пока нет.
Цитата: nikitozz
Как и нет причин утверждать обратное. Хотя это уже дейсвительно получается демагогия. :)
Демагогию, ты и разводишь возможно, может и пр..
Цитата: nikitozz
Вообщем, я хочу сказать, что аргументы, доказывающие, что свойства могут сказаться на STL отрицательно были уже приведены неоднократно
Покажи как это сведет на нет. Не скажется отрицательно, а сведет на нет.
Цитата: nikitozz
(такие как потенциальная багоопасность, излишняя сложность и пр., не буду повторяться), а вот аргументы (такие как скажем пример кода), доказывающее обратное, пока нет.
Это ошибки самих свойств, как это отразится на остальных компонентах stl?
Вот не хотел прибегать к цитированию каждой фразы и ответа на нее, но не удержался. :)
Покажи как это сведет на нет. Не скажется отрицательно, а сведет на нет.
Это ошибки самих свойств, как это отразится на остальных компонентах stl?
Цитата: Nixus
Демагогию, ты и разводишь возможно, может и пр..
С этим я бы поспорил. От вас я пока что ничто кроме гипотетических "не сведет", абсолютно не подкрепленных никакой аргументной базой не "услышал".
Цитата: Nixus
Покажи как это сведет на нет. Не скажется отрицательно, а сведет на нет.
Ну, наверное, у нас с вами разное понимание этой фразы "сведет на нет". Для меня это сокращенный вариант от "сведет на нет все его основные преимущества." Что для вас - не знаю.
Цитата: Nixus
Это ошибки самих свойств, как это отразится на остальных компонентах stl?
Отличный аргумент! Опять же, "сведет на нет" не означает, что из-за свойств "сломается" существующая STL. Вопрос в том, что если свойтсва там есть, то они там есть для того, чтобы ими пользоваться, а не для того, чтобы они там просто были, иначе зачем они нужны вообще. А вот если они там есть, то они как минимум должны быть без ошибок и при том должны предоставить все, что предоставляют геттеры/сеттеры с тем же удобством, с той же производительностью и с тем же соотношением затраченных усилий и полученной выгоды для разработчиков STL. Вот если они этого предоставить не смогут, тогда и получается, что "свели на нет".
И повторюсь, аргументы, что они этого предоставить не смогут, уже были приведены, а доказывающее обратное - нет.
Цитата: nikitozz
От вас я пока что ничто кроме гипотетических "не сведет", абсолютно не подкрепленных никакой аргументной базой не "услышал".
Лично от вас я пока тоже ничего внятного не услышал, кроме возможных причин которые может что-то вызовут.
Цитата: nikitozz
Ну, наверное, у нас с вами разное понимание этой фразы "сведет на нет". Для меня это сокращенный вариант от "сведет на нет все его основные преимущества." Что для вас - не знаю.
Давай по порядку, что случиться с stl если туда введут свойства. Какие преимущества из-за этого потеряются? Перечисли.
Может не стоит меня в чем-то убеждать, не разобравщись о чем я хочу сказать?
Что случится с тем же std::vector? Ответ - ничего не случится, он даже не изменится.
Цитата: nikitozz
И повторюсь, аргументы, что они этого предоставить не смогут, уже были приведены, а доказывающее обратное - нет.
Как я устал повторять. Были приведены аргументы глючности свойств приведенных автором темы. Как это относится к свойствам в общем виде - не вижу. Покажи.
Nixus, мне порой кажется что тебе лишь бы поспорить любой ценой ради самого спора. Выдрать какую то фразу и 10 страниц оспаривать ее. ) Уж не первый раз замечаю. Извините, что влез в вашу дискуссию. )
Другие бы блюнули бы уже дано на эту чушь. )
Кстати, очень интересно, что понимаешь под термином "свойства в общем виде" в контексте C++, чтобы уж внести ясность - что обсуждаешь то хоть. )
Другие бы блюнули бы уже дано на эту чушь. )
Кстати, очень интересно, что понимаешь под термином "свойства в общем виде" в контексте C++, чтобы уж внести ясность - что обсуждаешь то хоть. )
Цитата: aks
Nixus, мне порой кажется что тебе лишь бы поспорить любой ценой ради самого спора.
Мне тоже много чего кажется, однако я лучше промолчу, а то опять кому-нибудь хамство покажется.
А выражение своего мнения для тебя это "лишь бы поспорить любой ценой"? Я не виноват, что у некоторых участников этого форума мое мнение вызывает острое отторжение и они начинают со мной спорить, при чем самое интересное, что всегда одни и те же лица.
Цитата: aks
Выдрать какую то фразу и 10 страниц оспаривать ее. ) Уж не первый раз замечаю. Извините, что влез в вашу дискуссию. )
Ну давай приведи аргументы. А то товарищу kot_'у тоже много чего постоянно видется, что не соответсвует реальности.
Цитата: aks
Другие бы блюнули бы уже дано на эту чушь. )
Да я вот тоже удивляюсь что народ никак не уймется. 3 человека доказывали мне то, с чем я не спорю. Хочешь быть 4-м?
Цитата: aks
Кстати, очень интересно, что понимаешь под термином "свойства в общем виде" в контексте C++, чтобы уж внести ясность - что обсуждаешь то хоть. )
Знаешь что такое решение задачи в общем виде? Вот тут и оно: не делая акцент на особености конкретных реализации.
Цитата: aks
Не хочу, меня не забавляют ваши споры.
Угу. То-то ты ниже начинаешь развивать тему. :)
Цитата: aks
=))
Какие особенности. Ты хоть дай определение что ли. Что такое свойства в C++ по твоему. Раз уж вы спорите о разных вещах. )))
Какие особенности. Ты хоть дай определение что ли. Что такое свойства в C++ по твоему. Раз уж вы спорите о разных вещах. )))
Это сущность, при попытке получить значение которой выполняется определенное программистом действие и возвращается определенное программистом значение, при попытке установки значение выполняется другое опредленное програмистом действие.
Цитата: Nixus
Угу. То-то ты ниже начинаешь развивать тему. :)
Я не развиваю - я пытаюсь узнать о чем вы спорите. Может уже и спорить то не о чем - сами увидите.
Цитата: Nixus
Это сущность, при попытке получить значение которой выполняется определенное программистом действие и возвращается определенное программистом значение, при попытке установки значение выполняется другое опредленное програмистом действие.
И что это за определение )
Объект класса попадает под это определение? )
Нет уж если вы все тут придираетесь к словам и формулировкам - так давайте четкую формулировку в терминах языка или заканчивайте спор. )
Цитата: aks
Я не развиваю - я пытаюсь узнать о чем вы спорите. Может уже и спорить то не о чем - сами увидите.
Я не знаю о чем спорят товарищи Green, kot_ и пр.... По моему, я чеко выразил свою позицию. Введение свойств в stl не сведет ее на нет, т.е. библиотека не сломается.
Цитата: aks
И что это за определение )
Объект класса попадает под это определение? )
Нет уж если вы все тут придираетесь к словам и формулировкам - так давайте четкую формулировку в терминах языка или заканчивайте спор. )
Объект класса попадает под это определение? )
Нет уж если вы все тут придираетесь к словам и формулировкам - так давайте четкую формулировку в терминах языка или заканчивайте спор. )
Да, это определение свойства в общем виде.
ЗЫ. Ты адресуешь свой вопрос всем или только мне?
Ну на сколько я понял из дискуссии, народ в первую очередь обсуждал реализации того, что принято называть "свойством" приведенные здесь.
ну да, немножко покритиковали расширения языка в билдере, но на основное обсуждение (так и хочется назватить демагогию) это не особо влияло.
Ты предлагаешь обсуждать с точки зрения свойст в общем виде. Мне интресно что это такое. С твоим определением, я не согласен - оно слишком общее и под него можно подвести кучу всего что не является свойством в том виде как его привыкли понимать из других языков (где оно есть). А если ничего кроме абстракых несуществующих вещей нет - может хватит это обсуждать? )
ну да, немножко покритиковали расширения языка в билдере, но на основное обсуждение (так и хочется назватить демагогию) это не особо влияло.
Ты предлагаешь обсуждать с точки зрения свойст в общем виде. Мне интресно что это такое. С твоим определением, я не согласен - оно слишком общее и под него можно подвести кучу всего что не является свойством в том виде как его привыкли понимать из других языков (где оно есть). А если ничего кроме абстракых несуществующих вещей нет - может хватит это обсуждать? )