[00:12:04] <vlad2> Kemet: поэтому я запретил в oberonjs переопределять базовые поля :)
[00:27:00] <_valexey__> а что на эту тему репорт говорит?
[00:28:09] <_valexey__> что-то походу оборонкор лежит
[01:05:22] <vlad2> Дык, чего он может сказать на 16 страницах? :-]
[01:14:00] <_valexey__> На семнадцати же!
[01:39:30] <vlad2> Когда оно дорастет до 50 можно уже надеятся на описание таких "мелочей".
[02:52:52] <_valexey_> Никогда!
[10:10:29] <geniepro> _valexey_> Внутренняя структура это детали реализвции
_valexey_> Это не должно заботить никого кроме того кто этот конкретный класс реализует.
Kemet> у объекта должны быть инварианты - непротиворечивые состояния, а как это реализуется совсем не важно, поля это частный случай, но достаточно простой и понятный

не вполне понятно, как в таких условиях может работать иерархия классов, расширение типов. ведь субкласс не получит доступа к внутренностям своего суперкласса, по крайней мере большего доступа чем другие классы
отсюда вопрос -- а зачем тогда наследование?
[11:06:58] <NEW> абстрактные методы - вот зачем наследование. Методы используются в базовом классе, а реализуются в подклассе.
[11:10:58] <geniepro> так это интерфейсы, они и в хаскелле есть, хоть там и нет иерархий типов как в ООП
[11:13:06] <NEW> интерфейсы - это не то. В интерфейс могут входить как абстрактные методы, так и реализованные.
[11:59:28] <geniepro> ну, в классы типов хаскеля тоже могут входить как абстрактные методы, которые нужно определять пользователю, так и предопределённые, которые можно переопределить, если нужно
[12:54:57] <TRUE> тогда, значит, в хаскеле есть  иерархия
[13:06:52] <geniepro> в хаскелле нет иерархий, но есть зависимости -- это немного другое
[13:07:44] <geniepro> в классе типов можно указать, что он зависит от других классов типов, это требует при его использовании использовать и те,Ю от которых он зависит
но в иерархию они не выстраиваются
[14:20:55] <Kemet> geniepro: > не вполне понятно, как в таких условиях может работать иерархия классов, расширение типов. ведь субкласс не получит доступа к внутренностям своего суперкласса, по крайней мере большего доступа чем другие классы
отсюда вопрос -- а зачем тогда наследование?
хз, это просто сфероконь в вакууме, теоретики, мать их, реальный мир яп дает нам простые и понятные реализации
[14:44:32] <_valexey__> geniepro: класс типов это ж не ООП ни разу. без левых расширений языка в хаскеле нет ничего похожего на ООП
[14:44:46] <_valexey__> Если я правильно помню, расширение называется - существовательные типы :-)
[14:50:41] <_valexey__> а чистых хаскель ваще ничего не может!
[14:52:48] <_valexey__> чистый
[14:52:53] <_valexey__> камло круче!
[14:53:07] <_valexey__> верблюд грязен, но эффективен!
[15:02:19] <geniepro> _valexey__> geniepro: класс типов это ж не ООП ни разу. без левых расширений языка в хаскеле нет ничего похожего на ООП
ну да, это пример интерфейсов без ООП, NEW утверждал, что ООП нужен для интерфейсов, раз уж иерархии классов в нём не нужны
[15:03:15] <geniepro> _valexey__> Если я правильно помню, расширение называется - существовательные типы :-)
это не ООП-расширение, а попытка чесать левое ухо правой пяткой -- если пытаться обосновать эти экзистенциалы ООП-ом
[15:04:26] <geniepro> есть ООП-вариант хаскела -- о'хаскелл называется, но заброшен и сдох
[15:04:38] <geniepro> хаскеллерам ООП нинужен
[15:17:40] <TRUE> я объяснял смысл существования наследования.
[15:20:05] <geniepro> так в чём смысл существования наследования, если нтерфейсы можно делать без наследования, а при инкапсуляции по типу валексея внутренности суперклассов субклассам недоступны?
[15:46:37] <TRUE> на не нужен доступ к суперклассам
[15:46:47] <TRUE> это суперклассам нужен доступ к наследникам
[15:48:00] <geniepro> о_О они же ничего не знают о том, кто их там унаследует
[16:04:28] <TRUE> они экспортируют абстрактные методы. И сами же эти абстрактные методы используют. В наследниках абстрактные методы реализуются, и методы из базового класса начинают работать.
[16:12:01] <TRUE> abstract class Logger {
 private String ERR = "ERROR";
 private String INFO = "INFO";

 public abstract void writeLine(String lvl, String msg);

 public void err(String msg) {
   writeLine(ERR, msg);
 }
 public void info(String msg) {
   writeLine(INFO, msg);
 }
}

class ConsoleLogger {
 public void writeLine(String lvl, String msg) {
   String data = new Date() + " | " + lvl + " | " + msg;
   System.out.println(data);
 }
}

class FileLogger {
 public void writeLine(String lvl, String msg) {
   ...
 }
}

[17:27:35] <Kemet> TRUE: но это доступ не к наследникам, а просто к виртуальному методу
[17:28:00] <TRUE> ну, в общем, да
[17:28:41] <Kemet> наверное не во всех яп можно обращаться к абстактным методам
[17:28:45] <TRUE> просто, к виртуальным методам может обращаться третья сторона, а может предок.
[20:35:37] <valexey> TRUE пахнет жабой...
[20:35:51] <valexey> А вот жаба ООП не пахнет :-)
[21:01:27] <TRUE> а в плюсах не также?
[21:07:29] <TRUE> но если подумать, то и в моём примере можно обойтись без наследования. Достаточно лишь вынести все абстрактные методы из класса в интерфейс, а в самом классе использовать сам интерфейс, который кем-то в другом месте реализован.
[21:10:57] <TRUE> Правда, в исходный класс потребуется добавить метод, который получает сущность, реализующую нужный интерфейс. И этим методом можно забыть воспользоваться, что впоследствии приведёт к неправильной работе приложения. В частном случае, объект с этим интерфейсом передаётся в конструктор, и тогда такой проблемы не будет.
[21:11:17] <TRUE> Но в итоге оказывается, что да - наследование не нужно.
[21:20:24] <valexey> блин, надо будет таки найти время и смалтолком обкуриться
[21:25:56] <valexey> "Cи заставляет упираться в совершенно нетривиальные и почти бесполезные в остальных языках указатели. Это основная проблема."
[21:26:03] <valexey> В золотой цитатник!
[21:26:05] <valexey> :-)
[21:45:24] <vlad2> "Это с обреронкоре?
[21:46:36] <valexey> не
[21:46:38] <valexey> LOR
[22:42:46] <valexey> Вот этот эпичный тредик: www.linux.org.ru/forum/development/12942669