Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

[amk]

А если написать так?

window->changeCaptionTo("NewCaption")

Вообще, по-моему, в C++ хорошей заменой атрибутам Delphi могло бы послужить такое решение

class WindowClass {
  ...
  attribute_like Caption {
    operator=(const char *newcaption);
    const operator(char*) ();
  }
  ...
}

Добавлено:
Это не все, полный текст парой постов ниже

Сообщение отредактировано: amk - 30.10.11, 10:54

[Повстанець]

Цитата amk @ 30.10.11, 10:44

Вообще, по-моему, в C++ хорошей заменой атрибутам Delphi могло бы послужить такое решение

Мда. А обратную связь с WindowClass как?

[amk]

А если написать так?

window->changeCaptionTo("NewCaption")

Вообще, по-моему, в C++ хорошей заменой атрибутам Delphi могло бы послужить такое решение

class WindowClass {
  char *caption;
  WindowClass(): caption(0) { ... }
  ~ WindowClass() { if (caption) free(caption); }
  ...
  public:
  attribute_like Caption {
    operator=(const char *newcaption) {
      if (caption) free(caption);
      caption = strdup(newcaption);
    }
    const char *operator (char*) () { // Не помню я как каст к указателю описывать
      return caption;
    }
  }
  ...
}

Что позволяло бы обращаться

WindowClass window;
 
window.Caption = "NewCaption";
wname = window.Caption;

Но позволяло бы описывать и что-нибудь вроде

window.Counter.reset();
window.Counter.increment(1); // или
window.Counter += 1; // или
++window.Counter;

Добавлено 30.10.11, 10:54
Чего-то у меня полпоста отдельно ушло.

Добавлено 30.10.11, 10:55
Да, 'attribute_like' это такое, придуманное мной ключевое слово

[Flex Ferrum]

Цитата korvin @ 30.10.11, 09:03

и я не понимаю, почему ты решил, что для вызова метода обязательно нужны скобки

Ну так языки то разные бывают. Или нет иных языков программирования кроме Lisp'а, и korvin - пророк его?

[D_KEY]

Цитата Qraizer @ 29.10.11, 22:32

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

А в случае "ромба" при расширении интерфейсов разве есть, что совмещать и делить?

interface A
{
    int f();
}
 
interface B : A
{
    int g();
}
 
interface С : A
{
    int g();
}
 
interface D : B, C // , A
{
    // Здесь может и логично управлять разделением/совмещением g(), но не f()
}

Цитата

А реализации IUnknown обязаны быть разделены, чтобы у каждого были свои счётчики. Или счётчик пользователей не является аттрибутом, потому что непубличный?

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

Добавлено 30.10.11, 11:36

Цитата Flex Ferrum @ 30.10.11, 06:53

Он влияет на проектирование. Делает интерфейс класса более очевидным и приближенным к реальности.

Например?

Сообщение отредактировано: D_KEY - 30.10.11, 12:48

[korvin]

Цитата Flex Ferrum @ 30.10.11, 11:05

Ну так языки то разные бывают. Или нет иных языков программирования кроме Lisp'а, и korvin - пророк его?

при чем тут лисп? просто ты приводишь особенности синтаксиса как аргументы, но мы не синтаксис тут обсуждаем =)

Добавлено 30.10.11, 11:49
P.S. а синтаксис без скобок используется в SmallTalk, Objective C, Ocaml и частично в Delphi и Ruby

[Flex Ferrum]

Цитата D_KEY @ 30.10.11, 11:36

Например?

Давай для начала определимся с сутью понятия. Для меня "свойство" - это видимый атрибут объекта, явным образом этим объектом публикуемый. Именно это я понимаю под "свойством". Теперь пример. Ты приходишь на психологический тренинг, и цепляешь себе на грудь бейдж со своим именем. Теперь у других участников тренинга нет нужды подходить к тебе и задавать вопрос "Как тебя зовут?" (you->GetName(). Они сразу смотрят на опубликованный тобою атрибут "Имя" (you->Name;). Другой пример. Разноцветная бумага. Цвет - "публикуемое свойство" у объекта "разноцветная бумага". Было бы странно, если бы ты, беря в руки очередной лист, спрашивал "Какой у тебя цвет?". Ты его и так видишь. Более приближенный к IT пример. Ты читаешь записи из БД. У каждой записи есть уникальный идентификатор и дата создания. Причём эти атрибуты являются частью публичного интерфейса (т. е. должны быть доступны клиентам). Ты можешь всякий раз спрашивать у объекта его идентификатор (obj->GetDbaseId()), а можешь просто его брать (obj->DbaseId). Тут именно семантическая разница.

[D_KEY]

Цитата Flex Ferrum @ 30.10.11, 12:22

Цитата D_KEY @ 30.10.11, 11:36

Например?

Давай для начала определимся с сутью понятия. Для меня "свойство" - это видимый атрибут объекта, явным образом этим объектом публикуемый. Именно это я понимаю под "свойством". Теперь пример. Ты приходишь на психологический тренинг, и цепляешь себе на грудь бейдж со своим именем. Теперь у других участников тренинга нет нужды подходить к тебе и задавать вопрос "Как тебя зовут?" (you->GetName(). Они сразу смотрят на опубликованный тобою атрибут "Имя" (you->Name;). Другой пример. Разноцветная бумага. Цвет - "публикуемое свойство" у объекта "разноцветная бумага". Было бы странно, если бы ты, беря в руки очередной лист, спрашивал "Какой у тебя цвет?". Ты его и так видишь.

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

Цитата

У каждой записи есть уникальный идентификатор и дата создания.

Почему бы тебе не запросить их через методы? Что дают тебе свойства?
Проблема-то в том, что к объекту нужно относится как к самостоятельной сущности, способный связываться с остальным "миром" посредством сообщений. Не приводит ли работа со свойствами к рассматрению объекта, как набору структур?

Цитата

Ты можешь всякий раз спрашивать у объекта его идентификатор (obj->GetDbaseId()), а можешь просто его брать (obj->DbaseId).

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

Сообщение отредактировано: D_KEY - 30.10.11, 12:56

[OpenGL]

По-моему, логично пользоваться одним синтаксисом для задания и для получения какого-либо свойства у объекта. Как это может ухудшать читабельность программы - ума не приложу.

[D_KEY]

Цитата OpenGL @ 30.10.11, 12:59

...для задания и для получения какого-либо свойства у объекта...

Ну так ты исходишь из того, что объект - это набор свойств. Естественно, что ты придешь именно к таким выводам

[korvin]

Цитата OpenGL @ 30.10.11, 12:59

По-моему, логично пользоваться одним синтаксисом для задания и для получения какого-либо свойства у объекта. Как это может ухудшать читабельность программы - ума не приложу.

у объектов нет свойств, у них есть поведение и может быть внутреннее состояние. а введение сущности, которая выглядит как поле, а ведет себя как метод -- дурная затея

Добавлено 30.10.11, 13:11

Цитата Flex Ferrum @ 30.10.11, 12:22

Давай для начала определимся с сутью понятия. Для меня "свойство" - это видимый атрибут объекта

давай. что такое атрибут объекта?

[OpenGL]

Цитата D_KEY @ 30.10.11, 13:09

Ну так ты исходишь из того, что объект - это набор свойств...

.. и методов, если смотреть на него снаружи. Что плохого в таком представлении?

Цитата korvin @ 30.10.11, 13:10

у объектов нет свойств, у них есть поведение и может быть внутреннее состояние. а введение сущности, которая выглядит как поле, а ведет себя как метод -- дурная затея

В чем дурная? Если я пишу oldLen=a.Length, мне неважно, вызывается там метод или нет, мне важно, чтобы в переменную записалось то, что я запросил.

[Flex Ferrum]

Цитата korvin @ 30.10.11, 13:10

давай. что такое атрибут объекта?

Некоторая часть его состояния.

Цитата D_KEY @ 30.10.11, 12:56

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

Ну, ты просил меня уточнить, какое это имеет отношение к реальности. Я и уточнил. А с такой точки зрения, которую ты привёл в первой части предложения, и между процедурным и ООП-подходом никакой разницы нет.

Цитата D_KEY @ 30.10.11, 12:56

Почему бы тебе не запросить их через методы? Что дают тебе свойства?

Это как в том анекдоте - жопа свойство есть, а слова языкового механизма нету. Вообще, геттеры и сеттеры - это своего рода самообман. Сначала встали в позицию "публичный интерфейс метода должен включать только методы", потом опомнились: "ой, а с видимой атрибутикой то что делать?", и ввели геттеры и сеттеры. В итоге, посмотришь на интерфейс иных классов (например), видишь туеву хучу геттеров и сеттеров, описывающих пару десятков свойств. А если ещё и в исходник взглянуть - так и вообще ахтунг, потому что для интеграции с дизайнером все те же самые свойства описываются и третий раз - посредством макросов. А потом и четвёртый - перечисляются соответствующие приватные мемберы. Зато слова нету, и всё правильно с точки зрения труъ-ООП.

Цитата D_KEY @ 30.10.11, 12:56

Проблема-то в том, что к объекту нужно относится как к самостоятельной сущности, способный связываться с остальным "миром" посредством сообщений. Не приводит ли работа со свойствами к рассматрению объекта, как набору структур?

А ты сам как считаешь? Ты когда последний раз дизайнил объект, который общается с "остальным миром" только посредством сообщений? Сколько у этого объекта было геттеров и сеттеров? Я, в свою очередь, считаю, что не приводит. Если работа со свойствами не нарушает инкапсуляцию - то и не должно приводить.

Добавлено 30.10.11, 13:50

Цитата korvin @ 30.10.11, 13:10

у объектов нет свойств

Ну да ладно. Ты где такие объекты последний раз видел?

[korvin]

Цитата Flex Ferrum @ 30.10.11, 13:49

Цитата korvin @ 30.10.11, 13:10

давай. что такое атрибут объекта?

Некоторая часть его состояния.

откуда такое определение? почему эта "некоторая часть состояния объекта" должна быть видна?

Добавлено 30.10.11, 15:05

Цитата Flex Ferrum @ 30.10.11, 13:49

Это как в том анекдоте - жопа свойство есть, а слова языкового механизма нету.

в ООП понятия свойства нет

Добавлено 30.10.11, 15:11

Цитата Flex Ferrum @ 30.10.11, 13:49

Вообще, геттеры и сеттеры - это своего рода самообман. Сначала встали в позицию "интерфейс объекта должен включать только методы"

это не самообман, а признак плохого проектирования и использования инструмента не по назначению.

Цитата Flex Ferrum @ 30.10.11, 13:49

потом опомнились: "ой, а с видимой атрибутикой то что делать?", и ввели геттеры и сеттеры.

не существует никакой видимой атрибутики.

Цитата Flex Ferrum @ 30.10.11, 13:49

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

как раз пример неправильного использования ООП и вообще. собственно со свойствами все тоже самое, только есть свойства, да

Добавлено 30.10.11, 15:14

Цитата Flex Ferrum @ 30.10.11, 13:49

Цитата korvin @ 30.10.11, 13:10

у объектов нет свойств

Ну да ладно. Ты где такие объекты последний раз видел?

навскидку не вспомню, но сам стараюсь так и писать

[Romkin]

Цитата Qraizer @ 29.10.11, 18:06

И что? Если у нескольких интерфейсов общий предок, их реализации не могут столкнуться с одинаковыми аттрибутами? Откуда принципиальная невозможность-то?

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

Цитата Qraizer @ 29.10.11, 18:06

Проблем множественного наследования реализаций не существует.

Цитата korvin @ 29.10.11, 19:17

доступ к сеттеру/геттеру через свойство -- это прямой доступ к сеттеру и геттеру (прямой вызов сеттера и геттера), т.о. свойство ничего не скрывает

Угу. Но сеттер и геттер - методы, а не поля данных. Или методы тоже ничего не скрывают? Тогда сразу говори, что данные вообще скрыть нельзя, поскольку ко всем данным объекта так или иначе есть доступ