Ответ на »сообщение 4149« (sdf)
___________________________
Тю! да тут клиника в полный рост...
Извините.

Ответ на »сообщение 4147« (info21)
___________________________
Ну что нам, "Молот Ведьм" с полки доставать? - не томите душу, колитесь, раз уж запустили инфу! :о)

Ответ на »сообщение 4146« (Владимир Лось)
___________________________

Если бы было просто, то, например, товарищи из Еврофайтера не выбрали бы для некоторых подсистем своего самолёта Аду вместо Явы (да-с, и такие планы рассматривались). И одной из основных причин было то, что Ада выбрасывает исключение, если в case (switch в Яве) не были проанализированы все значения переменной из заданного типа перечисления...

Так, что "ничо до, ничо после" – это, скорее всего, всё-таки "точка зрения отдельных лиц раннепостпионерского возраста"... :о)

ну ну. попробуйте представить на минутку што я сделал свой язык. в нем есть enumeration и для оного тока операция сравнения. представили? ай молодца! а теперича представьте што я запрещаю case. оного у меня нету. опять представили. молодцом! чо теперича скажите? што у меня в моем языке чой-то есть но не тип? ну ну. жду пожду вашей реализации мово типа на C++. слово не воробей.

Ну да! В рамках вашего восприятия реализаций ООП в языках, - именно так.
Но всё дело в том, что, узнавать что-либо про другие языки у вас времени нет, потому от вашего внимания ускользнуло, что в Self как-то без классов обходятся (хотя сами авторы считают его пост-Смолтоком)...

вы мне мозги не полоскайте. с чего взяли што я языков других не знаю? кода говорили про объекты не оговаривались насчот особых случаев. подставились с объектами а теперича выкручиваетесь. ну ну

Откуда знания, если времени на самообразование, сами же сказали, не густо?

ткните своим пальцем где я такое ляпнул. али опять чото попутали?

Или вам неуютно, что кто-то покушается на цельность картины вашего мирка?

правда глазки колет? а откель взяли што у меня мирок? фантазии разыгрались?

Теперь я знаю, что говорить отпрыскам, на счёт того, какую аргументацию они должны "развивать" перед учителем по русскому языку после двойки... :о)

што есть. у одних пышная форма а содержания пшик. кот наплакал. у других наоборот.


Выпендрёж это когда заучили пару положений из "цитатника Мао"

выпендреж енто кода свое я лезет так наружи што дальше некуда. один тут умник начал мозги полоскать насчот глупых бучей. свое имя впендюрил в название конторы. а сам в жизни окромя автоматизации ничо не делал. одни кисы. игры крутые делал? неа. а там ооп покруче. имитационное моделирование отдыхает. а говорите мао. тормозните и пораскиньте мозгами. туфту гоните воткрытую

Ответ на »сообщение 4147« (info21)
___________________________
А что за компания?

Ответ на »сообщение 4145« (SAGE)
___________________________

Ответ на »сообщение 4144« (info21)
___________________________

Крупный производитель дисковых систем (NAS) только что сообщил о переводе firmware всех своих storage-продуктов на Оберон.
Из какого источника получена информация?

От Chief Executive Officer компании.

Ответ на »сообщение 4143« (sdf)
___________________________
я отличаю по имени. за ним стоит набор значений. окромя равно и неравно мне не нужно в ентом типе ничо. ничо до ничо опосля. вы хотите построить к ентому типу интерфейс? вперед а я погляжу. могете даже на одном языке.

Ну вот и – всё... :о)

" - ... и очень просто.
  - ... и вы напрасно говорите, что это очень просто! Это – ОЧЕНЬ не просто."
                                (с) из "Собачьего сердца"

Если бы было просто, то, например, товарищи из Еврофайтера не выбрали бы для некоторых подсистем своего самолёта Аду вместо Явы (да-с, и такие планы рассматривались). И одной из основных причин было то, что Ада выбрасывает исключение, если в case (switch в Яве) не были проанализированы все значения переменной из заданного типа перечисления...

Так, что "ничо до, ничо после" – это, скорее всего, всё-таки "точка зрения отдельных лиц раннепостпионерского возраста"... :о)

Наличие у объекта возможности предоставить какую-то операцию – конкретное свойство объекта.
да ну? я по простоте душевной думал што операции объявляет класс а не объект. к свойствам объектов не имеет ваще отношения. ну а объекты штампуют по заготовке. классом называется.
Ну да! В рамках вашего восприятия реализаций ООП в языках, - именно так.
Но всё дело в том, что, узнавать что-либо про другие языки у вас времени нет, потому от вашего внимания ускользнуло, что в Self как-то без классов обходятся (хотя сами авторы считают его пост-Смолтоком)... И в Io...
Простота, она, знаете, говорят, хуже воровства, случается... :о)

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

Если вы заглянете в САМЫЕ первые сообщения, то увидете, что мной как раз и было высказано пожелание не только об обероне здесь говорить
а чо тода не назвали тему просто "мысли об" ? про мой копирайт потом не забудьте.
Не забуду, конечно. Теперь всегда, когда будет начинаться очередная "сказка про белого бычка" – обязательно его ставить буду... :о)

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

кода цитируете смотрите внимательнее. я дефисы не ставлю. енто мой стиль.
Теперь я знаю, что говорить отпрыскам, на счёт того, какую аргументацию они должны "развивать" перед учителем по русскому языку после двойки... :о)

Ответ на »сообщение 4144« (info21)
___________________________

Крупный производитель дисковых систем (NAS) только что сообщил о переводе firmware всех своих storage-продуктов на Оберон.
Из какого источника получена информация?

Крупный производитель дисковых систем (NAS) только что сообщил о переводе firmware всех своих storage-продуктов на Оберон.

Ответ на »сообщение 4141« (Владимир Лось)
___________________________

Для чего обычно в ЯП служит тип перечисления?
Как вы отличаете "этот" тип перечисления от "того"? Не только текстуально, но во время выполнения программы?
Какие операции "общепринято" производить над переменными того или иного "типа" перечисления?

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

Наличие у объекта возможности предоставить какую-то операцию – конкретное свойство объекта.

да ну? я по простоте душевной думал што операции объявляет класс а не объект. к свойствам объектов не имеет ваще отношения. ну а объекты штампуют по заготовке. классом называется.

Я не пойму, почему такое высокомерие

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

Если вы заглянете в САМЫЕ первые сообщения, то увидете, что мной как раз и было высказано пожелание не только об обероне здесь говорить

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

Вы что думаете, здесь народ на почве ООП схлёстывается единственно по причине недостатка знаний в этой области? "три ха-ха"(с) sdf........

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

Ответ на »сообщение 4139« (hugi)
___________________________
Владимир, у меня к Вам одна ма-а-а-аленькая просьба: если можно, в следующий раз потрудитесь, пожалуйста, если уж приводите пример, пояснять его. Просто времени сейчас в обрез, и тратить его на ковыряние в Limbo, нет ну решительно никакой возможности. Мне кажется, я понял Вашу мысль, но уверенности в этом нет.
А что там было сложного? Если вы знакомы с мирами Си, Паскаля и (совсем цуть-цуть) Лиспа – то там всё прозрачно...
Ну так у меня тоже "нет времени". Но кто хочет – ищет возможности, кто не хочет – причины. С некоторых пор я понял, что ознакомление (хотя бы и поверхностное!) с как можно большим количеством ЯП вдруг начинает давать кумулятивный эффект при решении задач. Вы начинаете просто видеть вашу задачу под разными углами зрения... И находить решения, которые было бы трудно отыскать, находись вы только в одной языковой среде и парадигме.

В приведённых мной способах тоже никаких особых синтаксических конструкций не требовалось.
Да? А каким образом вы будете "удовлетворять компилятор" на предмет принадлежности конкретного класса к классу (интерфейсу) "Умеющих Летать"? :о)

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

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

А что такое класс, как не "держатель интерфейсов", он ведь и так предоставляет определённый интерфейс, просто концепция Интерфейсов (буду писать с большой буквы, чтобы избежать путаницы) позволяет сделать иерархию классов более гибкой, накладывая  на неё иерархию интерфейсов. А отличаться классы будут тем же, чем всегда отличались. Класс Птица отличен от класса ВоздушныйШар, хотя и тот и другой умеют летать (реализуют интерфейс УмеющийЛетать).
Наложение будет "1-в-1"? И де тут гибкость? :о)
УмеющийЛетать описывает некоторую функциональность позволяющую причислить АНАЛИЗИРУЕМЫЙ объект именно к этому классу. Так?
Вернёмся к примеру с сортировкой из Лимбо. Если следовать вашему подходу (принятому в массах на сегодняшний день), то сортируемые элементы ДОЛЖНЫ поддерживать интерфейс Сортируемый, в котором есть функция сравнения этих элементов. Что мы сделаем, например в Си++ или Яве, что бы включить этот интерфейс в состав класса? Унаследуем от абстрактного класса (Си++) или объявим, что ваш класс реализует данный интерфейс (Ява). Мы просто не сможем иначе "уговорить" компилятор в выполнении своих желаний на получение полиморфности.
А в Лимбо, компилятор вполне удовлетворится, если подставляемый объект просто будет иметь в своём наборе функций подходящую под конкретные в данном месте кода требования ...
Смотрите, какой интересный эффект получается: выходит, что как раз Лимбо ближе приближен к моделированию "реальной жизни". Ведь в природе, как таковой, классификаций нет, это мы такую (искусственную!) классификацию придумываем. Так и в Лимбо – мы МОЖЕМ думать, что данный объект МОЖЕТ БЫТЬ ПРИЧИСЛЕН к определённому классу, потому, что он имеет какую-либо функциональность (или их совокупность), но классов, как таковых в языке НЕТ. Есть просто конкретные локальные требования:

пример из Лимбо может быть переписан и так:

mergesort[Sortable, AnyType](s: Sortable, a, b: array of AnyType)
    for{  Ssortable =>  gt: fn(s: self Ssortable, x, y: AnyType): int;  }
{
    ...
      {  if(s.gt(b[i], b[j]))  a[k] = b[j++];
            else  a[k] = b[i++];
        }
    ...
}

То есть, первый аргумент функции может быть ЛЮБОГО АТД, в котором будет затребованная функция:

# один АТД
OurType1: adt {
    ....
    gt: fn(s: self OurType, x, y: int): int;
    ...
};

# второй АТД
OurType2: adt {
    ....
    gt: fn(s: self OurType2, x, y: string): int;
    ...
};


# объявления
our_adt1_var: OurType1;
int_arr1, int_arr2: array of int;

our_adt2_var: OurType2;
str_arr1, str_arr2: array of string;
....
# использование
result1 := mergesort(our_adt1_var, int_arr1, int_arr2);
result2 := mergesort(our_adt2_var, str_arr1, str_arr2);
...

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

Ещё раз повторюсь: из высказанных мной соображений НИ В КОЕЙ МЕРЕ нельзя сделать вывод, что я против подходов ООП. Я лишь имею очень смутное подозрение, что в процессе развития, ООП сделало слишком быстрый переход "в обобщение" – в безоговорочную  прямую применимость результатов классификации для построения дерева наследования "классов",что не всегда (или почти никогда не) приводит к адекватным гибким решениям для расширяемых систем...

Вы о чём, вообще? Какая система поддержки времени? Ничего не понимаю...
Система поддержки времени выполнения.

Господа, задавайте себе вопросы, крутите, "мусольте" тему. Смотрите на неё так и эдак... Никто не сказал, что знания задаются на века. Всё текёть, всё зминюеться...
К Вам это тоже относится...
Как видите, стараюсь, в меру сил и времени... :о)