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

Цитата Flex Ferrum @ 03.11.11, 09:30

А зачем она тебе?

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

Цитата D_KEY @ 03.11.11, 09:36

Ничего страшного не вижу, но и смысла такого действия не понимаю.

Цитата Romkin @ 03.11.11, 09:31

Не к предку, а так принцип похож.

Господа, я же специально оговорился

Цитата MyNameIsIgor @ 03.11.11, 09:28

переводя на твой пример

Цитата korvin @ 03.11.11, 09:44

но весь смысл сабтайпинга на смарку =)

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

Цитата

Цитата D_KEY @ 03.11.11, 09:41

Уверен? Мне казалось, что я так делал. Пойду читать
Если ты прав, то спасибо за поправку

уверен. проверено в IDEA =)

Может и в C# тогда нельзя?
Вообще странное поведение.

Добавлено 03.11.11, 09:54

Цитата Romkin @ 03.11.11, 09:47

у него идет подсчет ссылок

Я вот одного не понимаю, почему в Delphi интерфейсы смешали с подсчетом ссылок?

Цитата D_KEY @ 03.11.11, 09:52

Я вот одного не понимаю, почему в Delphi интерфейсы смешали с подсчетом ссылок?

Да там и COM смешали с языком... . И паттерны смешали с языком... . И много что смешали.

Цитата D_KEY @ 03.11.11, 09:52

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

да фигня какая-то имхо.

Цитата D_KEY @ 03.11.11, 09:52

Может и в C# тогда нельзя?
Вообще странное поведение.

почему странное? приватные мемберы класса доступны только ему, защищенные -- ему и наследникам, публичные -- всем

Цитата MyNameIsIgor @ 03.11.11, 09:51

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

Ну, сам этот класс должен быть известен на этапе построения диспатчера. Так? Значит и thunk-и ты можешь для него прописать заранее. А они, в свою очередь, могут работать по-разному в зависимости от наличия загруженного плагина. Таким образом, диспетчер остаётся полностью статически-типизируемым.

Цитата korvin @ 03.11.11, 09:57

приватные мемберы класса доступны только ему, защищенные -- ему и наследникам, публичные -- всем

Именно так. Доступа к методу у тебя нет, но перекрытие не является формой доступа

class A
{
public:
    void f()
    {
        f1();
        f2();
        f3();
    }
 
protected:
    virtual void f1();
 
private:
    virtual void f2()
    virtual void f3();
 
};
 
class B : public A
{
public:
    //...
 
protected:
    virtual void f1()
    {
        // имеем доступ к A::f1
    }
 
private:
    virtual void f2()
    {
        // НЕ имеем доступ к A::f2
    }
 
    virtual void f3()
    {
        // НЕ имеем доступ к A::f3
    }
};

Как мне обеспечить это в Java/Delphi? Зачем предоставлять дополнительный доступ, если требуется лишь возможность перекрытия?

Сообщение отредактировано: D_KEY - 03.11.11, 10:06

Цитата Flex Ferrum @ 03.11.11, 10:01

Ну, сам этот класс должен быть известен на этапе построения диспатчера. Так?

При построении плагина - да. Приложения - нет. В приложении я только знаю, что мне из плагина отдадут наследника какого-то базового класса.

Цитата D_KEY @ 03.11.11, 10:06

Цитата korvin @ 03.11.11, 09:57

приватные мемберы класса доступны только ему, защищенные -- ему и наследникам, публичные -- всем

Именно так. Доступа к методу у тебя нет, но перекрытие не является формой доступа

class A
{
public:
    void f()
    {
        f1();
        f2();
        f3();
    }
 
protected:
    virtual void f1();
 
private:
    virtual void f2()
    virtual void f3();
 
};
 
class B : public A
{
public:
    //...
 
protected:
    virtual void f1()
    {
        // имеем доступ к A::f1
    }
 
private:
    virtual void f2()
    {
        // НЕ имеем доступ к A::f2
    }
 
    virtual void f3()
    {
        // НЕ имеем доступ к A::f3
    }
};

Как мне обеспечить это в Java/Delphi? Зачем предоставлять дополнительный доступ, если требуется лишь возможность перекрытия?

в смысле? т.е. при вызове B::f() будет вызван B::f2(), а не A::f2()?

Цитата korvin @ 03.11.11, 10:15

в смысле? т.е. при вызове B::f() будет вызван B::f2(), а не A::f2()?

Да.

Добавлено 03.11.11, 10:18
В тему свойств, наткнулся на цитату Джефри Рихтера

Цитата

Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутствующих языков программирования. Причина в том, что свойства выглядят как поля, на самом деле являясь методами

Цитата D_KEY @ 03.11.11, 10:06

...
 
class B : public A
{
    ...
 
protected:
    virtual void f1()
    {
        // имеем доступ к A::f1
    }
...
};

нет, в Java мы не имеем доступ к A::f1.

Цитата scorpion @ 03.11.11, 09:51

И когда как? Пример можно привести? Зачем тогда нужен интерфейс с дополнительным функционалом?

Для использования интерфейсов в Delphi есть несколько дизайн-паттернов, каждый выбирается в конкретном случае.
1. Есть подсчет ссылок/нет подсчета
2. Интерфейс агрегирован, содержится или реализован напрямую
3. Есть публичные методы или нет
и так далее. Все достаточно разнообразно.
Если объект основной, то как правило у него есть свой функционал и нет подсчета ссылок, интерфейсы - дополнительные функции, например для системы сохранения/загрузки или управления транзакцией или получения дополнительной информации.
Если работа через интерфейсы, то опять же как правило делают подсчет ссылок и закрывают все методы кроме служебных, это еще и страховка: в Delphi нет явных способов понять что объект уже уничтожен. В этом случае подразумевается что функционал не знает с каким именно объектом он работает.
Ну и естественно возможны другие варианты.

Цитата D_KEY @ 03.11.11, 09:52

Я вот одного не понимаю, почему в Delphi интерфейсы смешали с подсчетом ссылок?

Почему нет? Впрочем, ответ простой, изначально они появились из-за поддержки COM, а потом так и осталось.

Цитата D_KEY @ 03.11.11, 10:06

Как мне обеспечить это в Java/Delphi?

Эээ. Через свойства подобное можно сделать.

Или нет. Вроде нельзя, по крайней мере в голову ничего путного не приходит.

Сообщение отредактировано: Romkin - 03.11.11, 10:27

Цитата korvin @ 03.11.11, 10:22

нет, в Java мы не имеем доступ к A::f1.

Ы? А как жеж?

super.f1()

Цитата D_KEY @ 03.11.11, 09:52

Может и в C# тогда нельзя?

Вроде там идет ошибка компиляции при попытке создания закрытого виртуального/абстрактного метода. Проверить не могу.

Цитата D_KEY @ 03.11.11, 10:17

Да.

не нравится мне это =)

Цитата D_KEY @ 03.11.11, 10:17

В тему свойств, наткнулся на цитату Джефри Рихтера

Цитата

Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутствующих языков программирования. Причина в том, что свойства выглядят как поля, на самом деле являясь методами

молодец Рихтер, всё правильно сказал

Добавлено 03.11.11, 10:26

Цитата MyNameIsIgor @ 03.11.11, 10:24

Цитата korvin @ 03.11.11, 10:22

нет, в Java мы не имеем доступ к A::f1.

Ы? А как жеж?

super.f1()

private-метод нельзя так вызвать

Цитата korvin @ 03.11.11, 10:25

private-метод нельзя так вызвать

Так он protected

Добавлено 03.11.11, 10:29
У D_KEY'я A::f1 - защищённый, а не приватный.