Здравствуйте, 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Автор: 0BD11A0D
Дата: 29.05.15
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 от создателей языка, но все, что нашел, это вот такую болтологию:
http://stackoverflow.com/questions/3510964/why-is-the-this-keyword-required-to-call-an-extension-method-from-within-the-e
Первый НЕудачный ответ Эрика Липперта на моей памяти. Он просто уходит от ответа. Чем-то же они думали, когда вводили this, а не перебирали совместимые сигнатуры. Вот и надо было написать, зачем и почему было принято такое решение. Ответ, как ни крути, сводится к явной маркировке, но что мешало ответить по существу?
EP>1. Не вижу смысла ограничиваться стандартной библиотекой, да и не думал что в этой ветке такое ограничение.
EP>2. Не вижу смысла уродовать код библиотеки (тем более стандартной) и сваливать внешние по сути алгоритмы во внутрь всех контейнеров, только из-за возможности получить автодополнение через точку.
EP>3. Алгоритмов очень много, далеко не все есть в стандартной библиотеке, расширять набор алгоритмов рано или поздно всё равно придётся.
1. А я вижу и объяснил почему.
2. А я вижу и объяснил почему.
3. Я предложил привести пример, чтобы его разобрать, но вместо примера получил общие рассуждения.
