DG>Имхо, хорошая статическая типизация — это такая типизация, в которой можно по-максимуму задать ограничения на этапе компиляция. DG>Замечу, что текущие языки не умеют "работать" даже с базовыми вещами. DG>Пример 1: DG>Определить функцию, которая принимает объект, который должен поддерживать и интерфейс IA, и интерфейс IB. DG>Такое ограничение можно записать только с помощью generic-ов: DG>
DG>void Method<T>(T value) where T:IA, IB {}
DG>
DG>Пример 2: DG>Определить функцию, которая принимает объект, или типа C1, или типа C2. DG>Такой пример даже с помощью generic-ов не записывается.
В Оберонах это есть. Вот, например, в Active Oberon for .NET
VAR x: OBJET;
y: OBJECT{D};
x — переменная, которая может обозначать любой объект.
y — переменная, которая может обозначать любой объект реализующий интерфейс D. (Точнее не интерфейс, а DEFINITION — это нечто более крутое чем интерфейс, но в частном случае, может рассматриваться как интерфейс.)
PROCEDURE DoSmth(VAR x: OBJECT; VAR y: OBJECT{D, E});
У процедуры DoSmth первый аргумент x — любой объект; второй аргумент y — любой объект реализующий интерфейсы D и E одновременно.
Здравствуйте, S.Yu.Gubanov, Вы писали: DG>>Определить функцию, которая принимает объект, или типа C1, или типа C2. DG>>Такой пример даже с помощью generic-ов не записывается. SYG>В Оберонах это есть. Вот, например, в Active Oberon for .NET
Неправда. Перечитай внимательно задачу. SYG>У процедуры DoSmth первый аргумент x — любой объект; второй аргумент y — любой объект реализующий интерфейсы D и E одновременно.
Такое есть и в C#2.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: К вопросу о "static typing" vs "dynamic typing"
DG>>Имхо, хорошая статическая типизация — это такая типизация, в которой можно по-максимуму задать ограничения на этапе компиляция. DG>>Замечу, что текущие языки не умеют "работать" даже с базовыми вещами. DG>>Пример 1: DG>>Определить функцию, которая принимает объект, который должен поддерживать и интерфейс IA, и интерфейс IB. DG>>Такое ограничение можно записать только с помощью generic-ов: DG>>
DG>>void Method<T>(T value) where T:IA, IB {}
DG>>
DG>>Пример 2: DG>>Определить функцию, которая принимает объект, или типа C1, или типа C2. DG>>Такой пример даже с помощью generic-ов не записывается.
Кстати, в Haskell'е возможны обе эти операции. Правда, 2-й случай ценой ошибок типа во время выполнения и ограничения типов до специального подмножества (неполиморфных типов).
1)
method:(IA a, IB a)=>a->a
method x = x
2)
import Data.Typeable
makeF2::(Typeable a, Typeable b, Typeable c)=>(b->b)->(a->a)->c->c
makeF2 f1 f2 = case cast f1 of
Just g1 -> g1
Nothing -> case cast f2 of
Just g2 -> g2
Nothing -> id
f_int::Int->Int
f_int x = x + 1
f_bool::Bool->Bool
f_bool x = not x
fg_func::(Typeable a)=>a->a
fg_func = makeF2 f_int f_bool
main = print ((show (fg_func (1::Int))) ++ (show (fg_func True)) ++ (show (fg_func 'a')))
makeF2 создает функцию, которая специальным образом работает на типах b и a, но в целом полиморфная (для всех остальных типов она просто возвращает значение).
f_int, f_bool — специализированные функции, на их основе мы создаем fg_func, которая специализирована для типов Bool и Int.
далее мы ее вызываем для 1, True и 'a' — вывод будет 2False'a', т.е. для 1 и True функция отработала особым образом, а для 'a' просто вернула значение.
Re: К вопросу о "static typing" vs "dynamic typing"
SYG>>PROCEDURE DoSmth(VAR x: OBJECT; VAR y: OBJECT{D, E});
SYG>>
SYG>>У процедуры DoSmth первый аргумент x — любой объект; второй аргумент y — любой объект реализующий интерфейсы D и E одновременно.
DG>Как это будет восприниматься другими .Net-языков (например, C#-ом)?
DG>>Имхо, хорошая статическая типизация — это такая типизация, в которой можно по-максимуму задать ограничения на этапе компиляция. DG>>Замечу, что текущие языки не умеют "работать" даже с базовыми вещами. DG>>Пример 1: DG>>Определить функцию, которая принимает объект, который должен поддерживать и интерфейс IA, и интерфейс IB. DG>>Такое ограничение можно записать только с помощью generic-ов: DG>>
DG>>void Method<T>(T value) where T:IA, IB {}
DG>>
Такое ограничение можно записать и проще и лучше:
void func( IA &ia, IB &id );
struct A : IA {};
struct AB : IA, IB {};
extern A a;
extern AB ab;
void test()
{
func(a,a); // error
func(ab,ab); // ok
}
Re[3]: К вопросу о "static typing" vs "dynamic typing"
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Kluev, Вы писали:
K>>А глазами сишного программера у вас написано K>>
K>>мусор f(x: C1); мусор
K>>
SYG>Добрый Вы...
Да ладно, не относитесь серьезно. Это профессиональные заморочки. Наверное Оберон действительно хороший язык раз у него есть такие активные поклонники. А вообще о вкусах не спорят
Re[6]: К вопросу о "static typing" vs "dynamic typing"
Здравствуйте, Schade, Вы писали:
S>Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>>На этот вопрос (про "C1 ИЛИ C2") я дал ответ еще в той ветке форума — это же самая обычная перегрузка. SYG>>
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Если написано OVERLOAD, то сразу видно что это не обероны.
[стеб]
Ну да. А если написано
__attribute__((dllexport))
то, разумеется, это GNU C++, а никак не Microsoft. Как, Вы не знали? Ну о чем говорить-то тогда? Почитайте-ка маны, что ли, для начала, избавьтесь от своей некомпетентности в столь важном вопросе.
[/стеб]
Я не помню, что бы я где-то утверждал, что легко отличаю один виртовский "шедевр" от другого. Но странно как-то в качестве еще одного аргумента в пользу "всемогущести" оберона приводить пример на модуле.
З.Ы. Вообще, серебряной пули нет. Не стоит ставить знак равенства между правильным проектированием и использованием оберона. Убогий и подрезанный со всех сторон язык не спасет от ламеризма. "Ударим по лабухам от программизма — отберем у них пошаговый отладчик". Замечательно, они будут трейсить в лог, ставить вместо брейкпойнтов дополнительные условия проверки — и все будет по-прежнему. И обероноподобный садизм (а как еще это можно назвать?) не поможет.
