Хочу странного!
Мне кажется, это можно реализовать через mixins
Только я не совсем понимаю, зачем это может быть нужно, если можно сделать обычную композицию
Только я не совсем понимаю, зачем это может быть нужно, если можно сделать обычную композицию
может быть, я не понял вопрос, но есть такая фишка, как классы типов в хаскеле
первая ссылка из гугла: http://www.haskell.org/tutorial/classes.html
первая ссылка из гугла: http://www.haskell.org/tutorial/classes.html
Через mixins - как раз фигу.
Это моё странное возникло от наблюдения за скаловской системой акторов. Функция для посылки сообщения принимает сообщения типа Any и не может быть ограничена по типу. Возникает это по следующей причине. Пусть у нас есть специальный тип для сообщений. В скале он называется для простоты алгебраическим, но таковым не является. По факт просто объявляется один старший тип и несколько наследников-конструкторов. То, что в хаскеле делается через data type, здесь делается просто через наследование. Но допустим, мы хотим скомбайнить обработку сообщений, например, через orElse, с обработкой сообщений другого типа. Тут возникает необходимость объявить анонимный супертип для двух типов, ну или на худой конец не анонимный, но такой, который не потребует переписывать объявления исходных типов. Такой функциональности в скале нет. Там можно сделать вручную делегата и зароутить методы класса, можно даже сделать это невручную, через кодогенерацию в плагинах компилятора. Но при этом возможность статической проверки типов пропадает всё равно. И поэтому все акторы, независимо от своего назначения, принимают сообщения типа Any, и отказываются от статической типизации.
Возможно есть и другие use case, где было бы очень удобно наращивать корни у дерева классов.
Это моё странное возникло от наблюдения за скаловской системой акторов. Функция для посылки сообщения принимает сообщения типа Any и не может быть ограничена по типу. Возникает это по следующей причине. Пусть у нас есть специальный тип для сообщений. В скале он называется для простоты алгебраическим, но таковым не является. По факт просто объявляется один старший тип и несколько наследников-конструкторов. То, что в хаскеле делается через data type, здесь делается просто через наследование. Но допустим, мы хотим скомбайнить обработку сообщений, например, через orElse, с обработкой сообщений другого типа. Тут возникает необходимость объявить анонимный супертип для двух типов, ну или на худой конец не анонимный, но такой, который не потребует переписывать объявления исходных типов. Такой функциональности в скале нет. Там можно сделать вручную делегата и зароутить методы класса, можно даже сделать это невручную, через кодогенерацию в плагинах компилятора. Но при этом возможность статической проверки типов пропадает всё равно. И поэтому все акторы, независимо от своего назначения, принимают сообщения типа Any, и отказываются от статической типизации.
Возможно есть и другие use case, где было бы очень удобно наращивать корни у дерева классов.
классы типовв любом случае, все супертипы (и прочие зависимости) у класса прописаны в объявлении класса. И не могут потом наращиваться
все супертипы (и прочие зависимости) у класса прописаны в объявлении классада вроде там чуток по-другому =\ ведь можно нацепить интерфейс на тип гораздо позже объявления типа
а мочкану-ка я еще ссылочкой: http://stackoverflow.com/questions/3124511/newbie-question-h...
интерфейс на типно ты не можешь нацепить интерфейс на интерфейс. В смысле наследования - можешь. А вот в смысле объявления суперкласса - нет
но ты не можешь нацепить интерфейс на интерфейс. В смысле наследования - можешь. А вот в смысле объявления суперкласса - нетя наверное не понял о чем речь, но вот в TypeScript-е интерфейс можно определять позже класса, и класс об интерфейсе ничего не знает:
class Foo {
m1: string {
return "";
}
}
interface IFoo {
m1: => string;
}
window.onload = => {
var foo: IFoo = new Foo;
};
это что, duck typing? Он же не позволяет производить статических проверок.
это что, duck typing?не совсем
Он же не позволяет производить статических проверок.
Каких проверок? Если у класса не будет метода интерфейса, то компилятор выдаст ошибку.
пример. У всех интов есть метод сложения. Да ещё много у каких типов. Статическая проверка позволяет избежать сложения разных типов.
duck typing никогда не заменит иерархии типов. Если считаешь иначе - заведу отдельную ветку для разъяснения различий нормальной иерархии типов и утиной
duck typing никогда не заменит иерархии типов. Если считаешь иначе - заведу отдельную ветку для разъяснения различий нормальной иерархии типов и утиной
пока я не уверен, что то что я показал это Duck typing
В TypeScript наличие метода проверяется в компайл тайме.
In "duck typing",[13] a statement calling a method m on an object does not rely on the declared type of the object; only that the object, of whatever type, must supply an implementation of the method called, when called, at run-time.
http://en.wikipedia.org/wiki/Type_system#Duck_typing
В TypeScript наличие метода проверяется в компайл тайме.
a statement calling a method m on an object does not rely on the declared type of the objectв TS релаются не на декларацию типа, а на шаг позже на декларацию переменной (или параметра метода).
В TypeScript наличие метода проверяется в компайл тайме.в скале тоже есть статический duck typing, но он всё равно не позволяет строить таксономию типов для выполнения дополнительных проверок. И duck typing теряется на pattern matching и полиморфизме. И в том примере, что я показал, тоже теряется.
для выполнения дополнительных проверокможешь в коде показать каких проверок не хватает? Просьба, в примере по минимуму использовать навороты скалы, я скалу не знаю.
Не видел ли кто возможно эзотерического языка, где иерархию типов можно растить не только вниз, объявляя новый сабкласс от классов, но и вверх, объявляя новый суперкласс для существующих классов? Таковой суперкласс по идее является неким union type, где методы автоматически или вручную делегируются нужному типу.Категории в Objective-C?
Оставить комментарий
yroslavasako
Не видел ли кто возможно эзотерического языка, где иерархию типов можно растить не только вниз, объявляя новый сабкласс от классов, но и вверх, объявляя новый суперкласс для существующих классов? Таковой суперкласс по идее является неким union type, где методы автоматически или вручную делегируются нужному типу. Фишка в том, чтобы это делалось не вручную, а встраивалось в концепцию классов, насследования, ко/контр-вариации и позволяла бы статически проверять контракты типов. Если вместо инкапсуляции в классы будут generic methods в стиле CLOS, то это только приветствуется.