Здравствуйте, Воронков Василий, Вы писали:
ВВ>Собственно, сабж. Что это дает-то в принципе? На первый взгляд кажется, что это вообще скорее вредно.
Я так понимаю ты проникся стуктурной типизацией? Ну, дык это не повод не понимать, что кроме структурной есть еще номинативная. Это разные идеологии. Обе пригодны для практического использования. У обоих есть преимущества и недостатки.
В номинативной системе типов наследование реализует полиморфизм нужный для создания АТД и ООП.
Короче фигово троллишь .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Собственно, сабж. Что это дает-то в принципе? На первый взгляд кажется, что это вообще скорее вредно.
VD>Я так понимаю ты проникся стуктурной типизацией?
Вопрос не ко мне, но здесь нет никакой структурной типизации. Класс обладает теми интерфейсами, которые явно указаны. И не может реализовывать интерфейсы, только лишь получив набор методов с нужными сигнатурами.
Здравствуйте, AlexRK, Вы писали:
ARK>В таком случае вашему коду нужен не ICollection, а "ICollection+IEnumerable", раз внутри него вызывается нечто, требующее IEnumerable.
Очень не многие языки умеют оперировать объединениями типов. Это прикольная концепция, но и наследование вполне решат задачи стоящие на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AlexRK, Вы писали:
ARK>Перегрузку по именам надо выкинуть. Она дает некоторое удобство при написании кода, но, ИМХО, никак не при чтении.
Практика показывает, что выкидывают языки без перегрузки. Можно потратить пол жизни на доказательство того, что перегрузка не нужна. Но всем на это будет наплевать.
Кроме того перегрузка она мешает только тем кто не умеет ее готовить (в языках).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не очень хороший пример, вот если потребуется сделать кликабельный Label... начнут городить огород? Лучше давать возможность добавлять обработку сообщений опционально.
Написать то ты можешь. Но толку от этого не будет. Нужна реализация алгоритма. А структуры данных могут быть (и будут на практике) очень сильно разными. Скажем односвязный список и массив.
Такие штуки прокатят только чем-то вроде классов типов, когда можно сделать по перегрузке (отдельной реализации) для каждого поддерживаемого типа.
Вот только к исходному вопросу это уже отношение не имеет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vpchelko, Вы писали:
V>Не очень хороший пример, вот если потребуется сделать кликабельный Label... начнут городить огород? Лучше давать возможность добавлять обработку сообщений опционально.
Безотносительно хороший/плохой пример — кликабельный Label — это собственно говоря и есть Button, с другой формой лица.
F> Безотносительно хороший/плохой пример — кликабельный Label — это собственно говоря и есть Button, с другой формой лица.
Да с какой стороны посмотреть кликаться мы можем, а там mouseover обрабатывать тоже захотим, даже просто по обычному не кликабельному тексту (менять курсор на выделялку текста).
Здравствуйте, AlexRK, Вы писали:
ARK>Вопрос не ко мне, но здесь нет никакой структурной типизации. Класс обладает теми интерфейсами, которые явно указаны. И не может реализовывать интерфейсы, только лишь получив набор методов с нужными сигнатурами.
Если нет, то это банальная логическая ошибка в рассуждениях. Ведь передается не класс, а интерфейс. А при этом информация о реализованных интерфейсах теряется. Приедется делать динамические проверки. А это уже плохо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Написать то ты можешь. Но толку от этого не будет. Нужна реализация алгоритма. А структуры данных могут быть (и будут на практике) очень сильно разными. Скажем односвязный список и массив.
И как ты себе представляешь ленивый массив?
VD>Такие штуки прокатят только чем-то вроде классов типов, когда можно сделать по перегрузке (отдельной реализации) для каждого поддерживаемого типа. VD>Вот только к исходному вопросу это уже отношение не имеет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AlexRK, Вы писали:
ARK>>В таком случае вашему коду нужен не ICollection, а "ICollection+IEnumerable", раз внутри него вызывается нечто, требующее IEnumerable.
VD>Очень не многие языки умеют оперировать объединениями типов. Это прикольная концепция, но и наследование вполне решат задачи стоящие на практике.
Ну мы же сейчас вроде как обсуждаем идеологию и философию программирования, а не реальные языки.
Из реальных мне на ум приходит только Ceylon.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AlexRK, Вы писали:
ARK>>Перегрузку по именам надо выкинуть. Она дает некоторое удобство при написании кода, но, ИМХО, никак не при чтении.
VD>Практика показывает, что выкидывают языки без перегрузки. Можно потратить пол жизни на доказательство того, что перегрузка не нужна. Но всем на это будет наплевать.
Практика показывает, что выживают языки, в которые вкладывается много ресурсов. Остальное по большому счету не имеет значения.
Не думаю, что языковые возможности выживших являются безусловным образцом для подражания.
VD>Кроме того перегрузка она мешает только тем кто не умеет ее готовить (в языках).
Ну фиг знает. По моему мнению перегрузка облегчает запись, но не чтение.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AlexRK, Вы писали:
ARK>>Вопрос не ко мне, но здесь нет никакой структурной типизации. Класс обладает теми интерфейсами, которые явно указаны. И не может реализовывать интерфейсы, только лишь получив набор методов с нужными сигнатурами.
VD>Если нет, то это банальная логическая ошибка в рассуждениях. Ведь передается не класс, а интерфейс. А при этом информация о реализованных интерфейсах теряется. Приедется делать динамические проверки. А это уже плохо.
Да нет, передается именно класс, который реализует некоторый набор интерфейсов. В общем, как генерик-методы в C#.
В принципе, тут можно усмотреть некий намек на структурную типизацию, хотя не в привычном смысле. Единицей "структуры" будет один интерфейс, а главной сущностью — "набор интерфейсов". А при использовании наследования этот самый "набор интерфейсов" жестко зашит в одну сущность.
Здравствуйте, vpchelko, Вы писали:
V>Да с какой стороны посмотреть кликаться мы можем, а там mouseover обрабатывать тоже захотим, даже просто по обычному не кликабельному тексту (менять курсор на выделялку текста).
Дык всё это можно и с Button. Всё в итоге упирается в конкретный UI фреймворк, и есть ли там невменяемые ограничения.
F> Дык всё это можно и с Button.
Вот опять, нафиг мне все кнопочное (из соображений — грузить в память только необходимое), если мне нужно нарисовать текст и менять курсор / подсветить текст под курсором.
Здравствуйте, vpchelko, Вы писали:
F>> Дык всё это можно и с Button. V>Вот опять, нафиг мне все кнопочное (из соображений — грузить в память только необходимое), если мне нужно нарисовать текст и менять курсор / подсветить текст под курсором.
А что кнопочного то? Кнопка так и делает. Рисует текст и реагирует на несколько событий.
А с поведенческой точки зрения то кликабельный лэйбл — это как раз самая кнопка.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AlexRK, Вы писали:
ВВ>Ты когда пишешь
ВВ>
ВВ>2 + 2
ВВ>12.2 + 12.2
ВВ>
ВВ>то это ведь тоже перегрузка.
Согласен. Хотя вроде бы в окамле операторы разные.
Вообще тут вопрос неоднозначный. Во-первых, в идеальном сферическом языке в вакууме даже оператор сложения не будет перегружен — будет единый тип "число". Во-вторых, если ближе к реальности, то с такой перегрузкой я согласен — она в одном месте и выглядит естественно, т.к. пришла из математики. Даже специальный синтаксис используется, а не обычный вызов метода. А вот другие типы перегрузки как-то не внушают доверия. Кстати, я тут подумал — не припомню в своих проектах интенсивного использования перегрузки (хотя у других людей опыт другой, конечно).
.
кликаться мы можем, а там mouseover обрабатывать тоже захотим, даже просто по обычному не кликабельному тексту (менять курсор на выделялку текста).
