Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Вот мне и интересно, что под этим можно понимать? Под термином "данные объекта", или "функция объекта", или "класс" ясно, что скрывается. А вот что такое "свойство"? Класс? Или не класс?
Свойство — это, вообще говоря, паттерн.
Вот его примерное определение: свойство — это часть контракта объекта, обеспечивающая управление изолированной частью его состояния.
Подробнее: если удается выделить некоторую изолировнную часть состояния объекта (например, Height), и ей имеет смысл управлять отдельно, то можно дать доступ на чтение к этим данным и на запись этих данных.

Реализация этого паттерна существенным образом зависит от языка. В примитивных языках приходится извращаться при помощи функций типа GetWindowText/SetWindowText.
В более продвинутых языках паттерн реализуется методами класса.
В совсем продвинутых языках этот паттерн поддерживается напрямую и не требует никаких соглашений, что упрощает читаемость кода, снижает количество случайных ошибок, и предоставляет метаданные о реализации данного паттерна средствам метапрограммирования.

IT>>И дальше что? Как ты собираешься это использовать?

ГВ>Да как-как. Вот так, к примеру:
Не вижу в примере упоминаний ни Property, ни AdvancedProperty.
Собственно, фундамент непонимания происходит именно от того, что не вполне оправданно реализовывать свойство в виде отдельного класса. Значение свойства — пожалуйста. Впрочем, проблема понятна — нельзя выразить в терминах С++ то, чего в нем нету. Принципиально нету.
Кстати, на досуге советую помедитировать также над паттерном Event, который является несколько более сложным аналогм паттерна Property.

Здравствуйте, Cyberax, Вы писали:

C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
C>класса я могу взять ссылку (в С++).
А на метод ???

icWasya wrote:

> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
> C>класса я могу взять ссылку (в С++).
> А на метод ???
Да.

typedef Result Object::*MethodRef(Param);

MethodRef — указатель на возвращающй Result метод объекта Object с параметром типа Param.

Здравствуйте, Sinclair, Вы писали:

ГВ>>Вот мне и интересно, что под этим можно понимать? Под термином "данные объекта", или "функция объекта", или "класс" ясно, что скрывается. А вот что такое "свойство"? Класс? Или не класс?
S>Свойство — это, вообще говоря, паттерн.
S>Вот его примерное определение: свойство — это часть контракта объекта, обеспечивающая управление изолированной частью его состояния.

И метод — тоже часть контракта, далее по тексту. И потом, что значит: "изолированная часть состояния"? Явная поддержка слабой внутренней связности? Милый паттерн, ничего не скажешь.

S>Подробнее: если удается выделить некоторую изолировнную часть состояния объекта (например, Height), и ей имеет смысл управлять отдельно, то можно дать доступ на чтение к этим данным и на запись этих данных.

Интересно, а read-only часть состояния "Perimeter" связана с Height или нет?

S>Реализация этого паттерна существенным образом зависит от языка. В примитивных языках приходится извращаться при помощи функций типа GetWindowText/SetWindowText.
S>В более продвинутых языках паттерн реализуется методами класса.

S>В совсем продвинутых языках этот паттерн поддерживается напрямую и не требует никаких соглашений, что упрощает читаемость кода, снижает количество случайных ошибок, и предоставляет метаданные о реализации данного паттерна средствам метапрограммирования.

Как известно, паттерн на то и паттерн, что подразумевает много реализаций. Реализация классом — одна из них.

S>Собственно, фундамент непонимания происходит именно от того, что не вполне оправданно реализовывать свойство в виде отдельного класса. Значение свойства — пожалуйста. Впрочем, проблема понятна — нельзя выразить в терминах С++ то, чего в нем нету. Принципиально нету.

Всё равно для того, чтобы рассуждать об оправданности реализации свойства классом необходимо сначала ясно ответить, что такое "свойство". "Ясно" означает так, чтобы этим определением нельзя было обозначить ничего другого кроме свойства.

S>Кстати, на досуге советую помедитировать также над паттерном Event, который является несколько более сложным аналогм паттерна Property.

Чтобы тебе не соврать... Года четыре-пять назад тут много над ним медитировали. Ключевое слово: "делегаты". Дальше — в поиск.

Здравствуйте, Sinclair, Вы писали:

S>Свойство — это, вообще говоря, паттерн.

Ты не верно интерпретируешь понятие "паттерн".

По-моему, паттерн — это некий стандартный способ эмуляции некоего подразумеваемого поведения или свойства. Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка. А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.

Например, в C++ паттерном кроме свойств так же являются и интерфейсы, указатели на функцию-член класса и многое другое.

И можно смело утверждать, что чем больше в ЯП приходится делать с помщью паттернов, тем более низкоуровнеым и менее выразительным является язык. В прочем конечно если язык позволяет встравать паттерны, то уровень языка можно менять на ходу. Вопрос только в качестве и простоте этого изменения.

Здравствуйте, VladD2, Вы писали:

VD>Ты не верно интерпретируешь понятие "паттерн".

VD>По-моему, паттерн — это некий стандартный способ эмуляции некоего подразумеваемого поведения или свойства. Так что если в языке свойство есть, то это уже не паттерн, а часть спецификации языка. А вот если его нет и его приходится эмулировать через некий набор действий (подход) или некий эмулирующий его код, вот тогда это паттерн.

А по моему ты неверно привязываешь понятие паттерн к конкретным языкам. Мне кажется паттерн более общее понятие не зависящее от языков. В той же бандитской книге есть много оговорок что например данный патерн реализуется в смаллток просто конструкциями языка, но паттерном от этого быть не перестает.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, IT, Вы писали:

IT>>Кстати, а вдруг твой метод вернёт true, а в переменной окажется null Вот веселуха начнётся.
S>Кстати, только вчера нарвался на аналогичные чудеса.
S>Вызываем IXMLDocument::selectSingleNode().
S>Проверяем его результат на SUCCEEDED.
S>Пытаемся работать с out-параметром.
S>Упс! Оказывается, эти орлы возвращают S_FALSE, который считается успешным результатом. Ну и получаем классической ASSERT p!=0.
S>Коды ошибок — отстой.

Сначала я думал, что виноваты коды ошибок. На самом деле здесь виноват ты в том, что не прочёл документации, и не знаешь, что возвращаемый resultNode может быть NULL.

Ты хочешь, чтобы функция возвратила ошибочный код, если node не найден. Если такое поведение перевести на язык C#, например, то это будет эквивалентно выбрасыванию исключения. Такой подход не имеет смысла, потому что ситуация, когда node не может быть найден в xml документе, типична, а вовсе не исключительна. Поэтому использование исключения (в варианте C#) как и ошибочного кода возврата (в варианте C++) здесь не правомерно.

Здравствуйте, FR, Вы писали:

FR>А по моему ты неверно привязываешь понятие паттерн к конкретным языкам. Мне кажется паттерн более общее понятие не зависящее от языков. В той же бандитской книге есть много оговорок что например данный патерн реализуется в смаллток просто конструкциями языка, но паттерном от этого быть не перестает.

Это только по-твоему. Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.

Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.

kan_izh wrote:

>> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
>> C>класса я могу взять ссылку (в С++).
>> А на метод ???
> Да.
> typedef Result Object::*MethodRef(Param);
> MethodRef — указатель на возвращающй Result метод объекта Object с
> параметром типа Param.
Э... Что неправильно? Почему "-", VladD2?

Если вопрос заключался в "а на метод объекта", то достаточно запомнить пару — this и указатель на метод класса. В
качестве удобной реализации этой идеомы можно boost::function взять.

kan_izh wrote:
>> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
>> C>класса я могу взять ссылку (в С++).
>> А на метод ???
> Да.
> typedef Result Object::*MethodRef(Param);
> MethodRef — указатель на возвращающй Result метод объекта Object с
> параметром типа Param.
А теперь вызови его без указателя this

Что-то с boost::function было бы более похоже на правду, но там от
семантики ссылки уже мало что останется.

Здравствуйте, VladD2, Вы писали:

VD>Это только по-твоему. Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.

Смысл паттернов не зависит от того реализованы или нет они на каком-то языке, это влияет только на легкость исползования.

VD>Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.

И что? Скажем так, это деталь реализации данного патерна для некторых языков

Cyberax wrote:

>> > C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
>> > C>класса я могу взять ссылку (в С++).
>> > А на метод ???
>> Да.
>> typedef Result Object::*MethodRef(Param);
>> MethodRef — указатель на возвращающй Result метод объекта Object с
>> параметром типа Param.
> А теперь вызови его без указателя this
Тоже путаем класс и объект?

> Что-то с boost::function было бы более похоже на правду, но там от
> семантики ссылки уже мало что останется.
Т.е.?

kan_izh wrote:
>> А теперь вызови его без указателя this
> Тоже путаем класс и объект?
Нет, прочитай топик сначала — флейм был о свойствах (которые не добавили
тупые стандартизаторы С++).

>> Что-то с boost::function было бы более похоже на правду, но там от
>> семантики ссылки уже мало что останется.
> Т.е.?
Свойство обладает, фактически, семантикой обычной ссылки. То есть
маскируется под обычную переменную.

Здравствуйте, VladD2, Вы писали:

A>>boost::function отлично выполняет эту функцию.

VD>1. boost::function не является примитивом языка.

Очень хорошо.

VD>2. Он не компилируется на некоторых компиляторах, а значит доступен не везде.

Беда компиляторов.

VD>3. Он имеет ряд проблем в применении.

Основная, как я понимаю — невозможность неожиданно изменить время жизни объектов, вовлекаемых в замыкание. Нормальная деталь программирования на C++ — контроль жизненного цикла объекта.

VD>4. Примеры с тем что ты называшь лямбдами вообще никуда не годятся.

Ну в качестве примеров они вполне годятся.

VD>5. Реализация этого дела ужасна. Она значительно увеличиывает время компиляции и ухудшает понятность сообщений об ошибках.

Субъективные факторы, кроме времени компиляции. Мне вот, например, сообщения понятны.

VD>В итое, лично я не могу назвать такую реализацию полной и качественной. С другой стороны я не могу найти ни одного недостатка у сэмулированных макросами Немерла операторов.

А лично я не могу сказать, что мучаюсь без лямбд. Иногда не хватает, да, но и не более того. И мне индифферентно, насколько качественна реализация boost::function. Не понравится — свою напишу. Сейчас пока нужды в этом нет.

VD>В общем, если даже принять во внимане boost::function, все равно в языке остается слишком много лишнего сахара который вообще не реализовать средствами языка, и средства изменения языка очень окграничены.

А зачем менять синтаксис языка? Задача как правило состоит в реализации тех или иных концепций и подходов, как с теми же замыканиями.

VD>Как иминимум нет возможности изменить синтаксис.

Это недостаток?

VD>А изменение семантики сложно, неполноценно и чревато проблемами.

Если ты про изменение семантики операторов, то оно происходит по вполне точным "законам жанра": чего-то можно, чего-то нельзя.

Здравствуйте, WolfHound, Вы писали:

E>>

E>>[...]Moreover, these public fields have side effects!

E>>Было бы любопытно услышать, что по этому поводу думают сторонники properties.
WH>Демагогия обыкновенная. Такая "аргументация" в данном форуме очень частое явление. Особенно когда реальных аргументов нет.

Насчёт побочных эффектов невинного "obj.val = 123" всё правильно сказано.

Здравствуйте, Sinclair,

Так в чём, всё-таки, глобальный дифференс между свойством "bool engine_active" и функцией "bool is_engine_active() const"? Кроме подслащения синтаксиса, разумеется.

И ещё, кстати, инкапсуляция сама по себе от пользователей ничего не требует. Вот такое обращение:

SomeClass *p = ...;

p->internal_data_ = 0;

означает прямое изменение инкапсулированных данных, а не "нарушение инкапсуляции". SomeClass как инкапсулировал (содержал) internal_data_, так и продолжает это делать. Правда такое обращение противоречит концепции скрытия данных. Разницу между "скрытием" и "содержанием" объяснять нужно?

Cyberax wrote:

>> > А теперь вызови его без указателя this
>> Тоже путаем класс и объект?
> Нет, прочитай топик сначала — флейм был о свойствах (которые не добавили
> тупые стандартизаторы С++).
Ну да, твоим возражением было то, что оно плохо вписывается в идеологию, ибо как на член класса на него тоже хочется
брать ссылку. Я с этим согласен, хочется иметь возможностьоперировать свойством как некой сущностью, например, передать
как аргумент функции (например, написать функцию, которая будет коллекцию объектов сортировать по данному свойству).
icWasya спросил, можно ли такое делать с методом, я показал как.
В общем всё.

>> > Что-то с boost::function было бы более похоже на правду, но там от
>> > семантики ссылки уже мало что останется.
>> Т.е.?
> Свойство обладает, фактически, семантикой обычной ссылки. То есть
> маскируется под обычную переменную.
Вроде, не семантикой. Семантически — это метод, который синтаксически выглядит как переменная.

Здравствуйте, FR, Вы писали:

FR>Смысл паттернов не зависит от того реализованы или нет они на каком-то языке, это влияет только на легкость исползования.

Ошибаешся. Паттерн это именно прием эмуляции недостающей функциональности. Если же фукнциональность есть, то нужны ее эмулировать нет. И стало быть писать код проще.

VD>>Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.

FR>И что? Скажем так, это деталь реализации данного патерна для некторых языков

Ты серьезно считашь паттерн-матнчинг реализацией Посетителя? Я вот так не считаю. Однако нужда в Посетителе при этом отпадает. Причем код при этом получается более высокоуровневым. А ведь паттерн-матчинг не более чем сахар. Все что он делает можно сэмулировать паттернами проектирования на if-ах.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Смысл паттернов не зависит от того реализованы или нет они на каком-то языке, это влияет только на легкость исползования.

VD>Ошибаешся. Паттерн это именно прием эмуляции недостающей функциональности. Если же фукнциональность есть, то нужны ее эмулировать нет. И стало быть писать код проще.

Нет не эмуляция, а типовой способ решения задачи. И даже если язык напрямую подерживает паттерн, важно еще знать когда и как его применять.

VD>>>Например, паттерн-матчинг в лучшем виде заменяет паттерн Посетитель.

FR>>И что? Скажем так, это деталь реализации данного патерна для некторых языков

VD>Ты серьезно считашь паттерн-матнчинг реализацией Посетителя? Я вот так не считаю. Однако нужда в Посетителе при этом отпадает. Причем код при этом получается более высокоуровневым. А ведь паттерн-матчинг не более чем сахар. Все что он делает можно сэмулировать паттернами проектирования на if-ах.

Нет. Патерн-матчинг не может полностью заменить посетителя (вот мультиметоды могут) с его помощью просто удобно решать многие из тех задач для решения которых был придуман посетитель.

Здравствуйте, VladD2, Вы писали:

FR>>А по моему ты неверно привязываешь понятие паттерн к конкретным языкам. Мне кажется паттерн более общее понятие не зависящее от языков. В той же бандитской книге есть много оговорок что например данный патерн реализуется в смаллток просто конструкциями языка, но паттерном от этого быть не перестает.

VD>Это только по-твоему.

По-моему тоже.

VD>Тем не менее есть языки для которых многие паттерны не имеют смысла, так как языки имеют встроенную реализацию оных или нечто в лучшем виде заменющих их.

Под оными ты понимаешь паттерны, правильно?