Re[23]: Обновление
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.11.04 22:06
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>ЭТО ВСЕГО ЛИШЬ ВОПРОС ПРИВЫЧКИ.


Скорее безвкусия.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Oberon???????????????????????????????????
От: Вадим Никулин Россия Здесь
Дата: 04.11.04 09:59
Оценка:
Здравствуйте, prVovik, Вы писали:

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


LVV>>Кстати, какие альтернативы оберону есть, кто-нить представляет?

V>Java? На ней олимпиады проводятся?

Обман. см. здесь
Re[12]: Мэйнстрим vs. Самосовершенствование :)))
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.11.04 10:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>> Ты немного противоречишь САМ СЕБЕ.


VD>Где?


VD>>>Ну, не просто так в Яве и Шарпе остались continue и есть return. Та же Дельфи и Васик долго жили без них, но в итоге иVD> в них были добавлены эти конструкции. Вред этих конструкций высасан из пальца.

S>> Так, что и тебя понять очень сложно

VD>А ты уверен, что мне что-то сложно понять?

Нет тебя понять сложно когда ты говоришь что Delphi жил без continue и return.
S>> Всетаки не надо задевать огульно Delphi там, где его не знаешь .

VD>Где я ее задевал? А на счет не знаю. Я писал на дельфи 2-3 по более твоего. Просто вот уже лет 6 серьезно ею не занимался. Все не нужное со временем забывается.

Откуда ты взял такие данные????? Может мегабайтами кода будем мерятся.
VD>Но о Дельфи я в общем-то ничего и не говорил.
Выделил.
S>> А уж тем более ставить его в один ряд с Васиком, хотя к Васику у меня нет никаких претензий особенно фор Аппликатион, просто совершенно разные языки.

VD>Ну, ты как-нибудь определись с отношением. Дельфи и Васик среды/языки делящие одну рыночную нишу. И было бы глупо не ставить их в один ряд.

Отнюдь не так. Как по возможностям так и по архитектуре.
S>> Тогда лучше сравнивать ранний Паскаль с Ранним С. Во интересных сравнений найдется огромная куча.


VD>Небыло никакого раннего Паскаля. Был Паскль и его клоны вроде ТП и Дельфи.

Здесь ты тоже не прав, так как Паскаль для ДВК несколько отличался от Виртовского.
VD> С тут вообще никто не бсуждал. В общем, я так и не понял цель твоего влезания в разговор.
Я просто указал на то, что continue и есть return были в Delphi всегда и никак он без них не обходился.
Надо признавать ошибки. А не признавать только "лучшая защита это нападение".
... << RSDN@Home 1.1.3 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[3]: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.11.04 22:45
Оценка:
Здравствуйте, Вадим Никулин, Вы писали:

ВН>Обман. см. здесь


А на что там смотреть?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 00:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


V>>1) Можно ли этот ТР использовать для своих нужд, то есть не только для ремотинга?


AVK>Можно. Хотя "не для ремоутинга" не очень корректно говорить, поскольку TP это собственно ремоутинг и есть. Есть даже специальная штука для его использования в собственных нуждах в пределах одного домена — ContextBoundObject.


Думаю под словами "для ремоутинга" подразумевается "для обмена по сети или между процессами". В таком случае несомненно можно.

V>>2) А как оно работает? Через рефлекшн + эмит?


AVK>Что именно? Если вызов метода закрываемого класса, то по дефолту рефлекшен, хотя ты можешь придумать что то свое. Если трансляция в TP, то это unmanaged stub, даже джитом не обрабатываемый.


Кстати, на R#-пе такие вещи делаются очень легко и вообще без накладных расходов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 00:02
Оценка:
Здравствуйте, Undying, Вы писали:

U>Но компилятором эта ситуация отслеживается, т.е. особой проблемы не представляет, но естественно не понятно, почему делегирование нельзя ввести на уровень языка, вроде это не сложнее наследования (даже попроще, т.к. нет никаких проблем с разборками в каких случаях должен вызываться метод базового класса, а в каких его перегруженный вариант).


Согласен. У меня как раз в планах в качестве одной из демонстраций возможностей R# реализовать на нем миксины (типа импорт бленов одного класса другим).

Так же можно сделать и чистую делегацию, но смысла в этом особого не вижу. Если убедите в ее необходимости, прикручу и ее. Там делов на пару часов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 00:02
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Тоже дельное замечание. Я подразумевал статическую делегацию. Согласен, динамическая тоже вполне имеет право на жизнь.


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

Что мешает сдалать так (Шарп для простоты):
// Интерфейс в котором определяются методы для обратной связи
// с делегатором. Делегатор - это класс в котором будет 
// производиться делегировние.
interface IDelegator
{
    // описываем нужную функциональность делегатора. Например:
    string Name { get; }
    ...
}

// Интерфейс который должен реализовать объект которому
// делегируются вызовы.
interface IDelegate
{
    void Method1(IDelegator delegator, int data1);
    void Method2(IDelegator delegator, string data2);
    ...
}

// Реализация делегирующего объекта. Таких может быть поре.
class Delegator : IDelegator
{
    public IDelegate Delegate;
    
    public void Method1(int data1)
    {
        Delegate.Method1(Delegate, data1);
    }

    public void Method2(string data2);
    {
        Delegate.Method2(Delegate, data2);
    }
    
    private string IDelegator.Name { get { return "Вася"; } }

}

// Реализация приемника. Таких тоже может быть много.
class DelegateIml1 : IDelegate
{
    private void IDelegate.Method1(IDelegator delegator, int data1)
    {
        // делаем что хотим, если что используем делегатора.
        Console.WriteLine("Меня вызвал " + delegator.Name + " с параметром data1 = " + data1);
    }
    
    private void IDelegate.Method2(IDelegator delegator, string data2);
    {
        ...
    }
    ...
}
...
static void Main()
{
    Delegator delegator = new Delegator();
    
    DelegateIml1 del1 = new DelegateIml1();
    
    delegator.Delegate = del1;

    delegator.Method1(123);

    delegator.Delegate = new DelegateImlXxx();
    delegator.Method2("123");
}


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

Например, можно объявлять делегатора и реализоатора со специальным синтаксисом. Параметр со сылкой на делегатора сделать неявным, а ссылку на него получать приведением к интерфейсу IDelegator или вообще делать методы IDelegator-а виртуально доступными из реализатора. Погу попробовать по фантазировать:
// Интерфейс в котором определяются методы для обратной связи
// с делегатором. Делегатор - это класс в котором будет 
// производиться делегировние.
interface IDelegator
{
    // описываем нужную функциональность делегатора. Например:
    string Name { get; }
    ...
}

// Интерфейс который должен реализовать объект которому
// делегируются вызовы.
// Оставляем как есть, только удаляем delegator
interface IDelegate
{
    void Method1(int data1);
    void Method2(string data2);
    ...
}

// Реализация делегирующего объекта. Таких может быть поре.
// Поже оставляем как есть. Вместо в принципе интерфейса можно 
// использовать и основной класс.
class Delegator : IDelegator, delegate IDelegate
{
    private string IDelegator.Name { get { return "Вася"; } }
}

// Реализация приемника. Таких тоже может быть много.
// ключевое слово implementor означает, что этот класс 
// предназначен для реализации делегирования вызовов.
// при этом итерфейс указываемый непосредственно за ключевым
// словом неализуется классом и его методы вызваются при делегировании,
// а интерфейс указанный в скобках является инерфейсом обратной связи.
// Он неявно доступен в любом методе класса.
class DelegateIml1 : implementor IDelegate(IDelegator)
{
    private void IDelegate.Method1(int data1)
    {
        // делаем что хотим, если что используем предопределенное
        // ключевое слово delegator. Оно аналогично this, но
        // используется только для доступа к делегирующему объекту.
        Console.WriteLine("Меня вызвал " + delegator.Name + " с параметром data1 = " + data1);
        // Как вариант можно сделать члены интерфейса делеатора доступными 
        // неявно, т.е. без ключевого сова delegator.
        Console.WriteLine("Меня вызвал " + this.Name + " с параметром data1 = " + data1);
    }
    
    private void IDelegate.Method2(string data2);
    {
        ...
    }
    ...
}
...
static void Main()
{
    Delegator delegator = new Delegator();
    
    DelegateIml1 del1 = new DelegateIml1();
    
    delegator.Method1(123); // Исключение говорящее о том, что не бы подключен делекат.
    
    delegator.IDelegator = del1;

    delegator.Method1(123);

    delegator.IDelegator = new DelegateImlXxx();
    delegator.Method2("123");
}
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 05.11.04 00:14
Оценка:
VladD2:

> ПК> Тоже дельное замечание. Я подразумевал статическую делегацию. Согласен, динамическая тоже вполне имеет право на жизнь.


> Собственно я как-то не понял в чем у орла была проблема.


Если под "орлом" подразумевается Бьярн Страуструп, то проблема, которую он описывал, предложенным тобой способом не решается, т.к. среди ее условий, очевидно, есть и то, что класс, которому делегируются вызовы, понятия не имеет, что его захотят использовать в таком качестве.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[35]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 00:41
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>VladD2:


>> ПК> Тоже дельное замечание. Я подразумевал статическую делегацию. Согласен, динамическая тоже вполне имеет право на жизнь.


>> Собственно я как-то не понял в чем у орла была проблема.


ПК>Если под "орлом" подразумевается Бьярн Страуструп, то проблема, которую он описывал, предложенным тобой способом не решается, т.к. среди ее условий, очевидно,


Только тебе.

ПК>есть и то, что класс, которому делегируются вызовы, понятия не имеет, что его захотят использовать в таком качестве.


Где это требование? И зачем оно нужно?

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

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

Собственно, довольно бессмысленно скрывать от реализатора интерфейс IDelegator-а. Но можно все сделать так, чтобы в качестве делегата можно было бы использовать тип ничего не знающий о Delegator-е. В этом случае всего лишь не будет доступна ссылка на IDelegator. Так что это все отговорки. Просто видимо орел ненашел нормального решения и решил что МН будет за глаза хватать. Про интерфейсы, кстати, тогда вообще речь не шала. По-моему, в СФронт 1.0 даже виртуальных методов не было. А уж понятие интерфейса появилось только с DCE-RPC.

ЗЫ

Лучше бы он в том 87 подумал как сделать длегирование и миксины, а от МН отказался бы. Глядишь и разных Яв с Шарпами и не появилось бы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Oberon???????????????????????????????????
От: Soare  
Дата: 05.11.04 06:50
Оценка:
Salutare, LaptevVV, Вы писали:

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

Странная точка зрения..
У нас тоже были студенты из сел.. И за три семестра Си не Си, но уж основы то знали все.. даже я..
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[35]: Мэйнстрим vs. Самосовершенствование :)))
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.11.04 07:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, на R#-пе такие вещи делаются очень легко и вообще без накладных расходов.


Не все. Добавление к экземпляру на ходу скажем реализации интерфейса при помощи него не сделаешь.
... << RSDN@Home 1.1.4 beta 3 rev. 219>>
AVK Blog
Re[4]: Oberon???????????????????????????????????
От: poilk  
Дата: 05.11.04 07:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Вадим Никулин, Вы писали:


ВН>>Обман. см. здесь


VD>А на что там смотреть?


Видимо то, что на олимпиаде используют VC6, Delphi и Java.
Re[5]: Oberon???????????????????????????????????
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 18:31
Оценка:
Здравствуйте, poilk, Вы писали:

VD>>А на что там смотреть?


P>Видимо то, что на олимпиаде используют VC6, Delphi и Java.


И в чем обман? Да и вообще-то я так и не заметил требований к языкам и компиляторам.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 18:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Кстати, на R#-пе такие вещи делаются очень легко и вообще без накладных расходов.


AVK>Не все. Добавление к экземпляру на ходу скажем реализации интерфейса при помощи него не сделаешь.


А причем тут ход? Хотя можно и на ходу. Никто не мешат компилировать в рантайме. Собственно сам R# так и делает. Класс запускающий правла как раз генерируется на ходу, реализует интерфейс и запускается. Ну, разве что для повышения производительности кэшируется на диске, чтобы перекомпилироваться только при изменении исходников.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Мэйнстрим vs. Самосовершенствование :)))
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.11.04 20:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Кстати, на R#-пе такие вещи делаются очень легко и вообще без накладных расходов.


AVK>>Не все. Добавление к экземпляру на ходу скажем реализации интерфейса при помощи него не сделаешь.


VD>А причем тут ход? Хотя можно и на ходу. Никто не мешат компилировать в рантайме.


Влад, читай внимательнее. Я писал что интерфейсы можно менять у ЭКЗЕМПЛЯРА. Никакая компиляция тебе это сделать не поможет.
... << RSDN@Home 1.1.4 beta 3 rev. 224>>
AVK Blog
Re[17]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 21:09
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ага: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1585.pdf Но, судя по предварительным голосованиям, обсуждаемая здесь возможность, то есть вызов "свободных" функций через синтаксис функций-членов, пока особой поддержки в комитете не получила; скорее могут ограничиться разрешением вызова функций-членов через синтаксис "свободных" функций, если вообще какие-то изменения будут. В общем, поживем-увидим.


Это что пройдет еще лет десять и там вообще разума не остнется. За-то напринимают разной фигни окончательно усложняющей язык.

А идея в общем-то не плохая. Что бы вы там не говорили, а проблемы реализации это для неудачников. Рельно ЯП создан, чтобы не нем выражать свои мысли. И я хочу мыслить в понятиях объектов и действий над ними, а не структурных конструкций.

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

Интерпретация первого параметра как self/this тоже могло быть выходом. Но это неявное поведение. Тогда бы уж добавить некое финсированное название параметра (то же self/this), чтобы явно выражать намерение. Тольк опять таки это банальная реализация методов во-вне. В принципе, дорасширение классов не такая уж и плохая диея. Хотя и протеворечащая классике ООП.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 21:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Влад, читай внимательнее. Я писал что интерфейсы можно менять у ЭКЗЕМПЛЯРА. Никакая компиляция тебе это сделать не поможет.


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

Ты вот приведи пример где я не смогу обойтись компиляцией в рантайме?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Мэйнстрим vs. Самосовершенствование :)))
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.11.04 21:59
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Влад, читай внимательнее. Я писал что интерфейсы можно менять у ЭКЗЕМПЛЯРА. Никакая компиляция тебе это сделать не поможет.


VD>Ну, уж менять реализацию прямо у экземпляра точно смысла нет.


Это уже второй вопрос. Главное что ограничение есть.

VD>Ты вот приведи пример где я не смогу обойтись компиляцией в рантайме?


Качественно СОМ к примеру не обернешь.
... << RSDN@Home 1.1.4 beta 3 rev. 224>>
AVK Blog
Re[40]: Мэйнстрим vs. Самосовершенствование :)))
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.11.04 23:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Качественно СОМ к примеру не обернешь.


Так TlbImp.exe именно это и делает.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Мэйнстрим vs. Самосовершенствование :)))
От: Павел Кузнецов  
Дата: 06.11.04 01:10
Оценка:
VladD2:

> ПК> вызов "свободных" функций через синтаксис функций-членов, пока особой поддержки в комитете не получила; скорее могут ограничиться разрешением вызова функций-членов через синтаксис "свободных" функций, если вообще какие-то изменения будут. В общем, поживем-увидим.


> Это что пройдет еще лет десять и там вообще разума не остнется. За-то напринимают разной фигни окончательно усложняющей язык.


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

> Рельно ЯП создан, чтобы не нем выражать свои мысли. И я хочу мыслить в понятиях объектов и действий над ними, а не структурных конструкций.


Значит, надо искать такой язык, который тебе позволяет это делать удачнее всего. Мне же, с моим предпочтением использования смеси парадигм, C++ пока вполне подходит.

> В принципе, дорасширение классов не такая уж и плохая диея. Хотя и протеворечащая классике ООП.


Если, как в указанном предложении, добавляемые функции не будут получать специальных прав доступа к содержимому класса, то "классика" сможет спать спокойно
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.