Здравствуйте, Cyberax, Вы писали:
C>>>Meanwhile in IDEA: http://blog.jetbrains.com/idea/2012/08/complete-static-methods-and-fields-with-the-new-intellij-idea-12-eap-build-12229/ BDA>>Талант у человека — что ни напишет, все не в тему. Взять IDE от Java вместо CLion, притянуть поиск по именам в статических методах вместо ПОДБОРА ВСЕХ ПОДДЕРЖИВАЕМЫХ АЛГОРИТМОВ ПО ОБЪЕКТУ, а потом ололокать — это не говнопрограммистом надо быть, а я не знаю, кем. C>Я понимаю, у вас в String запиханы ВСЕ методы, которые когда-либо работают со строкой. Для тех методов, которые со строками не работают по каким-то надуманным причинам — сделаны строковые обёртки.
C>А программы пишутся выбором методов после "MyNameIsVasja".ctrl-space. При этом заранее неизвестно что за метод нужен, программист всегда пробегает по всему списку методов и выбирает наиболее интересный.
C>Ну типа, надо вызвать disk.getInfo() и программист пишет "MyNameIsVasja".getDiskBlockInfo(disk). При этом интеллисенс очен вежливо подсказывает, какой именно disk должен попасть в параметр!
C>Да, я начинаю понимать всю всемогущность такой техники! Завтра же переписываю все свои программы!
Ядовитость и острота хороши тогда, когда ими приправлен хорошо продуманный и полезный ответ. Когда ответ как у вас — тупой бесформенный пельмень из сои — а вы его еще и поливаете уксусом, впечатление совсем другое.
Я написал, что в Джаве найти по части имени статические методы всех известных классов — это не то же самое, что найти все алгоритмы в C++, которые могут быть применены к объекту o типа T. Не находите в себе сил признать, что пример притянут за уши и другие внешние органы — не пишите ничего.
Здравствуйте, 0BD11A0D, Вы писали:
C>>Ну типа, надо вызвать disk.getInfo() и программист пишет "MyNameIsVasja".getDiskBlockInfo(disk). При этом интеллисенс очен вежливо подсказывает, какой именно disk должен попасть в параметр! C>>Да, я начинаю понимать всю всемогущность такой техники! Завтра же переписываю все свои программы! BDA>Я написал, что в Джаве найти по части имени статические методы всех известных классов — это не то же самое, что найти все алгоритмы в C++, которые могут быть применены к объекту o типа T.
Что конкретно "не так"? Это ровно та же задача, для С++ она только немного сложнее. Принципиальной разницы нет.
BDA>Не находите в себе сил признать, что пример притянут за уши и другие внешние органы — не пишите ничего.
Ну я понимаю, у тебя интеллисенс головного мозга, осложнённый двусторонним ООП, и всё такое.
Здравствуйте, Cyberax, Вы писали:
C>Что конкретно "не так"? Это ровно та же задача, для С++ она только немного сложнее. Принципиальной разницы нет.
Если разницы нет, почему бы не привести сразу «правильный» пример? Хотя бы одну IDE, которая решает поставленную мною задачу. Это же так легко — р-раз, и я понимаю, что кругом неправ.
Здравствуйте, Eugeny__, Вы писали:
E__>Что значит "редкий сценарий"? Программы работают с внешними данными, характер которых и размер на этапе компиляции по определению неизвестен. Иначе на кой хрен та программа вообще нужна?
Здравствуйте, greenpci, Вы писали:
G>так как он был неразрывно связан с нашими данными.
Тогда вам бы вообще ничего не подошло. Зная характер и особенности данных всегда можно придумать более оптимальную их обработку. Ты демки в 90е не писал ? Обалдел бы, что и как можно выжать из убогенького 8битного камня. Просто хитрой организацией обрабатываемых данных. Даже не в сотни, в тысячи и десятки тысяч раз ускорение.
Очень показательно, что Cyberax даже не попытался зафиксировать меня в рамки, потребовав формализовать задачу (поставленную мною). Хотя я бы первым делом это потребовал. Поскольку победить Cyberax'а мне неинтересно (по причинам, которые ему показались бы обидными, если бы я их озвучил), я сделаю необходимое уточнение сам, добровольно: вдруг кто-то еще покажет мне, что C++ вовсе не так ужасен (а вот это будет интересно).
std::wstring s = L"Москва,Новосибирск,Париж,Лондон,Владивосток";
Панасюк выше написал (про IDE):
>пусть делают новые формы дополнения, а не только "через точку"
Окей, мы не будем ставить точку и ждать интеллисенса. Мы нажмем любую комбинация клавиш и будем ждать вывода в любой форме, пусть хоть в консоль, а вывестись должно следующее: какие операции (алгоритмы) нам вообще доступны для объекта s? То есть, то, что я назвал индексом контрактов. Что нас интересует (так уж сформулирована задача), это получение списка городов, заданного строкой, как коллекции. Чтобы сложить с другим списком-коллекцией, например.
Спрашивается, КАК IDE должна понять, что это типичный алгоритм, применимый к s? Что это за «новая форма дополнения»? Разумеется, это просто невозможно. Мы или будем искать статику, куда можно отдать строку, и погрязнем в куче бесполезных вхождений, или пропустим полезное.
Хорошо, а как это понимает человек? Человек читает мануалы, спрашивает у других человеков и Гугла и опирается на неявное знание. Которое можно сделать явным, сжулив и научив IDE понимать, что такому-то классу соответствует такой-то набор алгоритмов. И вся эта схема идет по звезде, потому, что boost не часть языка. Если он не подключен, компилятор должен ругаться на include, а не советовать вызвать неподключенный метод. Хорошо, определяем, подключен boost или нет. А ЧТО ЕСЛИ ПОДКЛЮЧИТЬ ЕГО, А ЗАТЕМ УДАЛИТЬ split? Все, тут мы приплываем окончательно.
В случае с FCL студии жулить смысла нет, поскольку проблему и невозможность его создатели понимали отлично. Поэтому там принято соглашение неявное знание делать явным другим путем: универсальным путем вписывания алгоритмов в классы. Чуть позже создатели языка формализовали синтаксис extension, чтобы алгоритмы можно было дописывать, оставаясь в рамках того же способа явно привязать алгоритм к классу.
К чему это ведет, я показал. Задача посмотреть список контрактов принципиально неавтоматизируема ни в каком виде. Например, если у какого-то... товарища смех без причины при виде интеллисенса, можно было бы попросить IDE построить диаграмму. В случае со стандартной библиотекой беда не так страшна. Есть три инструмента — StackOverflow, Google и много-много нейронных сетей — которые приготовили тебе список на блюде, задай только вопрос на английском языке (такой вот интеллисенс). Но когда человек с забустованным мозгом садится писать свою систему, он воспроизводит тот же паттерн, да еще считает, что делает хорошее дело. ЕГО библиотеку, однако, использует три с половиной анонима, вопросы на СО не задаются, Гугл про это ничего не знает. А значит, есть только один способ не прошляпить то, что нужно — выкурить ВЕСЬ код от начала до конца. Что, конечно, писуну этого кода очень нравится. Но не способствует популярности ни библиотеки, ни языка, на котором она создавалась.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Eugeny__, Вы писали:
E__>>Что значит "редкий сценарий"? Программы работают с внешними данными, характер которых и размер на этапе компиляции по определению неизвестен. Иначе на кой хрен та программа вообще нужна?
IID>Почему нельзя поставить оценку "фейспалм" ?
Объясни, пожалуйста.
Внешние данные могут занимать килобайты, мегабайты, и терабайты, а также сотни тысяч терабайт, приходить порциями от нескольких байт до терабайт. В чем фейспалм?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>>>Как раз интеллисенс играет тут первую скрипку. Вы открываете его окошко и видите ВСЕ возможности некоторого класса. EP>>Нет, далеко не все. Например он не покажет что этот объект может быть аргументом у метода другого объекта BDA>Потому, что это информация не об объекте.
То есть ты считаешь что эта информация настолько незначительная, что её можно не показывать, а вот информация о методах — это must-have?
EP>>это скорее вопрос к IDE — пусть делают новые формы дополнения, а не только "через точку" BDA>Это принципиально невозможно.
Что невозможно? Получить список функций для которых данный объект может быть аргументом? Не считая случаи какого-нибудь сильного TMP/duck-typing — то всё возможно.
В любом случае "дополнение через точку" не стоит того чтобы уродовать язык и код — да и главным преимуществом ООП уж точно не является.
BDA>>>Альтернатива — курить маны. То есть, вышел новый стандарт, новый STL, новый boost и вы должны сразу прочитать, понять и запомнить все, что написано в сопроводиловке. EP>>Читать документацию придётся в любом случае, чтобы знать контракты. BDA>В хорошем коде контракты выражены через него же.
А как например выражается алгоритмическая сложность, список возможных исключений, и exception safety guarantee? Не говоря уже о том, что на последовательность вызова методов могут быть наложены некоторые ограничения.
IntelliSense Oriented Development возможен только в примитивнейших случаях типа установки свойств формы и т.п. В общем же случае от него польза только в качестве подсказки правильного имени метода/поля.
EP>>А это вообще ортогонально. Декомпозицию на контейнеры и алгоритмы можно делать и в что называется в "true OO style". То есть смотришь ты "с высоты птичьего полета" на класс UTF-8 строки, и видишь что она реализует IBidirectionalSequence, далее смотришь на алгоритмы которые принимают IBidirectionalSequence — и находишь там to_lower, split или что там нужно. BDA>Когда вы покажете, что в IDE можно сделать интеллисенс, не основанный на инкапсуляции, я соглашусь.
* глобальные функции дополняются без всякой инкапсуляции.
* MSVS C# умеет дополнять extension method'ы — которые по сути те же внешние функции. Думаю очевидно что такое же дополнение возможно без ключевого слова this и без специального синтаксиса вызова глобальной функции.
BDA>Но выше я утверждаю, что это невозможно. Однако бремя доказательства обратного я возлагаю на вас — ведь это вы написали «пусть делают новые формы дополнения», вам и показывать, КАК ИМЕННО.
А что конкретно не понятно? Как найти список функций? Или как инициировать такое дополнение?
EP>>Или ты против такой декомпозиции вообще? Тогда например для каждой строки (и контейнера в общем) придётся придётся реализовывать каждый алгоритм — M контейнеров * N алгоритмов BDA>Зачем? Если алгоритму не важен тип контейнера, он может быть реализован в классе АбстрактныйКонтейнер, а затем переопределен в более специфическом классе. Никакого комбинаторного взрыва.
Предлагаешь наследовать реализацию? Сразу получаем проблемы в языках без множественного наследования.
Да и как расширять? Как добавить новый алгоритм без изменения?
BDA>>>Как раз вынесение алгоритмов за пределы классов принципиально и не дает воспользоваться этим преимуществом ООП. Процедурщина и хендловщина в полный рост. EP>>Ты так говоришь как будто "true OOP" это всегда хорошо, а "процедурщина" плохо. BDA>С меня будет достаточно, если вы подтвердите, что стандартная библиотека C++ — не true OOP.
Она не true OOP ни в каких смыслах.
BDA>Хорошо это или плохо, мы поговорим в другой раз.
Конечно же это хорошо, я бы сказал что это большая удача что C++ пошёл по этому пути.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BDA>>>>Как раз интеллисенс играет тут первую скрипку. Вы открываете его окошко и видите ВСЕ возможности некоторого класса. EP>>>Нет, далеко не все. Например он не покажет что этот объект может быть аргументом у метода другого объекта BDA>>Потому, что это информация не об объекте.
EP>То есть ты считаешь что эта информация настолько незначительная, что её можно не показывать, а вот информация о методах — это must-have?
Да, она менее значительна (вплоть до полной незначительности).
Пример: File OpenFile(String name); — это незначительно в контексте String s, если s = "Мама мыла раму", а не "/etc/www/blah-blah-blah.htm".
И вот такого мусора вывалится ГОРА. И ничего с этим не сделать. Поэтому все значительное умные люди инкапсулируют либо маскируют под инкапсуляцию (extension). Это прямо вот такой способ указать на значительность. Которую все равно надо указывать явно.
EP>>>это скорее вопрос к IDE — пусть делают новые формы дополнения, а не только "через точку" BDA>>Это принципиально невозможно.
EP>Что невозможно? Получить список функций для которых данный объект может быть аргументом? Не считая случаи какого-нибудь сильного TMP/duck-typing — то всё возможно.
EP>В любом случае "дополнение через точку" не стоит того чтобы уродовать язык и код — да и главным преимуществом ООП уж точно не является.
Не просто главным, а единственным (известным мне). Конечно, не само по себе, а как маркер. Я могу писать в блокноте без интеллисенса, предварительно осмотрев класс, но не могу, не изучив проект досконально, понять, что полагается делать с некоторым набором данных, если автор это не формализовал. То есть, на моделирование проекта в голове уйдет времени намного больше и оно будет потрачено неэффективно — мне придется рутинную работу делать как творческую.
Все. А какие еще у него есть преимущества, по-вашему? Сокрытие и защита данных? Так хендлы давно это делают. Безопасность? Смешно. Какие?
BDA>>>>Альтернатива — курить маны. То есть, вышел новый стандарт, новый STL, новый boost и вы должны сразу прочитать, понять и запомнить все, что написано в сопроводиловке. EP>>>Читать документацию придётся в любом случае, чтобы знать контракты. BDA>>В хорошем коде контракты выражены через него же.
EP>А как например выражается алгоритмическая сложность, список возможных исключений, и exception safety guarantee? Не говоря уже о том, что на последовательность вызова методов могут быть наложены некоторые ограничения. EP>IntelliSense Oriented Development возможен только в примитивнейших случаях типа установки свойств формы и т.п. В общем же случае от него польза только в качестве подсказки правильного имени метода/поля.
Как например? Так вам надо поискать примеры. Они есть.
EP>>>А это вообще ортогонально. Декомпозицию на контейнеры и алгоритмы можно делать и в что называется в "true OO style". То есть смотришь ты "с высоты птичьего полета" на класс UTF-8 строки, и видишь что она реализует IBidirectionalSequence, далее смотришь на алгоритмы которые принимают IBidirectionalSequence — и находишь там to_lower, split или что там нужно. BDA>>Когда вы покажете, что в IDE можно сделать интеллисенс, не основанный на инкапсуляции, я соглашусь.
EP>* глобальные функции дополняются без всякой инкапсуляции.
Нет, это невозможно, я показал это на примере с boost::split по ссылке выше.
EP>* MSVS C# умеет дополнять extension method'ы — которые по сути те же внешние функции. Думаю очевидно что такое же дополнение возможно без ключевого слова this и без специального синтаксиса вызова глобальной функции.
Ага, ехали Ландау с Лившицем в такси...
Не только не очевидно, но и ложно. C# потому и C#, что в нем не стали повторять ошибок C++. Вся роль extension'ов сводится к тому, чтобы маркировать статику в явном виде, как предназначенную для классов, в тех случаях, когда это невозможно сделать при помощи инкапсуляции (кастомизация или разделение во времени). Если их НЕ маркировать, получим (в этом отношении) C++, в котором знания о привязке просто ТЕРЯЮТСЯ. И уж точно автоматизировать эту работу будет нельзя.
В следующий раз, когда захочется написать «очевидно», опишите сразу как и почему.
BDA>>Но выше я утверждаю, что это невозможно. Однако бремя доказательства обратного я возлагаю на вас — ведь это вы написали «пусть делают новые формы дополнения», вам и показывать, КАК ИМЕННО.
EP>А что конкретно не понятно? Как найти список функций? Или как инициировать такое дополнение?
Вот это продуктивный подход, уважаю. Ответ по той же самой ссылке.
EP>>>Или ты против такой декомпозиции вообще? Тогда например для каждой строки (и контейнера в общем) придётся придётся реализовывать каждый алгоритм — M контейнеров * N алгоритмов BDA>>Зачем? Если алгоритму не важен тип контейнера, он может быть реализован в классе АбстрактныйКонтейнер, а затем переопределен в более специфическом классе. Никакого комбинаторного взрыва.
EP>Предлагаешь наследовать реализацию? Сразу получаем проблемы в языках без множественного наследования. EP>Да и как расширять? Как добавить новый алгоритм без изменения?
Вы слишком уводите тему в сторону. В этой теме, в этой ее ветке, речь идет о способе организации стандартной библиотеки, которая содержит в себе конечный набор алгоритмов. Что делать, когда нужен свой, новый, предлагаю обсудить на примере.
Здравствуйте, 0BD11A0D, Вы писали:
EP>>То есть ты считаешь что эта информация настолько незначительная, что её можно не показывать, а вот информация о методах — это must-have? BDA>Да, она менее значительна (вплоть до полной незначительности). BDA>Пример: File OpenFile(String name); — это незначительно в контексте String s, если s = "Мама мыла раму", а не "/etc/www/blah-blah-blah.htm". BDA>И вот такого мусора вывалится ГОРА. И ничего с этим не сделать. Поэтому все значительное умные люди инкапсулируют либо маскируют под инкапсуляцию (extension). BDA>Это прямо вот такой способ указать на значительность. Которую все равно надо указывать явно.
Во-первых нужно правильно сортировать варианты. Например функции из того же namespace — более приоритетные. В более общем виде — чем меньше расстояние в дереве namespace'ов — тем выше приоритет.
Во-вторых рулит type-rich programming. Например path вместо string.
EP>>>>это скорее вопрос к IDE — пусть делают новые формы дополнения, а не только "через точку" BDA>>>Это принципиально невозможно. EP>>Что невозможно? Получить список функций для которых данный объект может быть аргументом? Не считая случаи какого-нибудь сильного TMP/duck-typing — то всё возможно. BDA>Вот что невозможно: BDA>http://rsdn.ru/forum/flame.comp/6063107.1
Там говорится про "типичный" алгоритм — но если у класса сотни методов то как IDE должна выбрать из них "типичные"?
EP>>В любом случае "дополнение через точку" не стоит того чтобы уродовать язык и код — да и главным преимуществом ООП уж точно не является. BDA>Не просто главным, а единственным (известным мне). Конечно, не само по себе, а как маркер.
Всё же "единственным" или просто "маркер"?
Вот если бы не было авто-дополнения — ты бы вообще использовал ООП?
BDA>Я могу писать в блокноте без интеллисенса, предварительно осмотрев класс, но не могу, не изучив проект досконально, понять, что полагается делать с некоторым набором данных, если автор это не формализовал. То есть, на моделирование проекта в голове уйдет времени намного больше и оно будет потрачено неэффективно — мне придется рутинную работу делать как творческую.
И как тут помогает ООП? Ты моделируешь проект бегая по коду с IntelliSense'ом?
BDA>Все. А какие еще у него есть преимущества, по-вашему? Сокрытие и защита данных? Так хендлы давно это делают. Безопасность? Смешно. Какие?
Например иерархичность — в некоторых областях это действительно удобно и естественно, правда далеко не во всех.
EP>>>>Читать документацию придётся в любом случае, чтобы знать контракты. BDA>>>В хорошем коде контракты выражены через него же. EP>>А как например выражается алгоритмическая сложность, список возможных исключений, и exception safety guarantee? Не говоря уже о том, что на последовательность вызова методов могут быть наложены некоторые ограничения. EP>>IntelliSense Oriented Development возможен только в примитивнейших случаях типа установки свойств формы и т.п. В общем же случае от него польза только в качестве подсказки правильного имени метода/поля. BDA>Как например? Так вам надо поискать примеры. Они есть.
Примеры IntelliSense Oriented Development я действительно видел — "нужно добавить элементы. что тут у нас есть? ага — add, его и заюзаем — клац" — и в итоге получаем квадратическую сложность на ровном месте, потому что в контракт не смотрели. Что характерно, я фиксил подобное с помощью документации и "блокнота", даже без возможности скомпилировать.
EP>>>>А это вообще ортогонально. Декомпозицию на контейнеры и алгоритмы можно делать и в что называется в "true OO style". То есть смотришь ты "с высоты птичьего полета" на класс UTF-8 строки, и видишь что она реализует IBidirectionalSequence, далее смотришь на алгоритмы которые принимают IBidirectionalSequence — и находишь там to_lower, split или что там нужно. BDA>>>Когда вы покажете, что в IDE можно сделать интеллисенс, не основанный на инкапсуляции, я соглашусь. EP>>* глобальные функции дополняются без всякой инкапсуляции. BDA>Нет, это невозможно, я показал это на примере с boost::split по ссылке выше.
Конкретно здесь речь об дополнении имени функции по части её имени, а не по типам аргументов.
"IntelliSense не основанный на инкапсуляции" в чистом виде
EP>>* MSVS C# умеет дополнять extension method'ы — которые по сути те же внешние функции. Думаю очевидно что такое же дополнение возможно без ключевого слова this и без специального синтаксиса вызова глобальной функции. BDA>Ага, ехали Ландау с Лившицем в такси... BDA>Не только не очевидно, но и ложно. C# потому и C#, что в нем не стали повторять ошибок C++. Вся роль extension'ов сводится к тому, чтобы маркировать статику в явном виде, как предназначенную для классов, в тех случаях, когда это невозможно сделать при помощи инкапсуляции (кастомизация или разделение во времени). Если их НЕ маркировать, получим (в этом отношении) C++, в котором знания о привязке просто ТЕРЯЮТСЯ. И уж точно автоматизировать эту работу будет нельзя. BDA>В следующий раз, когда захочется написать «очевидно», опишите сразу как и почему.
А я и описал. Непонятно с чем конкртено ты не согласен. Могу ещё раз повторить: убери ключевое слово this из extension method'ов в C# и специальный синтаксис вызова — как ты думаешь, будет ли технически возможно автодополнение в таком случае, и если нет то почему.
EP>>Предлагаешь наследовать реализацию? Сразу получаем проблемы в языках без множественного наследования. EP>>Да и как расширять? Как добавить новый алгоритм без изменения? BDA>Вы слишком уводите тему в сторону. В этой теме, в этой ее ветке, речь идет о способе организации стандартной библиотеки, которая содержит в себе конечный набор алгоритмов. Что делать, когда нужен свой, новый, предлагаю обсудить на примере.
1. Не вижу смысла ограничиваться стандартной библиотекой, да и не думал что в этой ветке такое ограничение.
2. Не вижу смысла уродовать код библиотеки (тем более стандартной) и сваливать внешние по сути алгоритмы во внутрь всех контейнеров, только из-за возможности получить автодополнение через точку.
3. Алгоритмов очень много, далеко не все есть в стандартной библиотеке, расширять набор алгоритмов рано или поздно всё равно придётся.
Здравствуйте, greenpci, Вы писали:
G>Могу подтвердить. Производил замеры памяти и скорости, и пришлось отказаться от std::map и std::vector<bool> (отдельная спецификация вектора) в нашем продукте в пользу других реализаций, хотя очень хотелось использовать СТЛевские. Надо сказать, что создатели и не претендавали на самую быструю реализацию. Задача была выбрать меньшее из зол и удовлетворить большинство.
EP>>это скорее вопрос к IDE — пусть делают новые формы дополнения, а не только "через точку" BDA>Это принципиально невозможно.
Принципиально это возможно, всего лишь небольшое изменение в язык. Только это не нужно. Дополнения должны вызываться точно так же, как и основные методы, что бы не было никакой разницы с тз. синтаксиса.
x.Method(y)
x.ExtensionMethod(y)
x `Method` y
x `ExtensionMethod` y
BDA>Когда вы покажете, что в IDE можно сделать интеллисенс, не основанный на инкапсуляции, я соглашусь. Но выше я утверждаю, что это невозможно. Однако бремя доказательства обратного я возлагаю на вас — ведь это вы написали «пусть делают новые формы дополнения», вам и показывать, КАК ИМЕННО.
Ужос. Экстншны в шарпе сделаны как раз не на инкапсуляции и отлично поддерживаются IDE.
Здравствуйте, Ikemefula, Вы писали:
I>Дополнения должны вызываться точно так же, как и основные методы, что бы не было никакой разницы с тз. синтаксиса.
1. Чем плоха эта разница?
2. Почему внешние функции должны вызываться как внутренние, а не наоборот?
3. Extension методы работают только по первому параметру, в то время когда автодополнение возможно по любому — и в этом случае синтаксис "через точку" пролетает.
Вызовы через точку хороши только когда нужно делать method chaining — то есть эдакая инфиксность.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Дополнения должны вызываться точно так же, как и основные методы, что бы не было никакой разницы с тз. синтаксиса.
EP>1. Чем плоха эта разница?
Ломает полиморфизм.
EP>2. Почему внешние функции должны вызываться как внутренние, а не наоборот?
Смотри внимательно пример кода, там оба варианта.
EP>3. Extension методы работают только по первому параметру, в то время когда автодополнение возможно по любому — и в этом случае синтаксис "через точку" пролетает.
"через точку" это специальный случай
EP>P.S. Вот статья
Здравствуйте, 0BD11A0D, Вы писали:
EP>>* MSVS C# умеет дополнять extension method'ы — которые по сути те же внешние функции. Думаю очевидно что такое же дополнение возможно без ключевого слова this и без специального синтаксиса вызова глобальной функции.
BDA>Не только не очевидно, но и ложно. C# потому и C#, что в нем не стали повторять ошибок C++. Вся роль extension'ов сводится к тому, чтобы маркировать статику в явном виде, как предназначенную для классов, в тех случаях, когда это невозможно сделать при помощи инкапсуляции (кастомизация или разделение во времени). Если их НЕ маркировать, получим (в этом отношении) C++, в котором знания о привязке просто ТЕРЯЮТСЯ. И уж точно автоматизировать эту работу будет нельзя.
Роль экстеншнов это вобщем инкапсуляция + полиморфизм, как это странно ни звучит.
Здравствуйте, 0BD11A0D, Вы писали:
C>>Что конкретно "не так"? Это ровно та же задача, для С++ она только немного сложнее. Принципиальной разницы нет. BDA>Если разницы нет, почему бы не привести сразу «правильный» пример? Хотя бы одну IDE, которая решает поставленную мною задачу. Это же так легко — р-раз, и я понимаю, что кругом неправ.
Clion. Запусти и посмотри, БЛДЖАД. Не для всех случаев пока что, но уже вполне нормально.
Я уж не говорю о том, что слегка кретинично ставить во главу угла то, что через intellisense говнодебил сможет найти метод с примерно подходящим названием.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Во-первых нужно правильно сортировать варианты. Например функции из того же namespace — более приоритетные. В более общем виде — чем меньше расстояние в дереве namespace'ов — тем выше приоритет.
Еще чуть-чуть, и окажется, что class — САМЫЙ приоритетный namespace. Просто доведите свою мысль до конца.
EP>Во-вторых рулит type-rich programming. Например path вместо string.
Про path я думал, идея неплохая. Если добавить поддержку частей пути как списка и неявное преобразование в строки, я бы одобрил.
Ну хорошо — конструктор нового исключения. Предельно близок по неймсейсам, тип однозначно строковый. Будет вылезать всегда. И?
EP>>>>>это скорее вопрос к IDE — пусть делают новые формы дополнения, а не только "через точку" BDA>>>>Это принципиально невозможно. EP>>>Что невозможно? Получить список функций для которых данный объект может быть аргументом? Не считая случаи какого-нибудь сильного TMP/duck-typing — то всё возможно. BDA>>Вот что невозможно: BDA>>http://rsdn.ru/forum/flame.comp/6063107.1
EP>Там говорится про "типичный" алгоритм — но если у класса сотни методов то как IDE должна выбрать из них "типичные"?
Все методы, явно помещеные в класс — типичные. Типичными их делает как раз помещение туда. Дура-IDE должна показывать все молча. И, конечно, это авторский замысел, то есть, некая модель программистских представлений о сущностях. Например, регексы в FCL лежат отдельно, хотя ничего не мешало бы... То есть, не надо искать тут закономерностей, это удачное (или не очень) представление авторов кода о типичности.
EP>>>В любом случае "дополнение через точку" не стоит того чтобы уродовать язык и код — да и главным преимуществом ООП уж точно не является. BDA>>Не просто главным, а единственным (известным мне). Конечно, не само по себе, а как маркер.
EP>Всё же "единственным" или просто "маркер"? EP>Вот если бы не было авто-дополнения — ты бы вообще использовал ООП?
Удивительно вы разбиваете текст, который читаете. Ниже ответ, стоило ли задавать вопрос?
BDA>>Я могу писать в блокноте без интеллисенса, предварительно осмотрев класс, но не могу, не изучив проект досконально, понять, что полагается делать с некоторым набором данных, если автор это не формализовал. То есть, на моделирование проекта в голове уйдет времени намного больше и оно будет потрачено неэффективно — мне придется рутинную работу делать как творческую.
EP>И как тут помогает ООП? Ты моделируешь проект бегая по коду с IntelliSense'ом?
По-моему, я все понятно написал и на все ответил.
BDA>>Все. А какие еще у него есть преимущества, по-вашему? Сокрытие и защита данных? Так хендлы давно это делают. Безопасность? Смешно. Какие?
EP>Например иерархичность — в некоторых областях это действительно удобно и естественно, правда далеко не во всех.
Ну, это долгая песня — является ли иерархичность непременным атрибутом ООП. Тратить время на нее не хочу, скажу просто, что с моей точки зрения она очень рульная вещь, но вторичная.
EP>>>А как например выражается алгоритмическая сложность, список возможных исключений, и exception safety guarantee? Не говоря уже о том, что на последовательность вызова методов могут быть наложены некоторые ограничения. EP>>>IntelliSense Oriented Development возможен только в примитивнейших случаях типа установки свойств формы и т.п. В общем же случае от него польза только в качестве подсказки правильного имени метода/поля. BDA>>Как например? Так вам надо поискать примеры. Они есть.
EP>Примеры IntelliSense Oriented Development я действительно видел — "нужно добавить элементы. что тут у нас есть? ага — add, его и заюзаем — клац" — и в итоге получаем квадратическую сложность на ровном месте, потому что в контракт не смотрели. Что характерно, я фиксил подобное с помощью документации и "блокнота", даже без возможности скомпилировать.
Я тоже много чего видел. Например, площадь Сан-Марко, как мне тут с утра напомнили. Но я же не пишу обо всем об этом, а пишу только о том, что имеет отношение к вопросам и ответам. Вопрос был — «А как например выражается алгоритмическая сложность, список возможных исключений». Я говорю: есть такие примеры и вы можете их найти самостоятельно. Незачем зацикливаться на C++.
EP>Конкретно здесь речь об дополнении имени функции по части её имени, а не по типам аргументов. EP>"IntelliSense не основанный на инкапсуляции" в чистом виде
Ну конечно, сейчас уже речь пойдет о том, чтобы часть имени указывать. Как иначе гору мусора фильтровать. Вы мне покажите ВСЕ операции. И чтобы мусора не было. В FCL все это есть и упаковано в вызывающий у некоторых смех интеллисенс. На меньшее не согласен. И никто, кто его видел вживую, а не в книжках с картинками и без, обратно к std возвращаться не хочет.
BDA>>Не только не очевидно, но и ложно. C# потому и C#, что в нем не стали повторять ошибок C++. Вся роль extension'ов сводится к тому, чтобы маркировать статику в явном виде, как предназначенную для классов, в тех случаях, когда это невозможно сделать при помощи инкапсуляции (кастомизация или разделение во времени). Если их НЕ маркировать, получим (в этом отношении) C++, в котором знания о привязке просто ТЕРЯЮТСЯ. И уж точно автоматизировать эту работу будет нельзя. BDA>>В следующий раз, когда захочется написать «очевидно», опишите сразу как и почему.
EP>А я и описал. Непонятно с чем конкртено ты не согласен. Могу ещё раз повторить: убери ключевое слово this из extension method'ов в C# и специальный синтаксис вызова — как ты думаешь, будет ли технически возможно автодополнение в таком случае, и если нет то почему.
Нет, не будет. Потому, что ни IDE, ни компилятор в вашу голову залезть не может и понять, что это за функция — случайно совместимая по сигнатуре или задизайненная как extension — тоже не может. Вы там вверху начали предлагать косвенно указывать на близость к телу, например, поощрять избыточную типизацию или рулить неймспейсами. Зачем косвенно, когда можно все это делать прямо?
Я хотел найти описание необходимости this от создателей языка, но все, что нашел, это вот такую болтологию:
Первый НЕудачный ответ Эрика Липперта на моей памяти. Он просто уходит от ответа. Чем-то же они думали, когда вводили this, а не перебирали совместимые сигнатуры. Вот и надо было написать, зачем и почему было принято такое решение. Ответ, как ни крути, сводится к явной маркировке, но что мешало ответить по существу?
EP>1. Не вижу смысла ограничиваться стандартной библиотекой, да и не думал что в этой ветке такое ограничение. EP>2. Не вижу смысла уродовать код библиотеки (тем более стандартной) и сваливать внешние по сути алгоритмы во внутрь всех контейнеров, только из-за возможности получить автодополнение через точку. EP>3. Алгоритмов очень много, далеко не все есть в стандартной библиотеке, расширять набор алгоритмов рано или поздно всё равно придётся.
1. А я вижу и объяснил почему.
2. А я вижу и объяснил почему.
3. Я предложил привести пример, чтобы его разобрать, но вместо примера получил общие рассуждения.
Здравствуйте, Ikemefula, Вы писали:
I>Ужос. Экстншны в шарпе сделаны как раз не на инкапсуляции и отлично поддерживаются IDE.
Они сделаны на псевдоинкапсуляции, отложенной инкапсуляции, называйте как хотите. Суть в том, что и при включении метода в класс, и при написании extension'ов, требуется явно указывать принадлежность к классу. Это — суть. А если вам хочется формально до чего-нибудь доковыряться, пожалуйста: да, согласен, экстншны в шарпе сделаны как раз не на инкапсуляции и отлично поддерживаются IDE, +100500, вы правы, абсолютно справедливое утверждение, еще или хватит?
