Здравствуйте, 0BD11A0D, Вы писали:
C>>Clion. Запусти и посмотри, БЛДЖАД. Не для всех случаев пока что, но уже вполне нормально. BDA>Понятно с вами все. Я написал Clion — через постинг получаю Clion. Элиза какая-то просто.
Ну так запусти и посмотри.
EP>>Там говорится про "типичный" алгоритм — но если у класса сотни методов то как IDE должна выбрать из них "типичные"? BDA>Все методы, явно помещеные в класс — типичные. Типичными их делает как раз помещение туда.
То есть, в классе строки будут методы для:
1) Base64-кодирования
2) URL-кодирования
3) escape'а для shell'а
4) escape'а для другого shell'а
5) Санитизации строк для SQL injection'а
6) Случайной перестановки букв
7) Проверки пароля с помощью PBKDF2
8) Приготовления кофе.
BDA>Дура-IDE должна показывать все молча. И, конечно, это авторский замысел, то есть, некая модель программистских представлений о сущностях. Например, регексы в FCL лежат отдельно, хотя ничего не мешало бы... То есть, не надо искать тут закономерностей, это удачное (или не очень) представление авторов кода о типичности.
Вот и надо убрать это кретиническое представление вообще.
BDA>Я тоже много чего видел. Например, площадь Сан-Марко, как мне тут с утра напомнили. Но я же не пишу обо всем об этом, а пишу только о том, что имеет отношение к вопросам и ответам. Вопрос был — «А как например выражается алгоритмическая сложность, список возможных исключений». Я говорю: есть такие примеры и вы можете их найти самостоятельно. Незачем зацикливаться на C++.
Тебе говорят, что твой ООП головного моска, осложнённый intellisense'ом, приводит только к говнокоду.
Интеллисенс — это инструмент, которым надо уметь пользоваться, а не заменять им всё.
BDA>2. А я вижу и объяснил почему. BDA>3. Я предложил привести пример, чтобы его разобрать, но вместо примера получил общие рассуждения.
Ничерта ты не объяснил.
Тебя уже ткнули носом в твои же какашки. Несколько раз.
Минимальная модель проистекает из фундаментальнейшего принципа дизайна ПО — Single Responsibility Principle. Каждый логический модуль занимается только тем, что ему необходимо и не более.
В случае с классами и ООП правильный дизайн приводит к тому, что имеем небольшой компактный класс, доступ к состоянию которого ведётся через минимальный интерфейс. Этот интерфейс проектируется так, что с его помощью нельзя нарушить инварианты класса.
Всё остальное делается внешним кодом, который гарантированно не может нарушить инварианты, так как просто технически вынужден работать через безопасный интерфейс.
В реальности от этого иногда приходится отступать, но это не повод начинать пихать в класс непонятно что.
Здравствуйте, Ikemefula, Вы писали:
I>>>Дополнения должны вызываться точно так же, как и основные методы, что бы не было никакой разницы с тз. синтаксиса. EP>>1. Чем плоха эта разница? I>Ломает полиморфизм.
Да, согласен, это главный аргумент за унификацию синтаксиса (только не обязательно в сторону "вызова через точку").
EP>>2. Почему внешние функции должны вызываться как внутренние, а не наоборот? I>Смотри внимательно пример кода, там оба варианта.
Там оба варианта инфиксные, и нет синтаксиса вызова метода как обычной внешней функции — method(obj, x).
EP>>3. Extension методы работают только по первому параметру, в то время когда автодополнение возможно по любому — и в этом случае синтаксис "через точку" пролетает. I>"через точку" это специальный случай
Я о том и говорю — что для общего случая оно не подходит.
EP>>P.S. Вот статья
от Страуструпа на эту тему и обсуждение. I>Так себе идея и здесь вроде как нет ничего про "автодополнение возможно по любому".
Синтаксис вызова ортогонален возможности дополнения. Разве что "точка" может служить триггером дополнения, а без неё будет специальный хоткей или таймер.
I>Гораздо полезнее сделать чтото навроде x `f` y
Это мало чем отличается от x.f(y). Да и как например расширить этот синтаксис на мультиметоды, или просто методы с несколькими параметрами?
Здравствуйте, Cyberax, Вы писали:
BDA>>Все методы, явно помещеные в класс — типичные. Типичными их делает как раз помещение туда.
C>То есть, в классе строки будут методы для: C>1) Base64-кодирования C>2) URL-кодирования C>3) escape'а для shell'а C>4) escape'а для другого shell'а C>5) Санитизации строк для SQL injection'а C>6) Случайной перестановки букв C>7) Проверки пароля с помощью PBKDF2 C>8) Приготовления кофе.
Они будут у идиота, чье представление о строках и типичных операциях с ними — идиотское. И заметьте, тут только один человек такое предлагает.
Здравствуйте, 0BD11A0D, Вы писали:
I>>Ужос. Экстншны в шарпе сделаны как раз не на инкапсуляции и отлично поддерживаются IDE.
BDA>Они сделаны на псевдоинкапсуляции, отложенной инкапсуляции, называйте как хотите. Суть в том, что и при включении метода в класс, и при написании extension'ов, требуется явно указывать принадлежность к классу. Это — суть.
Во-первых, Это язык со статической типизацией. Как ни крути, а тип будет задан явно.
Во-вторых, расширения улучшают и инкапсуляцию и полиморфизм.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>2. Почему внешние функции должны вызываться как внутренние, а не наоборот? I>>Смотри внимательно пример кода, там оба варианта.
EP>Там оба варианта инфиксные, и нет синтаксиса вызова метода как обычной внешней функции — method(obj, x).
Ты хотел вызывать внутреннюю как внешнюю, сейчас ты хочешь другой сорт вызова. Ты определись, чего же тебе надо.
I>>Гораздо полезнее сделать чтото навроде x `f` y
EP>Это мало чем отличается от x.f(y). Да и как например расширить этот синтаксис на мультиметоды, или просто методы с несколькими параметрами?
Здравствуйте, 0BD11A0D, Вы писали:
EP>>Во-первых нужно правильно сортировать варианты. Например функции из того же namespace — более приоритетные. В более общем виде — чем меньше расстояние в дереве namespace'ов — тем выше приоритет. BDA>Еще чуть-чуть, и окажется, что class — САМЫЙ приоритетный namespace. Просто доведите свою мысль до конца.
Да, и что? Из этого никак не следует что IDE должна подсказывать методы только из этого самого приоритетного namespace.
EP>>Во-вторых рулит type-rich programming. Например path вместо string. BDA>Про path я думал, идея неплохая. Если добавить поддержку частей пути как списка и неявное преобразование в строки, я бы одобрил.
boost::filesystem::path.
BDA>Ну хорошо — конструктор нового исключения. Предельно близок по неймсейсам, тип однозначно строковый. Будет вылезать всегда. И?
1. И пусть вылезает. Типичный use-case дополнения предполагает ввод нескольких букв из имени метода.
2. Желательно иметь чуть больше namespace'ов чем один std::*, да.
EP>>>>Что невозможно? Получить список функций для которых данный объект может быть аргументом? Не считая случаи какого-нибудь сильного TMP/duck-typing — то всё возможно. BDA>>>Вот что невозможно: BDA>>>http://rsdn.ru/forum/flame.comp/6063107.1
EP>>Там говорится про "типичный" алгоритм — но если у класса сотни методов то как IDE должна выбрать из них "типичные"? BDA>Все методы, явно помещеные в класс — типичные. Типичными их делает как раз помещение туда.
Типичные для кого? Если у класса сотни методов, то множества "типичных" для разных разработчиков будут слабо пересекаться в общем случае.
BDA>Дура-IDE должна показывать все молча. И, конечно, это авторский замысел, то есть, некая модель программистских представлений о сущностях.
То есть автор что-то захотел положить в класс, а что-то нет, исключительно по его представлениям о "типичности", а не например по соображениям инкапсуляции
Что делать в случае когда нужна та функция, которая оказалась вне класса? Ты разве против того, чтобы введя имя объекта была возможность получить список в котором будут в том числе и эти внешние функции?
BDA>>>Все. А какие еще у него есть преимущества, по-вашему? Сокрытие и защита данных? Так хендлы давно это делают. Безопасность? Смешно. Какие? EP>>Например иерархичность — в некоторых областях это действительно удобно и естественно, правда далеко не во всех. BDA>Ну, это долгая песня — является ли иерархичность непременным атрибутом ООП. Тратить время на нее не хочу, скажу просто, что с моей точки зрения она очень рульная вещь, но вторичная.
В целом я не в восторге от ООП — оно конечно отлично подходит для некоторых областей, но к сожалению на протяжении последних лет двадцати его пихают куда ни попадя.
Тем не менее, главным и единственным преимуществом "дополнение через точку" уж точно не является.
Из такого утверждения практически следует что не учитывая авто-дополнения, код без ООП строго не хуже, а во многих случаях и лучше чем с ООП. Фактически получается что по-твоему ООП это всего лишь уродование кода ради авто-дополнения
EP>>>>А как например выражается алгоритмическая сложность, список возможных исключений, и exception safety guarantee? Не говоря уже о том, что на последовательность вызова методов могут быть наложены некоторые ограничения. EP>>>>IntelliSense Oriented Development возможен только в примитивнейших случаях типа установки свойств формы и т.п. В общем же случае от него польза только в качестве подсказки правильного имени метода/поля. BDA>>>Как например? Так вам надо поискать примеры. Они есть. EP>>Примеры IntelliSense Oriented Development я действительно видел — "нужно добавить элементы. что тут у нас есть? ага — add, его и заюзаем — клац" — и в итоге получаем квадратическую сложность на ровном месте, потому что в контракт не смотрели. Что характерно, я фиксил подобное с помощью документации и "блокнота", даже без возможности скомпилировать. BDA>Я тоже много чего видел. Например, площадь Сан-Марко, как мне тут с утра напомнили. Но я же не пишу обо всем об этом, а пишу только о том, что имеет отношение к вопросам и ответам.
Здесь в общем обсуждается IntelliSense и т.п. — мой пример как раз про это
BDA>Вопрос был — «А как например выражается алгоритмическая сложность, список возможных исключений». Я говорю: есть такие примеры и вы можете их найти самостоятельно. Незачем зацикливаться на C++.
Уже во втором сообщении ты отсылаешь к каким-то примерам без всякой конкретики. "примеры есть, сам ищи"
EP>>Конкретно здесь речь об дополнении имени функции по части её имени, а не по типам аргументов. EP>>"IntelliSense не основанный на инкапсуляции" в чистом виде BDA>Ну конечно, сейчас уже речь пойдет о том, чтобы часть имени указывать.
Ты спрашивал "IntelliSense не основанный на инкапсуляции", я его показал
EP>>А я и описал. Непонятно с чем конкртено ты не согласен. Могу ещё раз повторить: убери ключевое слово this из extension method'ов в C# и специальный синтаксис вызова — как ты думаешь, будет ли технически возможно автодополнение в таком случае, и если нет то почему. BDA>Нет, не будет. Потому, что ни IDE, ни компилятор в вашу голову залезть не может и понять, что это за функция — случайно совместимая по сигнатуре или задизайненная как extension — тоже не может.
Что значит "случайно совместимая по сигнатуре"? Я говорю о том что нужно выводить как раз список всех таких функций.
BDA>Вы там вверху начали предлагать косвенно указывать на близость к телу,
В ISO C++ есть даже явные особенности использования функций "близких к телу" — Argument-Dependent Lookup.
Если IDE будет также учитывать эту близость — то это решение будет в духе самого языка.
BDA>например, поощрять избыточную типизацию
Я за type-rich programming даже не учитывая возможное авто-дополнение, это просто косвенный бонус. Но вводить дополнительные типы только из-за авто-дополнения не предлагаю.
BDA>или рулить неймспейсами.
Вполне естественно.
BDA>Зачем косвенно, когда можно все это делать прямо?
То что ты называешь "прямо":
1. Даёт намного меньше информации.
2. Ухудшает инкапсуляцию.
BDA>Я хотел найти описание необходимости this от создателей языка, но все, что нашел, это вот такую болтологию: BDA>http://stackoverflow.com/questions/3510964/why-is-the-this-keyword-required-to-call-an-extension-method-from-within-the-e BDA>Первый НЕудачный ответ Эрика Липперта на моей памяти. Он просто уходит от ответа. Чем-то же они думали, когда вводили this, а не перебирали совместимые сигнатуры. Вот и надо было написать, зачем и почему было принято такое решение. Ответ, как ни крути, сводится к явной маркировке, но что мешало ответить по существу?
Там вообще-то вопрос про другой this. Не про this в сигнатуре, а про this значение внутри метода расширяемого класса
EP>>3. Алгоритмов очень много, далеко не все есть в стандартной библиотеке, расширять набор алгоритмов рано или поздно всё равно придётся. BDA>3. Я предложил привести пример, чтобы его разобрать,
Например нам потребовалась поразрядная сортировка.
BDA>но вместо примера получил общие рассуждения.
Здравствуйте, Ikemefula, Вы писали:
EP>>>>2. Почему внешние функции должны вызываться как внутренние, а не наоборот? I>>>Смотри внимательно пример кода, там оба варианта. EP>>Там оба варианта инфиксные, и нет синтаксиса вызова метода как обычной внешней функции — method(obj, x). I>Ты хотел вызывать внутреннюю как внешнюю, сейчас ты хочешь другой сорт вызова. Ты определись, чего же тебе надо.
Под вызовом внешней функции подразумевается f(x,y,z).
I>>>Гораздо полезнее сделать чтото навроде x `f` y EP>>Это мало чем отличается от x.f(y). Да и как например расширить этот синтаксис на мультиметоды, или просто методы с несколькими параметрами? I>Никак. Вместо мултиметодов нужен паттерн-матчинг.
Ок, допустим. Но всё равно не понятно:
1. Чем x `f` y полезнее x.f(y)?
2. Как вызывать f(x,y,z) с таким синтаксисом? Через currying?
Здравствуйте, Ikemefula, Вы писали:
I>Во-первых, Это язык со статической типизацией. Как ни крути, а тип будет задан явно.
Речь идет о необходимости добавлять this. Почему бы просто не автодополнять и комипилировать любую статику с первым параметром соответствующего типа, даже если он не помечен this?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Это мало чем отличается от x.f(y). Да и как например расширить этот синтаксис на мультиметоды, или просто методы с несколькими параметрами? I>>Никак. Вместо мултиметодов нужен паттерн-матчинг.
EP>Ок, допустим. Но всё равно не понятно: EP>1. Чем x `f` y полезнее x.f(y)?
Чище. Здесь нет привязки к методу. f может быть чем угодно.
EP>2. Как вызывать f(x,y,z) с таким синтаксисом? Через currying?
Здравствуйте, 0BD11A0D, Вы писали:
I>>Во-первых, Это язык со статической типизацией. Как ни крути, а тип будет задан явно. BDA>Речь идет о необходимости добавлять this.
В языке D не такой необходимости — там можно вызывать f(x,y), как x.f(y).
Насколько D вообще поддерживается IDE — не знаю
Здравствуйте, 0BD11A0D, Вы писали:
I>>Во-первых, Это язык со статической типизацией. Как ни крути, а тип будет задан явно.
BDA>Речь идет о необходимости добавлять this. Почему бы просто не автодополнять и комипилировать любую статику с первым параметром соответствующего типа, даже если он не помечен this?
Ты хочешь сомнительную реализацию сомнительной фичи "что я могу сделать с ЭТИМ".
Как правило, не нужны сразу все возможные методы. Всегда ровно один, всё остальное мусор. Кроме того, гораздо эффективнее решать другую задачу — "как из x попасть в y".
this как штемсель, который говорит о том, что ты выполнил/прошел определенные проверки. Т.е. тебе даётся список того, что спроектировано целенаправленно, а не получилось случайно.
Скажем, для файла будет более менее нормально file.SendTo('deviceId'), если функция отсылает файла на девайс.
Но если эта функция отсылает не файл, а какую то хрень, [не]основываясь на содержимом файла, получится непойми что.
Здравствуйте, 0BD11A0D, Вы писали:
C>>То есть, в классе строки будут методы для: C>>1) Base64-кодирования C>>2) URL-кодирования C>>3) escape'а для shell'а C>>4) escape'а для другого shell'а C>>5) Санитизации строк для SQL injection'а C>>6) Случайной перестановки букв C>>7) Проверки пароля с помощью PBKDF2 C>>8) Приготовления кофе. BDA>Они будут у идиота, чье представление о строках и типичных операциях с ними — идиотское. И заметьте, тут только один человек такое предлагает.
Какой именно из этих пунктов — идиотский? Они все имеют смысл в рамках определённых проектов.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>1. И пусть вылезает. Типичный use-case дополнения предполагает ввод нескольких букв из имени метода.
Так ведь он не один вылезает. Вы посчитайте сами, сколько в бусте всего могло бы повылазить. И сколько нужного не вылазит.
EP>Типичные для кого? Если у класса сотни методов, то множества "типичных" для разных разработчиков будут слабо пересекаться в общем случае.
Для пользователей библиотеки, разумеется.
Откуда вы все берете эти «сотни»? Ни одна реализация строкового класса не содержит сотни методов. Ну, есть удвоение-утроение числа за счет перегрузок, но даже в этом случае о сотнях методов речи не идет. На практике их очень мало и как-то так получается, что пересечение множеств у продуманной библиотеки близко к 100%.
BDA>>Дура-IDE должна показывать все молча. И, конечно, это авторский замысел, то есть, некая модель программистских представлений о сущностях.
EP>То есть автор что-то захотел положить в класс, а что-то нет, исключительно по его представлениям о "типичности", а не например по соображениям инкапсуляции
А что такое «соображения инкапсуляции»? Например, в случае с мутабельной строкой в плюсах сырой буфер доступен всем, и это неизбежно для низкоуровневого языка с прицелом на перфоманс. Какие соображения еще надо принимать во внимание?
EP>Что делать в случае когда нужна та функция, которая оказалась вне класса? Ты разве против того, чтобы введя имя объекта была возможность получить список в котором будут в том числе и эти внешние функции?
Вызывать ее как функцию. Если при этом кажется, что она — типичный алгоритм для этого класса, жаловаться разработчику. В противном случае — радоваться жизни.
Да, я против того, чтобы вылезал неотфильтрованный список, потому, что это не то, что нужно. Когда вы просите секретаршу подготовить список потенциальных клиентов, вам что надо — список тех, кто реально у вас мог бы что-то заказать, или список всех кого попало, у кого какой-нибудь левый признак более-менее совпадает? Или как вам поисковая SEO — не приходилось сталкиваться? Чтобы этого не было, надо налагать нормальный фильтр. У секретарши есть мозг, а у IDE его нет. И, вроде бы, пока еще не дошло до такой острой конкуренции у разработчиков библиотек за клиентский вызов, чтобы SEO устраивать. Может, в будущем, при работе в облаках будет, а сейчас — нет. Значит, лучшее решение — задействовать мозг автора библиотеки и положиться на его суждение, что относится к объекту, а что нет.
EP>В целом я не в восторге от ООП — оно конечно отлично подходит для некоторых областей, но к сожалению на протяжении последних лет двадцати его пихают куда ни попадя. EP>Тем не менее, главным и единственным преимуществом "дополнение через точку" уж точно не является. EP>Из такого утверждения практически следует что не учитывая авто-дополнения, код без ООП строго не хуже, а во многих случаях и лучше чем с ООП. Фактически получается что по-твоему ООП это всего лишь уродование кода ради авто-дополнения
Во-первых, это по-вашему уродование. По-моему, уродование — забустовать без задней мысли.
Во-вторых, что вы приковырялись к автодополнению как таковому? Автодополнение показывает, насколько явно авторы пометили привязки в коде. И да, это (привязки алгоритмов к объектам) главное и единственное преимущество, если разобраться. Вывод выглядит неожиданно? Ну а что делать. Be open-minded. Вы же сами пишете, что суют ООП куда ни попадя. Обещают, что от использования будут миллионы денег, все бабы дадут, а потом прилетит Санта-Клаус и покажет кино. Я реалистично вам говорю — ничего такого не будет, вы просто структурируете код, делаете его понятнее, главным образом за счет привязок алгоритмов к данным. Делаете настолько понятным, что даже IDE может показать вам вменяемый список возможных действий с объектом. Что уж говорить о человеке — тот ТОЖЕ сможет гораздо лучше его найти и осознать. Это не так уж мало, согласитесь.
BDA>>Вопрос был — «А как например выражается алгоритмическая сложность, список возможных исключений». Я говорю: есть такие примеры и вы можете их найти самостоятельно. Незачем зацикливаться на C++. EP>Уже во втором сообщении ты отсылаешь к каким-то примерам без всякой конкретики. "примеры есть, сам ищи"
Да, именно так. Ну хорошо, есть такой широко известный пример, как выражается кодом список возможных исключений:
Мне не нравится, кстати. Но выражается. Непонятно зачем.
EP>Ты спрашивал "IntelliSense не основанный на инкапсуляции", я его показал
Я же вам дал ссылку на полную постановку задачи? Которую вы запросили, хоть и с опозданием? Дал. Какие проблемы? Что-то на то сообщение никто не берется отвечать. Потому, что нечего ответить. Если есть, давайте, не надо ходить вокруг да около.
EP>>>А я и описал. Непонятно с чем конкртено ты не согласен. Могу ещё раз повторить: убери ключевое слово this из extension method'ов в C# и специальный синтаксис вызова — как ты думаешь, будет ли технически возможно автодополнение в таком случае, и если нет то почему. BDA>>Нет, не будет. Потому, что ни IDE, ни компилятор в вашу голову залезть не может и понять, что это за функция — случайно совместимая по сигнатуре или задизайненная как extension — тоже не может.
EP>Что значит "случайно совместимая по сигнатуре"? Я говорю о том что нужно выводить как раз список всех таких функций.
Вам нужно видеть OpenFile, когда у вас на руках строка "Москва,Париж"? Ну так большинству не нужно.
EP>Там вообще-то вопрос про другой this. Не про this в сигнатуре, а про this значение внутри метода расширяемого класса
Хе-хе-хе, вот это скрюапчик. Невнимательно вопрос прочитал.
EP>>>3. Алгоритмов очень много, далеко не все есть в стандартной библиотеке, расширять набор алгоритмов рано или поздно всё равно придётся. BDA>>3. Я предложил привести пример, чтобы его разобрать,
EP>Например нам потребовалась поразрядная сортировка.
Если нам потребовалась (в одном месте) поразрядная сортировка, мне абсолютно пофиг, как вы ее оформите — хоть глобальной функцией. Моделировать проект это не помешает. Если она требуется много раз, это говорит о том, что, возможно, имеется некоторая сущность, которую, может быть, следует оформить как таковую. Если она требуется много где, это превращает алгоритм в стандартный, после чего с ним надо начать обращаться как со стандартным алгоритмом и мимикрировать под стандартную библиотеку. С учетом констрейнтов на тип параметра коллекции.
Здравствуйте, Ikemefula, Вы писали:
BDA>>Речь идет о необходимости добавлять this. Почему бы просто не автодополнять и комипилировать любую статику с первым параметром соответствующего типа, даже если он не помечен this?
I>Ты хочешь сомнительную реализацию сомнительной фичи "что я могу сделать с ЭТИМ". I>Как правило, не нужны сразу все возможные методы. Всегда ровно один, всё остальное мусор. Кроме того, гораздо эффективнее решать другую задачу — "как из x попасть в y".
I>this как штемсель, который говорит о том, что ты выполнил/прошел определенные проверки. Т.е. тебе даётся список того, что спроектировано целенаправленно, а не получилось случайно.
I>Скажем, для файла будет более менее нормально file.SendTo('deviceId'), если функция отсылает файла на девайс. I>Но если эта функция отсылает не файл, а какую то хрень, [не]основываясь на содержимом файла, получится непойми что.
Вы не могли бы это все >> Evgeny.Panasyuk? Потому, что я все это уже несколько раз написал. Главное, как объяснить, что this не только с extension'ами эту роль выполняет, но и с обычными классами. Потому и this.
Здравствуйте, 0BD11A0D, Вы писали:
EP>>Типичные для кого? Если у класса сотни методов, то множества "типичных" для разных разработчиков будут слабо пересекаться в общем случае. BDA>Для пользователей библиотеки, разумеется. BDA>Откуда вы все берете эти «сотни»? Ни одна реализация строкового класса не содержит сотни методов. Ну, есть удвоение-утроение числа за счет перегрузок, но даже в этом случае о сотнях методов речи не идет.
У std::string сотни методов. А если засунуть туда ещё и алгоритмы STL — то будет несколько сотен.
EP>>То есть автор что-то захотел положить в класс, а что-то нет, исключительно по его представлениям о "типичности", а не например по соображениям инкапсуляции BDA>А что такое «соображения инкапсуляции»? Например, в случае с мутабельной строкой в плюсах сырой буфер доступен всем, и это неизбежно для низкоуровневого языка с прицелом на перфоманс. Какие соображения еще надо принимать во внимание?
Внутренние инварианты строки недоступны из вне. Например внутренний указатель должен указывать на валидный буфер, либо быть нулевым, capacity должен быть не меньше size и т.п.
Все методы имеют доступ к этим инвариантам и могут их поломать.
EP>>Что делать в случае когда нужна та функция, которая оказалась вне класса? Ты разве против того, чтобы введя имя объекта была возможность получить список в котором будут в том числе и эти внешние функции? BDA>Вызывать ее как функцию.
И как ты это сделаешь без настолько "важного" IntelliSense?
BDA>Да, я против того, чтобы вылезал неотфильтрованный список, потому, что это не то, что нужно. Когда вы просите секретаршу подготовить список потенциальных клиентов, вам что надо — список тех, кто реально у вас мог бы что-то заказать, или список всех кого попало, у кого какой-нибудь левый признак более-менее совпадает?
Не просто список "всех кого попало", а отсортированный по приоритетам. Это большая разница.
Я хочу чтобы поисковой движок а-ля Google/Yandex выдавал как можно больше результатов, при этом они должны быть отсортированы по приоритетам. Да, часто нужны только первые несколько элементов, но бывает что нужно несколько страниц, а иногда даже все.
И меня совершенно не напрягает то что в тех случаях когда мне нужны только первые результаты, поисковик выдает много страниц.
EP>>В целом я не в восторге от ООП — оно конечно отлично подходит для некоторых областей, но к сожалению на протяжении последних лет двадцати его пихают куда ни попадя. EP>>Тем не менее, главным и единственным преимуществом "дополнение через точку" уж точно не является. EP>>Из такого утверждения практически следует что не учитывая авто-дополнения, код без ООП строго не хуже, а во многих случаях и лучше чем с ООП. Фактически получается что по-твоему ООП это всего лишь уродование кода ради авто-дополнения BDA>Во-первых, это по-вашему уродование. По-моему, уродование — забустовать без задней мысли.
А причём тут вообще "забустовать"? Какие-то конкретные библиотеки ортогональны обсуждению о том нужно ли складывать внутрь класса методы, которые спокойно могли быть реализованы как внешние функции
По твоим (тут вроде все на "ты") же словам получается что ООП стоит использовать исключительно только из-за дополнения, разве не так? То есть код без ООП не хуже, а то и лучше чем код с ним.
BDA>Во-вторых, что вы приковырялись к автодополнению как таковому? Автодополнение показывает, насколько явно авторы пометили привязки в коде. И да, это (привязки алгоритмов к объектам) главное и единственное преимущество, если разобраться. Вывод выглядит неожиданно? Ну а что делать. Be open-minded. Вы же сами пишете, что суют ООП куда ни попадя
Да, суют. Но при этом это не означает у ООП нет никаких преимуществ кроме автодополнения.
BDA>Обещают, что от использования будут миллионы денег, все бабы дадут, а потом прилетит Санта-Клаус и покажет кино. Я реалистично вам говорю — ничего такого не будет, вы просто структурируете код, делаете его понятнее, главным образом за счет привязок алгоритмов к данным. Делаете настолько понятным, что даже IDE может показать вам вменяемый список возможных действий с объектом. Что уж говорить о человеке — тот ТОЖЕ сможет гораздо лучше его найти и осознать. Это не так уж мало, согласитесь.
1. Этого мало чтобы только из-за этого менять свой код. Я без проблем пишу код без всякого Intellisense, при этом да — с поддержкой IDE удобнее, но отнюдь не настолько чтобы это заставило меня писать код как-то по-другому (по сути портить) только ради этой возможности.
2. Подобный список можно выводить и без всякого ООП, ограничившись namespace'ами. Причём это будет более мощное средство — так как можно ввести несколько аргументов и по их типам подобрать подходящие варианты.
BDA>>>Вопрос был — «А как например выражается алгоритмическая сложность, список возможных исключений». Я говорю: есть такие примеры и вы можете их найти самостоятельно. Незачем зацикливаться на C++. EP>>Уже во втором сообщении ты отсылаешь к каким-то примерам без всякой конкретики. "примеры есть, сам ищи" BDA>Да, именно так. Ну хорошо, есть такой широко известный пример, как выражается кодом список возможных исключений: BDA>https://docs.oracle.com/javase/tutorial/essential/exceptions/declaring.html
Так-то зачёт, и в C++ есть подобная возможность. Но, тут нет информации об условиях при которых вылетают эти исключения (хотя я её и забыл запросить).
Тем не менее — алгоритмическая сложность, и прочие описанные мной ограничения никак не указываются.
EP>>Ты спрашивал "IntelliSense не основанный на инкапсуляции", я его показал BDA>Я же вам дал ссылку на полную постановку задачи? Которую вы запросили, хоть и с опозданием? Дал. Какие проблемы? Что-то на то сообщение никто не берется отвечать. Потому, что нечего ответить. Если есть, давайте, не надо ходить вокруг да около.
Я уже здесь частично ответил. Ок, тогда отвечу на то сообщение, точнее на темы которые не обсуждались.
EP>>Что значит "случайно совместимая по сигнатуре"? Я говорю о том что нужно выводить как раз список всех таких функций. BDA>Вам нужно видеть OpenFile, когда у вас на руках строка "Москва,Париж"? Ну так большинству не нужно.
OpenFile где-то в хвосте списка ничем не повредит
EP>>Например нам потребовалась поразрядная сортировка. BDA>Если нам потребовалась (в одном месте) поразрядная сортировка, мне абсолютно пофиг, как вы ее оформите — хоть глобальной функцией. Моделировать проект это не помешает. Если она требуется много раз, это говорит о том, что, возможно, имеется некоторая сущность, которую, может быть, следует оформить как таковую. Если она требуется много где, это превращает алгоритм в стандартный, после чего с ним надо начать обращаться как со стандартным алгоритмом и мимикрировать под стандартную библиотеку. С учетом констрейнтов на тип параметра коллекции.
1. И как произойдёт это "мимикрирование"?
2. Почему вызов редко используемого алгоритма должен синтаксически отличаться от часто используемого?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Вы не могли бы это все >> Evgeny.Panasyuk? Потому, что я все это уже несколько раз написал. Главное, как объяснить, что this не только с extension'ами эту роль выполняет, но и с обычными классами. Потому и this.
Вроде как именно ты предлагаешь вываливать на юзера вообще всё, т.е. решать все проблемы одним интелисенсом.
Здравствуйте, Ikemefula, Вы писали:
BDA>>Вы не могли бы это все >> Evgeny.Panasyuk? Потому, что я все это уже несколько раз написал. Главное, как объяснить, что this не только с extension'ами эту роль выполняет, но и с обычными классами. Потому и this.
I>Вроде как именно ты предлагаешь вываливать на юзера вообще всё, т.е. решать все проблемы одним интелисенсом.
Что я тут делаю... А ведь несколько часов убил. Сейчас меня месяц жаба душить будет.
DreamMaker:
DM>и вообще. если все маразмы из С++ убрать, а все чего не хватает — сделать, получится С#
Чтобы на родных плюсах вместо new/delete была б-гомерзкая сборка мусора?
Работает прога с миллионами экземпляров объектов, никого не трогает и тут как начинается уборка
А виноват кто окажется? Программист вестимо.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
