[ООП] ООП и модульность [re: Почему ООП - это плохо?]
> ООП включает абстракцию данных, что мешает абстрагировать иными способами.
Кто мешает? Не абстрагируй данные, если у тебя на них зуб. А что за "иные" способы?
> Получается, что ООП подразумевают одну область видимости
"Я бы за такое сразу банил."
> ООП --- отстой.
> Потому что не только ничерта не учитывает достижений
> модульного программирования, но и является шагом назад,
> отбрасывая все эти достижения и ничего не давая взамен.
Поздравляю! Родился ещё один лозунг а-ля-КОНТРА, такой же тупой и бездоказательный, как и остальные.
Кто мешает? Не абстрагируй данные, если у тебя на них зуб. А что за "иные" способы?
> Получается, что ООП подразумевают одну область видимости
"Я бы за такое сразу банил."
> ООП --- отстой.
> Потому что не только ничерта не учитывает достижений
> модульного программирования, но и является шагом назад,
> отбрасывая все эти достижения и ничего не давая взамен.
Поздравляю! Родился ещё один лозунг а-ля-КОНТРА, такой же тупой и бездоказательный, как и остальные.
Доказывай.
Отрицательные утверждения в доказательстве не нуждаются,
доказывать нужно положительные.
Ты утверждаешь, что модульность существует? Приводи пример!
Жду пример средств, сравнимых по мощности со средствами Ады.
---
...Я работаю антинаучным аферистом...
Отрицательные утверждения в доказательстве не нуждаются,
доказывать нужно положительные.
Ты утверждаешь, что модульность существует? Приводи пример!
Жду пример средств, сравнимых по мощности со средствами Ады.
---
...Я работаю антинаучным аферистом...
Последняя строка не коректна. )
> Ты утверждаешь, что модульность существует? Приводи пример!
Я утверждаю? У тебя там... э-э... всё в порядке?
Я вообще-то спрашиваю, что это и почему в ООП (в ООП-языках C++/C#/Java) это отсутствует (если, конечно, отсутствует)?
Я утверждаю? У тебя там... э-э... всё в порядке?
Я вообще-то спрашиваю, что это и почему в ООП (в ООП-языках C++/C#/Java) это отсутствует (если, конечно, отсутствует)?
Потому что, как только что выяснили, в Яве модульность
есть только на уровне операционной системы,
а это точно такая же модульность, как и в машинном коде.
То же самое в сях.
Это --- не модульность.
---
"Я знаю правду! Все прежние правды --- прочь!"
есть только на уровне операционной системы,
а это точно такая же модульность, как и в машинном коде.
То же самое в сях.
Это --- не модульность.
---
"Я знаю правду! Все прежние правды --- прочь!"
Ты утверждаешь, что модульность существует? Приводи пример!хз. В шарпе есть ассембли и модификатор интернал/протектед интернал. Что ещё нужно для щастья?
Жду пример средств, сравнимых по мощности со средствами Ады.
Можешь внятно сказать, что такое модульность в твоём понимании и привести пример, для которого нет эквивалентного представления (с теми же областями видимости) на C++? Только не на PROLOG/CLIPS/Brainfuck, пожалуйста.
А зачем, собственно, эквивалентные представления нужны?
См. Аду.
Вот это --- Модульность.
---
"...А в нашей буче, боевой, кипучей, ---
и того лучше."
Вот это --- Модульность.
---
"...А в нашей буче, боевой, кипучей, ---
и того лучше."
Потому что есть сильное подозрение, что эта "модульность" - что бы она там не означала по разумению КОНТРЫ - есть и в C++/C#/Java.
Модульность --- это когда можно определять модули
без глупых ограничений, вроде "один на файл,"
и когда можно работать с модулями без столь же глупых
ограничений, вроде неперекрываемости имён в модулях,
или явной квалификации.
---
"...А в нашей буче, боевой, кипучей, ---
и того лучше."
без глупых ограничений, вроде "один на файл,"
и когда можно работать с модулями без столь же глупых
ограничений, вроде неперекрываемости имён в модулях,
или явной квалификации.
---
"...А в нашей буче, боевой, кипучей, ---
и того лучше."
Объяви на Яве два модуля в одном файле.
Тогда будем считать, что ты прав.
Хотя бы в части Явы.
---
"Истина грядёт --- её ничто не остановит!"
Тогда будем считать, что ты прав.
Хотя бы в части Явы.
---
"Истина грядёт --- её ничто не остановит!"
Почему явная квалификация есть глупое ограничение?
Как раз защита от дураков.
Как раз защита от дураков.
> Модульность --- это когда можно определять модули без глупых ограничений, вроде "один на файл,"
Не аргумент. В C# (тем более в C++) этого ограничения нет.
> и когда можно работать с модулями без столь же глупых ограничений, вроде неперекрываемости имён в модулях, или явной квалификации.
Если прям так надо кого-то с кем-то перекрыть, в C++ есть слово friendly.
Пример будет?
Не аргумент. В C# (тем более в C++) этого ограничения нет.
> и когда можно работать с модулями без столь же глупых ограничений, вроде неперекрываемости имён в модулях, или явной квалификации.
Если прям так надо кого-то с кем-то перекрыть, в C++ есть слово friendly.
Пример будет?
Потому что нафиг не надо писать сотню раз,
из которого модуля берётся объект, если он один с таким именем
или, как, например, для процедур или функций, это однозначно видно
по его типу.
---
...Я работаю антинаучным аферистом...
из которого модуля берётся объект, если он один с таким именем
или, как, например, для процедур или функций, это однозначно видно
по его типу.
---
...Я работаю антинаучным аферистом...
Что там насчёт вложенных?
Что насчёт "use"?
---
...Я работаю антинаучным аферистом...
Что насчёт "use"?
---
...Я работаю антинаучным аферистом...
С добрым утром! В Java есть import, в C# - using, в С++ - using namespace.
> Что там насчёт вложенных?
Вложенных чего? Это вообще к чему?
Вложенных чего? Это вообще к чему?
Добрый вечер!
Мы уже увидели, что в Яве нет модулей, а "using" в "C#" бесполезен,
поскольку не решает поставленную задачу.
---
...Я работаю антинаучным аферистом...
Мы уже увидели, что в Яве нет модулей, а "using" в "C#" бесполезен,
поскольку не решает поставленную задачу.
---
...Я работаю антинаучным аферистом...
Каких модулей? Какую задачу? Ты пример будешь приводить, или обоснование утверждений - не твой стиль?
Доказываются утверждения о существовании.
Это понятно или нет?
Как можно доказывать утверждение о несуществовании,
если это и так очевидно, что не существует?
Определи на Яве два модуля в одном файле.
Покажи, как на сях можно обойтись без явного указания модуля
в случае разных сигнатур функций.
---
...Я работаю антинаучным аферистом...
Это понятно или нет?
Как можно доказывать утверждение о несуществовании,
если это и так очевидно, что не существует?
Определи на Яве два модуля в одном файле.
Покажи, как на сях можно обойтись без явного указания модуля
в случае разных сигнатур функций.
---
...Я работаю антинаучным аферистом...
Так ведь я не знаю, что ты понимаешь под своими модулями. Что бы я не привёл в качестве примера, всегда можно сказать: "это не модуль". Так что давай сначала пример на своём мегарульном языке с указанием, где там модули, которые нельзя представить на C++/C#/Java (т. е. в рамках ООП-подхода на современных языках).
Под модулями я понимаю модули, которые не только
единицы компиляции, но связаны логически, в том числе
определяют область видимости имён.
---
...Я работаю антинаучным аферистом...
единицы компиляции, но связаны логически, в том числе
определяют область видимости имён.
---
...Я работаю антинаучным аферистом...
От тебя требуется сделать следующее на твоих трёх языках:
---
...Я работаю антинаучным аферистом...
И всё в одном файле.
package P1 is
with P2, P3; use P2;
package P11 is ... end;
...
end;
package P2 is ... end;
package P3 is ... end;
package P4 is
with P1, P1.P11; use P1, P1.P11;
...
end;
---
...Я работаю антинаучным аферистом...
Не прошло и полгода - и вот пример! Ура!
А как твой мегаязык называется, чтобы я мог посмотреть, что всё это значит?
А как твой мегаязык называется, чтобы я мог посмотреть, что всё это значит?
Это страшный язык Ада.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
С каких пор в Аду включили модули? 1995?
Думаю, ещё до 1980-го.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
1. Ты уверен, всё это на Аде должно находиться в одном файле, и это разумно?
2. То, что в Java в каждом файле кода может быть только один public class, нисколько не умаляет достоинтв ООП-подхода. Если у тебя есть нормальный IDE, который организует файлы, то неудобств вообще нет. Если ты пишешь на emacs, это твои проблемы. Повторяю, это НЕ аргумент.
2. То, что в Java в каждом файле кода может быть только один public class, нисколько не умаляет достоинтв ООП-подхода. Если у тебя есть нормальный IDE, который организует файлы, то неудобств вообще нет. Если ты пишешь на emacs, это твои проблемы. Повторяю, это НЕ аргумент.
Блин, о чем спор. Одни спорят, что лучше, ООП или ФП. А разве тогда не лучше ООП+ФП. Я конечно не спец по всяким экстремальным языкам, но вроде по поддержке ООП такой ФЯ как ML даст фору C++ и Java вместе взятыми.
Потом, просто не представляю, как писать хоть что-нибудь маломальски приличное без полиморфизма. И не надо говорить, что я им не пользуюсь, просто сам не замечаешь. Лучше, чтобы язык помогал в юзании полиморфизма. Кому мешает инкапсуляция. Она полезна хотя бы из таких соображений. Вот если посмотреть на ЯП-старичков, то можно заметить следующее. Несмотря на всю их там поддержку модульности, большинство грешат тем, что сваливают все идентификаторы в кучу. В современных языках (С++, Java, C#, есть еще наверно) эту проблему как-то решают, жизнь заставляет
. Кто-то лучше, кто-то хуже. И конечно инкапсуляция в этом тоже очень сильно помогает. Ну а наследование никому не мешает. Просто для полиморфизма нужно вводить что-то типа отношения тип-подтип (когда объекты одного можно использовать вместо объектов другого в принципе это можно делать и на уровне функций. Штука в том, что полиморфизм легко увязать с наследованием и со статической типизацией, а главное с эффективной реализации.
Еще ООП позволяет навоять библиотеку так, чтобы с одной стороны ее пользоваться было удобно VB програмеру, с другой стороны позволяла серьезному прогеру гибко настраивать функциональность библиотеки, даже лучше сказать "вгрызвться" в нее.
Потом, просто не представляю, как писать хоть что-нибудь маломальски приличное без полиморфизма. И не надо говорить, что я им не пользуюсь, просто сам не замечаешь. Лучше, чтобы язык помогал в юзании полиморфизма. Кому мешает инкапсуляция. Она полезна хотя бы из таких соображений. Вот если посмотреть на ЯП-старичков, то можно заметить следующее. Несмотря на всю их там поддержку модульности, большинство грешат тем, что сваливают все идентификаторы в кучу. В современных языках (С++, Java, C#, есть еще наверно) эту проблему как-то решают, жизнь заставляет
. Кто-то лучше, кто-то хуже. И конечно инкапсуляция в этом тоже очень сильно помогает. Ну а наследование никому не мешает. Просто для полиморфизма нужно вводить что-то типа отношения тип-подтип (когда объекты одного можно использовать вместо объектов другого в принципе это можно делать и на уровне функций. Штука в том, что полиморфизм легко увязать с наследованием и со статической типизацией, а главное с эффективной реализации.Еще ООП позволяет навоять библиотеку так, чтобы с одной стороны ее пользоваться было удобно VB програмеру, с другой стороны позволяла серьезному прогеру гибко настраивать функциональность библиотеки, даже лучше сказать "вгрызвться" в нее.
Код на C#.
namespaсe P1 {
using P2, P3;
namespace P11 {
...
}
}
и т. д. И всё в одном файле, специально для тех, для кого это проблема.Всё, свободен.Да, хотя бы по этому большинство языков, что может предложить КОНТРА, говно на практике.
Это _может_ находиться в одном файле.
И это куда более разумно, нежели распихивать
все функции в файлы по одной, потому что иначе никак нельзя
Если в твоей среде нет приличного редактора,
способного скрыть ненужные участки кода,
то это трудности твоей среды. Но не Емакса.
Перечитай ещё раз: твоё хвалёное ООП (в лице Явы) неспособно справиться
с простейшей задачей логического структурирования исходных текстов.
Со всеми вытекающими последствиями при росте.
Таким образом ООП делает шаг назад, отбрасывая достижения
модульного программирования и не давая ничего взамен.
Про действия над двумя объектами я пока молчу.
---
"Истина грядёт --- её ничто не остановит!"
И это куда более разумно, нежели распихивать
все функции в файлы по одной, потому что иначе никак нельзя
Если в твоей среде нет приличного редактора,
способного скрыть ненужные участки кода,
то это трудности твоей среды. Но не Емакса.
Перечитай ещё раз: твоё хвалёное ООП (в лице Явы) неспособно справиться
с простейшей задачей логического структурирования исходных текстов.
Со всеми вытекающими последствиями при росте.
Таким образом ООП делает шаг назад, отбрасывая достижения
модульного программирования и не давая ничего взамен.
Про действия над двумя объектами я пока молчу.
---
"Истина грядёт --- её ничто не остановит!"
Ну как это связано с ООП? Если в Java сделал немного криво, это ж не значит, что нельзя сделать нормально (см. C#).
Там, где стоит многоточие, я смогу использовать функцию f из P2,
вызывая её как "f", а не "P2.f"?
Если нет --- свободен.
Решается ли вопрос о функции f, описанной в P2 и P3 одновременно?
Которая будет вызываться при написании "f" без указания имени модуля?
---
...Я работаю антинаучным аферистом...
вызывая её как "f", а не "P2.f"?
Если нет --- свободен.
Решается ли вопрос о функции f, описанной в P2 и P3 одновременно?
Которая будет вызываться при написании "f" без указания имени модуля?
---
...Я работаю антинаучным аферистом...
Тем более, что (в Java) на это есть причины. С нормальным IDE это вообще не проблема.
Более того, программистам на C# советуют писать точно так же (Thinking in C#).
Более того, программистам на C# советуют писать точно так же (Thinking in C#).
Да, твою ..., да! Загляни, наконец, в описание C# и открой для себя XXI век. Я же пошарил насчёт Ады.
Это _может_ находиться в одном файле.У меня небольшой проект есть. 10 мегабайт весом. Всё это в один файл запихнуть можно, но, я полагаю, не стоит. Даже с возможностью упрятывания неактуальных кусков кода в VS.NET, удаление/добавление классов вручную станет просто адской мукой. Для нормальных людей, конечно.
И это куда более разумно, нежели распихивать
все функции в файлы по одной, потому что иначе никак нельзя
Хорошо, Яву вычёркиваем.
Раз уж её за отстой признали сами ОО-шники.
Переходим к жонглированию двумя объектами.
Каким образом это укладывается на ОО-модель?
---
...Я работаю антинаучным аферистом...
Раз уж её за отстой признали сами ОО-шники.
Переходим к жонглированию двумя объектами.
Каким образом это укладывается на ОО-модель?
---
...Я работаю антинаучным аферистом...
Ну, задачу решил. Молодец.
Теперь объясни, как это укладывается на ОО-модель.
Можно ли обращаться с областями видимости, как с объектами?
---
...Я работаю антинаучным аферистом...
Теперь объясни, как это укладывается на ОО-модель.
Можно ли обращаться с областями видимости, как с объектами?
---
...Я работаю антинаучным аферистом...
Я же сказал, свободен.
Я не собираюсь что-то делать с твоим невежеством, да ещё за свой собственный счёт.
Я не собираюсь что-то делать с твоим невежеством, да ещё за свой собственный счёт.
То есть, никак не ложится.
Засчитано.
---
...Я работаю антинаучным аферистом...
Засчитано.
---
...Я работаю антинаучным аферистом...
Тем более, что (в Java) на это есть причины. С нормальным IDE это вообще не проблема.Да нет там особых причин, почему совместили физическое структурирование и логическое. Хотя так возможно проще с точки зрения реализации VM (у Sun это отмазка всегда срабатывает
портировать легко 
). Просто так сделали, сильно в то время не задумывались.Я тут букварь читаю по Ada. Интересные вещи пишут. Например:
Although most Ada compilers permit multiple compilation units in a single file, it's usually better to put separate compilation units in separate files. One Ada compiler (GNAT) requires different compilation units to be in different files.Правильно ли я понимаю. что сами Ada guys учат новичков не делать того, что так не хватает тебе в Java? "Возможность засунуть несколько модулей в один файл."
> Просто так сделали, сильно в то время не задумывались.
Сантехники не задумывались.
Похоже на правду.
---
...Я работаю антинаучным аферистом...
Сантехники не задумывались.
Похоже на правду.
---
...Я работаю антинаучным аферистом...
Там, где стоит многоточие, я смогу использовать функцию f из P2,Все там ок, поверь. В случае
вызывая её как "f", а не "P2.f"?
Если нет --- свободен.
Решается ли вопрос о функции f, описанной в P2 и P3 одновременно?
Которая будет вызываться при написании "f" без указания имени модуля?
Которая будет вызываться при написании "f" без указания имени модуля?Неоднозначность. Ошибку выдают. Так тоже правильно, поверь.
Думаешь Хельжберг твою Аду не знает.
Во! И я про это. Я тоже прочитал про package, но решил, что может manual старый и спросил у КОНТРЫ. Оказывается и в мире Ады это не котируется, кроме как в голове у КОНТРЫ.
"It's usually better" не подразумевает необходимости.
Программисту лучше видно, что именно "better."
Кроме того, это относится к "compilation units,"
которые могут как совпадать с логическим делением программы,
так и не совпадать.
Там есть ещё замечательное слово "separate."
---
...Я работаю антинаучным аферистом...
Программисту лучше видно, что именно "better."
Кроме того, это относится к "compilation units,"
которые могут как совпадать с логическим делением программы,
так и не совпадать.
Там есть ещё замечательное слово "separate."
---
...Я работаю антинаучным аферистом...
А если сигнатуры разные?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Есть разница между пропагандой, наподобие "GOTO considered harmful,"
и разумным решением, что именно "considered harmful."
---
...Я работаю антинаучным аферистом...
и разумным решением, что именно "considered harmful."
---
...Я работаю антинаучным аферистом...
ОК. Ладно. Я с самого начала понимал, что аргумент слабоват.
Тогда не знаю, если честно. Впрочем я бы не возражал если бы компилятор выдавал ошибку. ТАК ведь можно случайно перепутать. Потом C# вроде функции вне классов не висят
> ТАК ведь можно случайно перепутать.
Там даже строчные и прописные различаются!
КАК можно так случайно перепутать?
> Потом C# вроде функции вне классов не висят
Что там насчёт жонглирования двумя объектами?
---
...Я работаю антинаучным аферистом...
Там даже строчные и прописные различаются!
КАК можно так случайно перепутать?
> Потом C# вроде функции вне классов не висят
Что там насчёт жонглирования двумя объектами?
---
...Я работаю антинаучным аферистом...
Это как раз по поводу вопроса о потакании компилятором (и языком) плохому стилю прогера. Современная точка зрения, что язык и компилятор должны препятствовать потенциальному совершению ошибок, даже ценой потери в "удобности".
Кстати, может тебе туда резюме заслать.
I have an opening for senior Program Manager on my team. I am looking for someone with deep industry experience that is equally capable and comfortable on a broad range of areas:Смотришь наведешь порядок в MS
Working with Closures and lamda function and virtual dispatch
Motivating and enabling a large team to focus on the right results
Writing code in VB, F#, C# and Python, and Lua
Giving compelling presentations to management at Microsoft, .NET User’s Groups\large conferences and professors at top tier universities
Knows the differences between:
FCalls and ECalls,
MethodDescs and MethodTables
CLI, CLR, CLS, and SSCLI
Buy-in, consensus and dictating
Does the right features at the right times for the right customers.
Want to be a part of what you see my team already doing today
See the full job description then let me know if you are interested.
Brad Abrams
Published: Brad Abrams [MSFT] Thursday, 10 March 2005 11:34:00
Почему бы тогда перегрузку вовсе не отменить?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> Почему бы тогда перегрузку вовсе не отменить?
потому что
> Потом C# вроде функции вне классов не висят
Поэтому когда речь идёт о содержимом одного класса, аффтары языка считают тебя способным называть методы так, что твои методы с одинаковым названием но разными сигнатурами делают одно и то же на самом деле. Когда идёт речь о более общих вещах, аффтары совершенно справедливо полагают тебя неспособным держать в голове всю структуру твоих классов и классов используемых тобой библиотек одновременно.
Если у тебя Formatter из неймспейса DiskTools случайно пересечётся с Formatter из неймспейса Text (названия вымышленные и умный компилятор начнёт угадывать, что ты на самом деле имел в виду, результаты могут получиться смешные.
Есть такое моё мнение, что некоторые вещи - библиотечные функции, апи, компиляторы - не должны обладать никакими признаками интеллекта. Потому что признаки интеллекта с неизбежностью приводят к существованию фантома "собственного мнения". А мне не нужно собственное мнение у таких утилит - у меня самого оно уже есть.
Хочется интеллектуальности - делаешь обёртку/свитч, который говорит - "а вот теперь если файл не найден там, где сказал программист, пытаемся поискать его рядом". Например. Но такое поведение по дефолту - безусловное зло.
Термин unforgiving по отношению к языку программирования/компилятору как раз означает что компилятор не пытается искать объявление переменной вообще везде, если не нашёл её там где она должна быть. ИМХО.
>Что там насчёт жонглирования двумя объектами?
Это ты о чём?
>Таким образом ООП делает шаг назад, отбрасывая достижения
>модульного программирования и не давая ничего взамен.
ООП ортогонально модульности. В случае жавы к модульности подошли таким образом, каким подошли. В случае шарпа рестрикшены немного снизили, и это удобно.
потому что
> Потом C# вроде функции вне классов не висят
Поэтому когда речь идёт о содержимом одного класса, аффтары языка считают тебя способным называть методы так, что твои методы с одинаковым названием но разными сигнатурами делают одно и то же на самом деле. Когда идёт речь о более общих вещах, аффтары совершенно справедливо полагают тебя неспособным держать в голове всю структуру твоих классов и классов используемых тобой библиотек одновременно.
Если у тебя Formatter из неймспейса DiskTools случайно пересечётся с Formatter из неймспейса Text (названия вымышленные и умный компилятор начнёт угадывать, что ты на самом деле имел в виду, результаты могут получиться смешные.
Есть такое моё мнение, что некоторые вещи - библиотечные функции, апи, компиляторы - не должны обладать никакими признаками интеллекта. Потому что признаки интеллекта с неизбежностью приводят к существованию фантома "собственного мнения". А мне не нужно собственное мнение у таких утилит - у меня самого оно уже есть.
Хочется интеллектуальности - делаешь обёртку/свитч, который говорит - "а вот теперь если файл не найден там, где сказал программист, пытаемся поискать его рядом". Например. Но такое поведение по дефолту - безусловное зло.
Термин unforgiving по отношению к языку программирования/компилятору как раз означает что компилятор не пытается искать объявление переменной вообще везде, если не нашёл её там где она должна быть. ИМХО.
>Что там насчёт жонглирования двумя объектами?
Это ты о чём?
>Таким образом ООП делает шаг назад, отбрасывая достижения
>модульного программирования и не давая ничего взамен.
ООП ортогонально модульности. В случае жавы к модульности подошли таким образом, каким подошли. В случае шарпа рестрикшены немного снизили, и это удобно.
При пересечении смыслов слова "format" выбирается тот,
который следует из контекста.
И если "a" у меня в "format a" обозначает "disk", то я не обязан
лишний раз объяснять совсем тупому компилятору, что именно я хочу
сделать. Потому что я позаботился о том, чтобы "a" обозначало
"disk", а не "text".
"Жонглирование двумя объектами" --- это работа над двумя
равноправными объектами.
Мне, кстати, так и не объяснили, почему SML менее ОО,
чем всякие явы.
Декомпозиция объектов, кстати, точно так же ложится на ОО,
как и композиция?
---
...Я работаю антинаучным аферистом...
который следует из контекста.
И если "a" у меня в "format a" обозначает "disk", то я не обязан
лишний раз объяснять совсем тупому компилятору, что именно я хочу
сделать. Потому что я позаботился о том, чтобы "a" обозначало
"disk", а не "text".
"Жонглирование двумя объектами" --- это работа над двумя
равноправными объектами.
Мне, кстати, так и не объяснили, почему SML менее ОО,
чем всякие явы.
Декомпозиция объектов, кстати, точно так же ложится на ОО,
как и композиция?
---
...Я работаю антинаучным аферистом...
Ну и что дает эта фича. Позволяет сэкономить в написании на пару идентификаторов и пару точек. А какой ценой. Повышается вероятность совершния ошибки. Уменьшается читабельность кода. Сегодня рулит прагматизм, поэтому этот вопрос решают не в пользу твоей фичи.
При пересечении смыслов слова "format" выбирается тот,
который следует из контекста.
И если "a" у меня в "format a" обозначает "disk", то я не обязан
лишний раз объяснять совсем тупому компилятору, что именно я хочу
сделать. Потому что я позаботился о том, чтобы "a" обозначало
"disk", а не "text".
ГЫ гы Гы.
Formatter.Format(new DiskName("a:";
Где DiskName это алиас на string.
Охуенная идея.
Мой практически опыт мне говорит, что
DiskTools.Formatter.Format("a:");
удобнее, понятнее и вообще.
Formatter.Format(new DiskName("a:";
Где DiskName это алиас на string.
Охуенная идея.
Мой практически опыт мне говорит, что
DiskTools.Formatter.Format("a:");
удобнее, понятнее и вообще.
Скорее, так:
use DiskFormatter;
use TextFormatter;
format (disk_name "a");
format (text_format <.....>) "arg1" "arg2" .... ;
Ну да. Отказались от слова new. Отлично!
Ну да мне пофиг. Я считаю, что в моей записи сразу понятно, что за format должен отработать в каждом случае.
В более сложных случаях никто не мешает явно указать модуль, я например так делаю, в случае,
если рядом нет никаких подсказок.
В более сложных случаях никто не мешает явно указать модуль, я например так делаю, в случае,
если рядом нет никаких подсказок.
Чем это фактически отличается от:
use DiskFormatter;
use TextFormatter;
format (disk_name "a");
format (text_format <.....>) "arg1" "arg2" .... ;
Где format такого составного объекта выглядит как (выполняется это на уровне компилятора, или на уровне runtime-а не важно).
(DiskFormatterNamespace + TextFormatterNamespace).format(disk_name("а";
зы
ComplexNamespace.format(object obj)
{
if (obj.GetType is Disk && obj.GetType is Text)
throw Error;
if (obj.GetType is Disk)
DiskFormatter.formatDisk)obj);
if (obj.GetType is Text)
TextFormatter.formatText)obj);
throw Error;
}
объекты есть - и с этим ничего не поделать.
поэтому мне не понятно, как можно пользоваться языком, который отрицает существование объектов.
ггг ты промахнулся мимо треда имхо =) тут модульность обсуждают =)
Вот этим:
Ты опять ввёл лишнюю сущность.
Этакий павлиноуткоёж: не диск, не текст.
---
...Я работаю антинаучным аферистом...
(DiskFormatterNamespace + TextFormatterNamespace)
Ты опять ввёл лишнюю сущность.
Этакий павлиноуткоёж: не диск, не текст.
---
...Я работаю антинаучным аферистом...
> Ты опять ввёл лишнюю сущность.
Ее ввел (а не я когда написал:
use A; use B;
Т.е. получается, что и godfather и его компилятор понимают, что есть совокупный namespace - который устроен по тем правилам, которые я и выписал.
Ее ввел (а не я когда написал:
use A; use B;
Т.е. получается, что и godfather и его компилятор понимают, что есть совокупный namespace - который устроен по тем правилам, которые я и выписал.
(DiskFormatterNamespace + TextFormatterNamespace)
Какого типа значение вовзращает "+"?
Тебе, кажется, надо класс павлиноуткоежей ввести?
В нашем случае, этой фигни не надо, оно пишется один раз
и на всю область видимости.
---
...Я работаю антинаучным аферистом...
> Какого типа значение вовзращает "+"?
например, object
например, object
Прощай, строгая типизация?
Неудивительно тогда, почему ООП так любят полностью указывать имена.
Контекста не хватает. Выразительности.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
Неудивительно тогда, почему ООП так любят полностью указывать имена.
Контекста не хватает. Выразительности.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Karel Capek
Зачем тебе нужна строгая типизация?
какая цель?
какая цель?
Цель обычная: писать и отлаживать меньше, а делать больше.
Строгая типизация даёт возможность перекрывать имена
и не писать типы аргументов в именах функций.
В том числе --- не писать явно, из которого модуля пришла функция,
если это понятно по сигнатуре.
---
...Я работаю антинаучным аферистом...
Строгая типизация даёт возможность перекрывать имена
и не писать типы аргументов в именах функций.
В том числе --- не писать явно, из которого модуля пришла функция,
если это понятно по сигнатуре.
---
...Я работаю антинаучным аферистом...
> В том числе --- не писать явно, из которого модуля пришла функция,
> если это понятно по сигнатуре.
Какое отношение это имеет к стат. типизации?
Почему это нельзя делать динамически?
> если это понятно по сигнатуре.
Какое отношение это имеет к стат. типизации?
Почему это нельзя делать динамически?
Прямое.
В случае динамической типизации это будет слишком медленно,
если не использовать искусственных приёмов, один из которых,
очень ограниченный, проталкивает ООП.
Любая динамическая типизация откладывает отладку со времени
компиляции на время прогона, что грозит пропуском ошибки.
---
...Я работаю антинаучным аферистом...
В случае динамической типизации это будет слишком медленно,
если не использовать искусственных приёмов, один из которых,
очень ограниченный, проталкивает ООП.
Любая динамическая типизация откладывает отладку со времени
компиляции на время прогона, что грозит пропуском ошибки.
---
...Я работаю антинаучным аферистом...
Очень мало программ хорошо ложится на стат. типизацию.
Это только у тех, у кого система типов слабовата.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
> Это только у тех, у кого система типов слабовата.
Скорее те, у которых кол-во вариантов видов очень мало.
Слабо написать граф. редактор на стат. типизации?
Скорее те, у которых кол-во вариантов видов очень мало.
Слабо написать граф. редактор на стат. типизации?
Прикинь, у Микрософта есть статья про такое на Хаскелле.
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
---
"Narrowness of experience leads to narrowness of imagination."
Rob Pike
и у них получился полноценный граф. редактор?
и там даже групповые операции есть?
и там даже групповые операции есть?
Да.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
дай, плиз, ссылку.
Я её уже ищу.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Начинать отсюда: http://research.microsoft.com/research/pubs/view.aspx?pubid=180
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Оставить комментарий
Ivan8209
Последнее неверно: ООП включает абстракцию данных, что мешает абстрагировать иными способами.Насчёт модульного... Сложно сказать.
Области видимости разделить сложно, какие-то объекты останутся за бортом,
а значит --- должны быть умерщвлены, потому что не существуют в ходе работы.
Получается, что ООП подразумевают одну область видимости,
то есть это шаг назад по отношению к модульности.
Надо будет подумать.
Во.
Делаем так.
Я утверждаю вот что:
ООП --- отстой.
Потому что не только ничерта не учитывает достижений
модульного программирования, но и является шагом назад,
отбрасывая все эти достижения и ничего не давая взамен.
---
"Я знаю правду! Все прежние правды --- прочь!"