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

[D_KEY]

Цитата korvin @ 15.03.11, 10:39

Цитата D_KEY @ 15.03.11, 10:26

korvin, еще раз, в чем разница между предоставлением доступа к методам get/set и доступом "к самому объекту", если ты с объектом все-равно ничего сделать не сможешь, кроме get и set?

get/set -- это условно, мне лень было придумывать кучу методов. разница в невозможности изменить часть объекта независимо от объекта, т.е. взять "адрес" на внутренний объект, передать куда-то и где-то там менять.

Что-то странное мутишь
Но можно сделать, как Мяут показал - хранить "методы" такого доступа в качестве функциональных полей объекта и мапить их на нужные методы нужных объектов.

Добавлено 15.03.11, 11:25
korvin, все-таки, зачем все это городить?

[korvin]

мне и не нужно городить, ты мой пример на яве видел? Где там огород? =)

[D_KEY]

Цитата korvin @ 15.03.11, 12:27

мне и не нужно городить, ты мой пример на яве видел? Где там огород? =)

А он у тебя там работающий, а?
Ты можешь в двух словах объяснить, зачем это нужно? Может ты какую идиому интересную придумал, которая этого требует, а от простого трудового народа скрываешь

[korvin]

Цитата D_KEY @ 15.03.11, 12:40

А он у тебя там работающий, а?

нет конечно, это пример как оно должно выглядеть(с поправкой на жабосинтаксис) и работать

[D_KEY]

Цитата korvin @ 15.03.11, 12:48

Цитата D_KEY @ 15.03.11, 12:40

А он у тебя там работающий, а?

нет конечно, это пример как оно должно выглядеть(с поправкой на жабосинтаксис) и работать

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

[Мяут-Настоящий]

Поддерживаю D_KEY.
Господа, может пора прекратить требовать реализации оторванных от реальности языковых возможностей и перейти к реализации завершенных и целостных языковых концепций?

[korvin]

Цитата Мяут-Настоящий @ 15.03.11, 13:06

Поддерживаю D_KEY.
Господа, может пора прекратить требовать реализации оторванных от реальности языковых возможностей и перейти к реализации завершенных и целостных языковых концепций?

это каких например?

[IL_Agent]

Цитата Qraizer @ 14.03.11, 15:10

Цитата IL_Agent @ 14.03.11, 09:26

В C# это не так. При реализации придётся явно указать, от какого интерфейса взят метод.

Вот это уже интереснее. Требуется явная квалификация? А когда? Всегда или только при коллизиях?

Ну да, я так и написал: требуется явно указать, какому именно интерфейсу принадлежит реализуемый метод.
Можно указывать интерфейс при реализации любого метода, при коллизиях это необходимо.
Пример приводился:

Цитата MyNameIsIgor @ 14.03.11, 10:10

Например, так

    using System;
    
    interface IA
    {
      void f();
    }
    
    interface IB
    {
      void f();
    }
    
    class A : IA, IB
    {
      void IA.f() { Console.WriteLine("IA.f"); }
      void IB.f() { Console.WriteLine("IB.f"); }
    }
    
    class Program
    {
      public static void Main(string[] args)
      {
        A a = new A();
        (a as IA).f();
        (a as IB).f();
      }
    }

[korvin]

Цитата D_KEY @ 15.03.11, 13:01

Вот я и спрашиваю, зачем это нужно языку программирования?

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

Добавлено 15.03.11, 16:39

Цитата Мяут-Настоящий @ 15.03.11, 13:06

Поддерживаю D_KEY.
Господа, может пора прекратить требовать реализации оторванных от реальности языковых возможностей и перейти к реализации завершенных и целостных языковых концепций?

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

[D_KEY]

Цитата korvin @ 15.03.11, 16:02

Цитата D_KEY @ 15.03.11, 13:01

Вот я и спрашиваю, зачем это нужно языку программирования?

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

Это-то понятно Зачем это? Ты посылаешь объекту сообщение и получаешь результат.
И я не зря тебе говорил про LoD...

[korvin]

Цитата D_KEY @ 15.03.11, 16:48

Это-то понятно Зачем это? Ты посылаешь объекту сообщение и получаешь результат.

class A {
    public void foo () {}
    public void bar () {}
}

ну смотри, по сути тут просто наследование:

class B extends A {
    public void gee () {}
}

и все, сам A внутри B невиден, но его методы доступны. но мне-то нужно два(или больше) объекта A внутри B

вариант второй:

class B {
    private A x = new A();
    private A y = new A();
 
    public void x_foo () {
        x.foo();
    }
    public void x_bar () {
        x.bar();
    }
    public void y_foo () {
        y.foo();
    }
    public void y_bar () {
        y.bar();
    }
}

итого получаем необходимость описывать n*m методов-оберток, где n -- количество полей объектов, m -- количество методов в классе поля-объекта

Цитата D_KEY @ 15.03.11, 16:48

И я не зря тебе говорил про LoD...

о, забыл по ссылке сходить, ща гляну

[Qraizer]

Цитата DesweR @ 15.03.11, 06:43

ИМХО тут как раз место агрегации.

Аргументируй, плз. Я к примеру не вижу логики в том, чтобы использовать именно агрегацию. Этот компонент будет реализовывать оба эти интерфейса, а не использовать их. Агрегации тут ИМХО не место.

Цитата DesweR @ 15.03.11, 06:43

Если забыл, в Delphi есть штатные средства для решения таких коллизий.

Не забыл. Знаю, есть. Только та фраза относилась не к моему вопросу о разрешении коллизий, а твоему (точнее korvin-а) примеру о невозможности вызова A.f, если есть IB.f, причём никакой AS тут не поможет. Как обычно ты попробовал что-то сказать лишь бы что-то сказать.

Цитата DesweR @ 15.03.11, 06:43

Это отчасти вытекает из идеологии COM'а ... а для этого класс A, должен содержать реализацию интерфейсов и child и parent.

И? Ты сказал то же, что и я. Почему, если А реализует и parent в частности, то его нельзя передать в функцию, принимающую интерфейс parent? Или Shaggy что-то путает?

Цитата DesweR @ 15.03.11, 06:43

?

Ты действительно этого хочешь? Пошагово?

class ISome1 {/* ... */};                // интерфейс1
class ISome2 {/* ... */};                // интерфейс2
class Some1 : public ISome1 {/* ... */}; // одна из реализаций первого
class Some2 : public ISome2 {/* ... */}; // одна из реализаций второго
 
void f(ISome1&);                         // Функция принимающая интерфейс. Одной хватит для демонстрации идеи.
 
class SuperSome : public Some1, public Some2 {/* ... */};  // "компонент", собранный из готовых кирпичиков
 
int main()
{
  SuperSome object;
 
  f(object);
}

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

class ISome1 {/* ... */};
class ISome2 {/* ... */};
class Some1 : public ISome1 {/* ... */};
class Some2 : public ISome2 {/* ... */};
 
void f(ISome1&);
 
class SuperSome
{
  Some1 s1;                              // "реализация" первого
  Some2 s2;                              // "реализация" второго
/* ... */
};
 
int main()
{
  SuperSome object;
 
  f(object);   // Опа-на, fail.
}

На Плюсах я могу решить эту проблему несколькими способами. Например, так:

class SuperSome : public ISome1, public ISome2 {/* ... */};  // "компонент", собранный из интерфейсов
{
  Some1 s1;
  Some2 s2;
/* ... */
public:
  operator ISome1&() { return s1; }
};

Или так:

class SuperSome : public ISome1, public ISome2 {/* ... */};
{
  Some1 s1;
  Some2 s2;
/* ... */
public:
  ISome1& getISome1() { return s1; }
};
/* ... */
  f(object.getISome1());

Или даже так:

class SuperSome : public ISome1, public ISome2 {/* ... */};
{
public:
  Some1 s1;
  Some2 s2;
/* ... */
};
/* ... */
  f(object.s1);

Все они неполноценны. Хотя бы потому, что ни полимофизм, ни dynamic_cast<> через границы агрегированных объектов тут работать не будут. Вернее, полиморфизм-то будет, но только у каждого в своей ветке Superобъекта. И это можно решить, только уже не так просто. Подозреваю, что решать придётся в духе VCL, с полями парентовых контролов, динамическими методами сиречь штрафами в run-time, счётчиками ссылок на чиелдов итп. А всё почему? Задокументировав "явление" собой обоих этих интерфейсов, реализация в этой документированности врёт. Она ими не "является", она их использует.
Вот я и спрашиваю, действительно "сложность" множественного наследования реализаций того стоила, чтобы от неё отказываться? Первый-то вариант идеален.
IL_Agent, кульно. А вот касательно

Цитата IL_Agent @ 15.03.11, 13:45

Пример приводился:...

не понял. Таки AS работает? Хто обманывает? Или чего я не учёл?

[D_KEY]

Цитата korvin @ 15.03.11, 17:05

итого получаем необходимость описывать n*m методов-оберток, где n -- количество полей объектов, m -- количество методов в классе поля-объекта

Ты описываешь классы, как контейнеры с кучей полей... Это как-то больше напоминает Сишные структуры, чем классы...

[korvin]

Цитата D_KEY @ 15.03.11, 16:48

И я не зря тебе говорил про LoD...

Цитата

Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

дык я это и предлагаю, вместо того, чтобы делать конкретные обертки (т.е. классу-контейнеру уже нужно знать, какие методы есть у внутреннего класса), просто разрешить доступ к интерфейсу объекта, но не позволяем внешнему коду работать с этим внутренним объектом "за спиной" у контейнера =)

Добавлено 15.03.11, 17:12

Цитата D_KEY @ 15.03.11, 17:09

Ты описываешь классы, как контейнеры с кучей полей... Это как-то больше напоминает Сишные структуры, чем классы...

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

[Qraizer]

Цитата korvin @ 15.03.11, 17:05

но мне-то нужно два(или больше) объекта A внутри B

Та скажи ж ты им, наконец, как ты хочешь "два(или больше) объекта A" отличать друг от друга. Синтаксически. Вон, DesweR "догадался" нумеровать. Мне тоже более изящного решения в голову не приходит.