Здравствуйте, VladD2, Вы писали:
VD>Собственно, подумалось, что идея открытия пространств имен порочна сама по себе. Намного проще и удобнее исходить из предположения, что все имена доступны глобально, и воздействовать на их видимость только в случае конфликта имен в конкретном файле.
То есть в BCL добавляется новый класс, и у непредсказуемого количества программистов перестает компилироваться код, потому что у них уже есть класс с таким же именем, в котором есть метод с такой же сигнатурой.
Это удобно.
Здравствуйте, HrorH, Вы писали:
HH>То есть в BCL добавляется новый класс, и у непредсказуемого количества программистов перестает компилироваться код, потому что у них уже есть класс с таким же именем, в котором есть метод с такой же сигнатурой. HH>Это удобно.
Есть куча гипотетических проблем не встречающихся на практике. Эта одна из них.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ZevS, Вы писали:
ZS>Представим такую ситуацию. В проекте используются две библиотеки, в которых есть два класса с одинаковым именем. Мы используем методы с разной сигнатурой, и вывод типов может определить класс какой библиотеки используется каждый раз. Теоретически, при одновременном обновлении сразу обеих этих библиотек может получиться так, что сигнатуры поменяются и вызываться будут методы не тех классов что нужно. И никаких ошибок компилятора. Случай конечно крайне гипотетический, но все же.
Это очень теоретически. Сейчас эта теоретическая возможность тоже присутствует. Но мир живет и земля не останавливается.
Вообще, если мы имеем одинаковый по названию метод, в одинаковом классе и с одинаковым названием и типами параметров, то это должны быть аналогичные методы. Или что-то не так в этом мире.
Конфликты конечно возможны. И они будут встречаться. Но их разгуливание куда менее затратная задача нежели каждодневная борьба с искусственно созданной проблемой.
Возможно, нужно придумать что-то что предотвращало бы случайные подмены. Я же не предлагаю готовое решение. Я просто озвучил свои мысли.
При использовании Решарпера человек уже не думает о том, что он импортирует. Он просто комплитит и юсинги меняются автоматически. Никаких проблем на практике не возникает. Так какую проблему тогда решают эти юсинги?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Есть куча гипотетических проблем не встречающихся на практике. Эта одна из них.
Так эта проблема не встречается сейчас именно благодаря using.
Простой пример: у скольких программистов до выхода Net 4.0 в коде мог быть класс Task с методом public void Start() ?
Это сотни проектов.
Работающий код становится неработающим из-за появления другого кода, не имеющего к нему никакого отношения.
Здравствуйте, VladD2, Вы писали:
VD>Конфликты конечно возможны. И они будут встречаться. Но их разгуливание куда менее затратная задача нежели каждодневная борьба с искусственно созданной проблемой.
Это как сказать. Я тут пару дней назад изрядно потрахался, чтобы корректно проапгрейдить в проекте сайта Web-стек. Как раз из-за конфликтов. И это на довольно неболшьшом проекте и при наличии юсингов. А если бы все было открыто?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, HrorH, Вы писали:
HH>Так эта проблема не встречается сейчас именно благодаря using. HH>Простой пример: у скольких программистов до выхода Net 4.0 в коде мог быть класс Task с методом public void Start() ?
С чего бы год должен перестать работать?
Ты же не создашь в точности такой же класс с точно такими же конструкторами и методами? А раз так, то умный компилятор сможет выбрать нужную версию.
В Шарпе неоднозначности частенько возникают только потому, что там нет вывода типов или он слабый. Но можно создать такой вывод типов который будет отличать любые неодинаковые типы/функции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это как сказать. Я тут пару дней назад изрядно потрахался, чтобы корректно проапгрейдить в проекте сайта Web-стек. Как раз из-за конфликтов. И это на довольно неболшьшом проекте и при наличии юсингов. А если бы все было открыто?
Ну, то есть юсинги тебе никак не помогли в этом? Тогда в чем их ценность?
Может разумнее придумать удобную систему разруливания конфликтов вместо них?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Есть куча гипотетических проблем не встречающихся на практике. Эта одна из них.
На практике встречаются ситуации, когда компания РогаИКопыта пилит некую библиотеку.
А через пять лет кусок этой библиотеки успешно выкупается другим вендором и внезапно переезжает в другой неймспейс.
Побочным эффектом является двойной комплект классов в депендах твоего проекта
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>На практике встречаются ситуации, когда компания РогаИКопыта пилит некую библиотеку. S>А через пять лет кусок этой библиотеки успешно выкупается другим вендором и внезапно переезжает в другой неймспейс. S>Побочным эффектом является двойной комплект классов в депендах твоего проекта
Дублирование одного и того же — это реальная проблема. Особенно когда это две версии одного и того же. Для разруливания таких ситуаций нужно придумывать какие-то решения.
Собственно я пока законченного решения не имею. Тему создал как раз для обсуждения с целью уточнения решения. Предлагаю подумать над решением возникающих проблем вместе.
Проблема дублирующихся классов досаждает и в языках с юсингами. Так что ей все равно стоит найти достойное решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, то есть юсинги тебе никак не помогли в этом?
Они не помогли, потому что лятский кодогенератор вьюх втыкает свои юсинги неявно, вот куча вьюх и осыпалась, потому что типы из МСных свежих либ конфликтовали с типами из проекта сайта. Т.е., фактически, получилась твоя глобальная видимость.
VD>Может разумнее придумать удобную систему разруливания конфликтов вместо них?
А что ты там разрулишь, если, к примеру, у МС появился класс Gravatar с методом GetUrl, а IT в свое время тоже написал класс Gravatar с методом GetUrl? Там даже по типам и именам параметров получилось пересечение. Единственное что тут можно сделать — вывалить ошибку о конфликте.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinclair, Вы писали:
S>На практике встречаются ситуации, когда компания РогаИКопыта пилит некую библиотеку. S>А через пять лет кусок этой библиотеки успешно выкупается другим вендором и внезапно переезжает в другой неймспейс.
Ну так мы все знаем чем это заканчивается — у публичных типов появляются префиксы — QWidget, TRxPanel и т.п.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Они не помогли, потому что лятский кодогенератор вьюх втыкает свои юсинги неявно, вот куча вьюх и осыпалась, потому что типы из МСных свежих либ конфликтовали с типами из проекта сайта.
Ну, так и РеШарпер втыкает юсинги в автомате, так что хрен проследишь на что отображаются конкретные типы.
AVK>Т.е., фактически, получилась твоя глобальная видимость.
Фактически получается, что решение с юсингами — плохое решение. Я же предлагаю сразу заниматься неоднозначностями и только ими. Причем сделать так, чтобы неоднозначность возникала только при полном совпадении.
Я предлагаю сделать более умный компилятор и забить не рудеминтарные действия.
VD>>Может разумнее придумать удобную систему разруливания конфликтов вместо них?
AVK>А что ты там разрулишь, если, к примеру, у МС появился класс Gravatar с методом GetUrl, а IT в свое время тоже написал класс Gravatar с методом GetUrl?
Если у них разная сигнатура, то это вообще не проблема. Если одинаковая, то это конфликт который нужно разрулить. Разруливать можно для всего проекта и для отдельного файла.
AVK>Там даже по типам и именам параметров получилось пересечение. Единственное что тут можно сделать — вывалить ошибку о конфликте.
Ага. Таких мест будет мало. Разрулить их и будет нам счастье.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Они не помогли, потому что лятский кодогенератор вьюх втыкает свои юсинги неявно, вот куча вьюх и осыпалась, потому что типы из МСных свежих либ конфликтовали с типами из проекта сайта. VD>Ну, так и РеШарпер втыкает юсинги в автомате
Он их не втыкает там где не нужно. А вот разор втыкает их везде, нужно это или нет. Т.е. эмулирует ровно то поведение, которое ты предлагаешь — все МСные либы доступны во всех вьюхах без юсингов.
AVK>>Т.е., фактически, получилась твоя глобальная видимость. VD>Фактически получается, что решение с юсингами — плохое решение.
Без них — еще хуже.
VD> Я же предлагаю сразу заниматься неоднозначностями и только ими. Причем сделать так, чтобы неоднозначность возникала только при полном совпадении.
Я тебе реальный и свежий пример привел, а ты уж думай сам.
AVK>>А что ты там разрулишь, если, к примеру, у МС появился класс Gravatar с методом GetUrl, а IT в свое время тоже написал класс Gravatar с методом GetUrl? VD>Если у них разная сигнатура, то это вообще не проблема.
Разная, но, с учетом дефолтных параметров, вызовы попадали под обе.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Он их не втыкает там где не нужно.
Он их втыкает автоматом. Человек вообще не думает о том какие пространства имен он использует. Это важный факт. Он заставляет усомниться в самой концепции юстингов.
AVK>А вот разор втыкает их везде, нужно это или нет. Т.е. эмулирует ровно то поведение, которое ты предлагаешь — все МСные либы доступны во всех вьюхах без юсингов.
Если бы вывод типов в шарпе был по умнее, и если бы были возможности разрешать неоднозначности, то это бы не создавало проблем.
VD>>Фактически получается, что решение с юсингами — плохое решение. AVK>Без них — еще хуже.
Ты застрял в мире шарпа. Смотри на мир шире. Они не нужны. Они являются способом решения кофликтов имен работающего от принципа "разрешить", а можно жить по принципу "запретить" или даже "разрулить там где есть проблемы".
VD>> Я же предлагаю сразу заниматься неоднозначностями и только ими. Причем сделать так, чтобы неоднозначность возникала только при полном совпадении.
AVK>Я тебе реальный и свежий пример привел, а ты уж думай сам.
Ты меня не слушаешь. В Шарпе вывод типов очень плохой. Он тупо не может отличить двух типов. Если бы это было не так, то неоднозначности были бы большой редкостью и было бы в сто раз проще их разруливать.
Что-то я устал повторяться. Ты прежде чем в следующий раз отвечать постарайся понять то, о чем я говорю.
AVK>>>А что ты там разрулишь, если, к примеру, у МС появился класс Gravatar с методом GetUrl, а IT в свое время тоже написал класс Gravatar с методом GetUrl? VD>>Если у них разная сигнатура, то это вообще не проблема.
AVK>Разная, но, с учетом дефолтных параметров, вызовы попадали под обе.
В совсем неоднозначных случаях нужно разрешать неоднозначности врунчную. Их не будет много. Это куда проще чем открывать разрешать их с помощью открытия пространств имен в каждом фале. По сути ты решаешь проблему во всех файлах проекта вместо того чтобы решить ее один раз.
В таких случаях можно выбрать предпочтение одного из классов/функций во всем проекте или его части или написать специальную функцию которая будет делать выбор сама (аналогично юсингу с алиасом для типа).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Он их не втыкает там где не нужно. VD>Он их втыкает автоматом. Человек вообще не думает о том какие пространства имен он использует.
Человек может и не думает, а я вот думаю.
VD>Если бы вывод типов в шарпе был по умнее, и если бы были возможности разрешать неоднозначности, то это бы не создавало проблем.
Я привел реальный случай.
VD>>>Фактически получается, что решение с юсингами — плохое решение. AVK>>Без них — еще хуже. VD>Ты застрял в мире шарпа.
Ясно. Тебе, как обычно, не чужое мнение нужно, а вещать Единственно Правильную Точку Зрения на вопрос.
AVK>>Я тебе реальный и свежий пример привел, а ты уж думай сам. VD>Ты меня не слушаешь. В Шарпе вывод типов очень плохой.
Это ты меня не слушаешь. Никакой вывод типов в данном случае не спас бы. Прочти мои предыдущие ответы еще раз.
AVK>>Разная, но, с учетом дефолтных параметров, вызовы попадали под обе. VD>В совсем неоднозначных случаях нужно разрешать неоднозначности врунчную. Их не будет много.
То есть вера. То есть обсуждать нечего.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Человек может и не думает, а я вот думаю.
Предлагаешь обсудить тебя?
AVK>Ясно. Тебе, как обычно, не чужое мнение нужно, а вещать Единственно Правильную Точку Зрения на вопрос.
Не обвинять меня в твоих недостатках. Я предлагал обсудить иной подход. Ты полез в бутылку выставляя свое единственно правильное мнение основанное на твоем опыте. Я тебе объяснил, что ты исходишь из не верных предпосылок. Ты же лезешь спорить и ругаться. Мне это не интересно. Мне нужен конструктив.
AVK>Это ты меня не слушаешь. Никакой вывод типов в данном случае не спас бы. Прочти мои предыдущие ответы еще раз.
Я тебя слушаю, но вижу что ты тупо повторяешь неверные доводы.
Мои доводы очень просто. В 99% случаев вывод типов отличит имена на базе информации о типах. В оставшемся одном проценте придется разрулить неоднозначности. Причем это можно будет сделать как на уровне проекта, так и на локальном уровне.
Если твой "данный случай" подпадает под этот самый 1%, то не стоит на этом основании делать далеко идущие выводы. Нужно подумать о картине в целом.
VD>>В совсем неоднозначных случаях нужно разрешать неоднозначности врунчную. Их не будет много.
AVK>То есть вера. То есть обсуждать нечего.
Вера во что?
Мне кажется тебе хочется устроить срач на ровном месте. Если это так, то лучше просто не влезай в спор. А влезаешь, старайся понять чужие аргументы, и обосновать свое мнение.
И так, если ты готов к конструктиву, чем тебе не понравилось мое утверждение выше?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Человек может и не думает, а я вот думаю. VD>Предлагаешь обсудить тебя?
Ты уже начал.
AVK>>Ясно. Тебе, как обычно, не чужое мнение нужно, а вещать Единственно Правильную Точку Зрения на вопрос. VD>Не обвинять меня в твоих недостатках. Я предлагал обсудить иной подход.
Оно и видно: "Ты застрял в мире шарпа. Смотри на мир шире.". Отличное обсуждение, чо.
VD> Ты полез в бутылку выставляя свое единственно правильное мнение основанное на твоем опыте
Я, прощу обратить внимание, вообще своего мнения не высказывал. Потому что я — не знаю. Статистики по конфликтам у меня нет, в личной практике встречался неоднократно с такими конфликтами, которые никакой вывод типов не разрулит. Могу тебе только очевидные вещи сказать — чем больше проект, старее, и больше у него референсов, тем вероятность конфликтов выше. И бывают крайне причудливые ситуации. Например две версии одной и той же библиотеки, подключенные одновременно. Или не подключенные, а просто воткнутые двумя папочками в проект, в одной из которых переименован неймспейс. Разруливать такое без юсингов — это реально застрелиться. И никакой вывод типов, очевидно, тебя при такой ситуации не спасет. Там даже юсинги не всегда спасают, приходится namespace alias использовать.
А вот ты почему то уверен, что проблем 100% не возникнет. Хотелось бы понять на основании каких данных у тебя эта уверенность, а не выслушивать эпитеты, которыми ты щедро оделяешь собеседников на ровном месте.
AVK>>Это ты меня не слушаешь. Никакой вывод типов в данном случае не спас бы. Прочти мои предыдущие ответы еще раз. VD>Я тебя слушаю, но вижу что ты тупо повторяешь неверные доводы.
Я никаких доводов не повторяю. Я привел тебе факт.
VD>Мои доводы очень просто. В 99% случаев вывод типов отличит имена на базе информации о типах.
Докажи.
VD>Если твой "данный случай" подпадает под этот самый 1%, то не стоит на этом основании делать далеко идущие выводы.
Я их и не делаю. Ты, похоже, их сделал за меня.
VD> Нужно подумать о картине в целом.
Нужно прежде всего не отметать неудобные факты, если они не укладываются в твою картину в целом.
AVK>>То есть вера. То есть обсуждать нечего. VD>Вера во что?
В то что таких проблем будет 1%. Для универсального языка, кстати, и 1% это весьма серьезно.
VD>Мне кажется тебе хочется устроить срач на ровном месте.
Срач устраивает тот, кто начинает оскорблять на ровном месте. Зуб даю.
VD>И так, если ты готов к конструктиву, чем тебе не понравилось мое утверждение выше?
Тем что оно предлагает опираться на веру в твое утверждение о 99%.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, VladD2, Вы писали:
VD>При использовании Решарпера человек уже не думает о том, что он импортирует. Он просто комплитит и юсинги меняются автоматически. Никаких проблем на практике не возникает. Так какую проблему тогда решают эти юсинги?
Одна зависимость транзитивно притащила бекпорт в 1.4 java.util.concurrent. Так эта гадость через автоимпорты расползлась по куче классов прежде чем заметили.
Здравствуйте, VladD2, Вы писали:
VD>Собственно, подумалось, что идея открытия пространств имен порочна сама по себе. Намного проще и удобнее исходить из предположения, что все имена доступны глобально, и воздействовать на их видимость только в случае конфликта имен в конкретном файле.
+1!
Одноимённых классов намного меньше, чем гемороя с подключением уникальных, так что идея "автоюзинга" абсолютно здравая. Раз в сто лет использую синоним для неоднозначных типов — он всё решает.
Когда только изучаешь язык, вроде бы using кажется разумным. Как только начинаешь писать тонны кода, становится непонятно, почему ты тратишь время на вещи, которые сам компьютер мог бы спокойно разрулить. Вывод типов сделали же! Хотя о нём во времена фортрана даже не мечтали.
