Приветствую!
Достался легаси говнокод, который модернизирую через BLToolkit. Попалась таблица с именем ABC, в которой есть колонка ABC (оставим на совести автора). После создания соотв. класса C# разругался: низя иметь поле с именем как у класса. Вопрос: ему что, так сложно разрулить кто-где? Есть какие-то ситуации, где их невозможно различить?

PS
Про мэппинг полей знаю, но пока не хочу — могут вылезти проблемы.

Здравствуйте, matumba, Вы писали:

>Вопрос: ему что, так сложно разрулить кто-где?

Такие правила этого языка, напр. и функцию с названием как у класса нельзя создать. И наследовать класс можно только от одного.

Здравствуйте, Аноним, Вы писали:

А>Такие правила этого языка

"Такова жизнь!" — ответ примерно такого уровня. Мой вопрос: ПОЧЕМУ нельзя иметь одинаковые имена.

Здравствуйте, matumba, Вы писали:

M>"Такова жизнь!" — ответ примерно такого уровня. Мой вопрос: ПОЧЕМУ нельзя иметь одинаковые имена.
На самом деле это был правильный ответ.

Курим спецификацию, раз компилятор нам не указ
Each class, struct, or interface declaration creates a new declaration space. Names are introduced into this declaration space through class-member-declarations, struct-member-declarations, interface-member-declarations, or type-parameters. Except for overloaded instance constructor declarations and static constructor declarations, a class or struct cannot contain a member declaration with the same name as the class or struct.
Место для курения

Здравствуйте, matumba, Вы писали:

M>Здравствуйте, Аноним, Вы писали:

А>>Такие правила этого языка

M>"Такова жизнь!" — ответ примерно такого уровня. Мой вопрос: ПОЧЕМУ нельзя иметь одинаковые имена.

Представим, что можно иметь одинаковые имена.

        // Класс с именами функц. свойств. которые выражают своим названием свою сущность. 
        public class MyClass
        {           
            private int myClass;
            public int MyClass { get; set; }
            public MyClass(int i) { myClass = i; }
            public int MyClass() { return 0; }
            public static int MyClass(int i) { return i; }
        }

        class C
        {
            public int MyProperty { get; set; }
        }
        public class B
        {
            public B()
            {
                var c = new MyClass(5) { MyClass = 6; };
                c.MyClass(); // конструктор или функ???

                // кстати свойство - обертка на функ. т.е. имеет все возможности функций
            }
        }

Здравствуйте, matumba, Вы писали:

M>Вопрос: ему что, так сложно разрулить кто-где? Есть какие-то ситуации, где их невозможно различить?

    class A
    {
        public int MyProperty { get; set; }
    }

    class B
    {
        public A B { get; set; }
        public static int MyProperty { get; set; }

        public void Foo()
        {
            Console.WriteLine(B.MyProperty); // ыыы?
        }
    }

Ну и требовали бы в случае такой неоднозначности this.B.MyProperty

Здравствуйте, hi_octane, Вы писали:

_>this.B.MyProperty

    class A
    {
        public int MyProperty { get; set; }
    }

    class B
    {
        public static A B { get; set; }
        public static int MyProperty { get; set; }

        public static void Foo()
        {
            Console.WriteLine(B.MyProperty); // а чо тут писать?
        }
    }

HL> Console.WriteLine(B.MyProperty); // а чо тут писать?

пиши global::Namespace.B.MyProperty или global::Namespace.B.B.MyProperty в зависимости от того к кому хочешь обратиться

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, matumba, Вы писали:

M>>Вопрос: ему что, так сложно разрулить кто-где? Есть какие-то ситуации, где их невозможно различить?
HL>

HL>    class A
HL>    {
HL>        public int MyProperty { get; set; }
HL>    }

HL>    class B
HL>    {
HL>        public A B { get; set; }
HL>        public static int MyProperty { get; set; }

HL>        public void Foo()
HL>        {
HL>            Console.WriteLine(B.MyProperty); // ыыы?
HL>        }
HL>    }

HL>

Давайте начнём с того, что данный пример — специально заточенный под неоднозначность. В моём случае это всего лишь класс А с пропертей А и абсолютно прозрачным использованием "А.А = 1".
Но даже поломав моск над вашим примером, не видно в чём проблема: у цэшарпа полно "хинтов", разруливающих неоднозначности (см. этюды nikov). В данном (абс. искусственном) случае можно ввести приоритет локальных филдов над статическими или (как уже показали ниже) обращаться через global. Вопрос не в том, какие конкретно случаи имеют неоднозначность, а в том, что их МОЖНО РАЗРУЛИТЬ.

Здравствуйте, matumba, Вы писали:

M>После создания соотв. класса C# разругался: низя иметь поле с именем как у класса. Вопрос: ему что, так сложно разрулить кто-где? Есть какие-то ситуации, где их невозможно различить?

Простой ответ: потомучта. Сложный:

I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money. Features are not cheap, and we try very hard to make sure that we are only shipping those features which give the best possible benefits to our users given our constrained time, effort and money budgets.

Если остаются сомнения — очень рекомендую прочитать вот этот пост. Своими словами: любое на первый взгляд элементарное улучшение на практике может только ухудшить язык. Как правило — в самых поганых местах, когда контекст неочевиден даже для компилятора, что уж говорить о пользователе

Совсем коротко: C# — это мейнстримный язык, за гик-фичами — велкам в f#/немерл и ко.

Здравствуйте, matumba, Вы писали:

M>Вопрос не в том, какие конкретно случаи имеют неоднозначность, а в том, что их МОЖНО РАЗРУЛИТЬ.
Можно. Вопрос в том, нафига.

Здравствуйте, Sinix, Вы цитировали:

S>I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature.

Ну это классический, тупой, самоочевидный ответ любого буржуя. Если же посмотреть на реальные причины, как правило они вытекают из жадности в тысячу последствий: пожалели времени/денег на поиск хороших разрабов => наняли нечто с регалиями и привычной буржуйской привычкой врать с улыбкой => в меру посредственных способностей (руководства / разрабов) выкатили решение по набросанным дома спекам. Проверять — долго и дорого, рынок ждёт. => сделали как могли, не особо заботясь о будущем => пришли первые отзывы с запросами, о которых можно было подумать, если бы не торопились наговнокодить => сделали умное лицо и начали "вешать" боссу про "непредсказуемых прогеров" (особенно вот эти долбаные головастики из Раши!) => Босс: да мы вообще не виноваты! => Пресс-секретарь: "The answer is always the same: because no one ever designed...." (no one used even 1% of brains to think twice about proper architecture, extensibility and programming at all) Как результат — фичи скорее "неудобны для просовывания меж костылей и вермишели", чем "nobody ever designed...etc". Учитывая Жабо-родословную, начинающие горе-архитекторы должны были 10 раз заложиться в каждую архитектурную деталь на предмет расширения, т.к. Жаба — это самое минимальное, что можно реализовать для сносного программинга.
Придумывать причины — много ума не надо, искать решения — вот задача этих мягких архитекторов. Почему-то Трупостраус не ныл на убогое наследие Си — просто взял и в 50 строк прикрутил множественное наследование(!). А всякие Липперты готовы мегабайтами флудить "почему в нашу Жабо.НЕТ нельзя всунуть очередную фичу".
К слову, самое тупое, чем можно мерять "фичи" — это вот это самое "best possible benefits to our users". Откуда им знать, насколько фича может "выстрелить" и вообще быть полезной? Одно дело — писать кишки компилера, другое — использовать сам компилер для повседневных задач. "Юзер всегда прав" — вот с чего надо начинать работу.

Здравствуйте, matumba, Вы писали:

M>Здравствуйте, Sinix, Вы цитировали:

M>Ну это классический, тупой, самоочевидный ответ любого буржуя. Если же посмотреть на реальные причины, как правило они вытекают из жадности в тысячу последствий: пожалели времени/денег на поиск хороших разрабов
Не, так конструктивного диалога не выйдет Что бы я не написал и какие бы ссылки не привёл в ответ всё равно будет: "не разбирался и не хочу, но осуждаю". Ну и нафига мне с этим спорить?

Если интересны объективные причины, а не похоливарить — всё есть по ссылке. Специально для вас:

First off, I reject the premise that the feature is "bad" for C#. The feature might well be good for C#, just not good enough compared to its costs (and to the opportunity cost of doing that feature instead of a more valuable feature.) The feature might become good enough for C# if its costs are lowered, or if the compelling benefit to customers becomes higher.

(оттуда же)

И плиз, если вам действительно обсудить а не побросаться какашками, давайте без поз д'Артаньяна, ок?

Здравствуйте, Sinix, Вы писали:

S>И плиз, если вам действительно обсудить а не побросаться какашками, давайте без поз д'Артаньяна, ок?

Это ваше личное, возможно искажённое, восприятие мира. Забавно, но вот это:

> just not good enough compared to its costs

...практически перефразирование моих слов:

> Как результат — фичи скорее "неудобны для просовывания меж костылей и вермишели"

Если вы считаете что-то в моих словах неконструктивным — цитируйте, опровергайте, пока я вижу моя картина маслом — 1:1 того, что у них происходит. Если бы я действительно просил что-то большое — оно бы и выглядело большим, а совпадение имён — так себе, ежедневная мишура, которой даже обфускаторы пользуются!
Учитывая, что проект "Жаба в мелкомягкой интерпретации" существовал задолго до .NET, я с 99% уверенностью могу сказать, что те жабо-наработки (на знаниях и людях тех лет) были просто допилены до "солидной платформы". Поэтому все ограничения, которые мы имеем сегодня, это не "nobody designed, implemented, etc", а тупо "в ту вермишель стало очень сложно засовывать фичи".
Я тоже как-то баловался со всякими языками, так у меня получилось аж сделать идентификаторы, начинающиеся с цифры! (без пересечения с обычными цифрами) Невелика заслуга, но зато прекрасно говорит о том, каким местом думают, когда что-то проектируют.

Здравствуйте, matumba, Вы писали:


S>>И плиз, если вам действительно обсудить а не побросаться какашками, давайте без поз д'Артаньяна, ок?
M>Это ваше личное, возможно искажённое, восприятие мира. Забавно, но вот это:
Вполне возможно

>> just not good enough compared to its costs
M>...практически перефразирование моих слов:
>> Как результат — фичи скорее "неудобны для просовывания меж костылей и вермишели"

Вы зря опустили то, что в скобках.

Смотрите сами: предположим, в 5м шарпе выкатят вашу фичу.

Плюсы: ???

Минусы:
— На проектирование, документирование, тестирование и реализацию придётся потратить часть ресурсов, отведённых на текущую итерацию разработки.
Как я понял, у вас этот пункт идёт как "просовывание меж костылей", типа написание любой фичи — вешь бесплатная, все затраты — на исправление ранее написанного кривого кода
На самом деле это не так даже если не рассматривать стоимость инструментальной обвязки (тесты, ide, пользовательская документация). Дотнет не ограничивается одним шарпом, поэтому, изменяя компилятор шарпа неплохо бы предусмотреть грабли, которые мы расставляем пользователям других языков. Иначе МС как раз и были бы теми самыми безответственными халтурщиками

Совпадение имён порождает конфликты.

class X
{
  Func<int> X;

  object ABC() { return X; }
}

return X — это неудачная попытка вернуть имя типа? Вызвать делегат (забыли скобки)? Конструктор (забыли скобки и new)? Или всё-таки имя поля? Как быть с пользователями других языков?

CLS Rule 5: All names introduced in a CLS-compliant scope shall be distinct independent of
kind, except where the names are identical and resolved via overloading. That is, while the CTS
allows a single type to use the same name for a method and a field, the CLS does not.

(c) Common Language Infrastructure, Partition I, I.8.5.2 Assemblies and scoping

Согласен, правило притянуто за уши — имя типа не относится к внутреннему scope (хотя оно вполне может там использоваться), да и .ctor с именем поля не пересекаются. Может быть где-то оно там оговорено детально, но мне пока лень искать.

Короче, на практике даже оценка стоимости реализации маленькой локальной фичи — штука неочевидная


Ок, мы уже потратили ресурсы на релизацию вашей фичи. Смотрим, что мы ещё потеряли:


— Мы не смогли реализовать какие-то действительно полезные фишки, например, автоматическую реализацию свойств или var *(ну, они всяко полезнее, чем совпадение имени поля с классом).

— Мы усложнили язык. Вместо простого правила, которое действует ещё с 1го шарпа:

The following rules apply to class-member-declarations:
Instance constructors, destructors and static constructors must have the same name as the immediately enclosing class. All other members must have names that differ from the name of the immediately enclosing class.

Придётся явно разделять field declaration statement (идентификатор класса может использоваться в качестве имени поля) и other member declaration statement (не может)

— Мы поломали обратную совместимость кода и вынудили все сторонние тулзы (FxCop/решарпер/StyleCop/msil/) переписыввать реализацию парсеров/анализаторов il. То же самое — для инфраструктуры моно и силверлайта.

— Библиотеки с биндингои/обжектмапперы/MVC-фреймворки тоже не останутся в стороне — им тоже неплохо бы пересмотреть код

Разница между вашим подходом и подходом МС — именно в оценке сопутствующих затрат и рисков. И закономерном консерватизме — лучше заставить 5 человек переименовать поле, чем всех пользователей — перепроверять уже выпущенный код.


Ну и нафига

M>Если бы я действительно просил что-то большое — оно бы и выглядело большим, а совпадение имён — так себе, ежедневная мишура, которой даже обфускаторы пользуются!
Зачем сравнивать несравнимое? Обфускаторы меняют код с целью защиты от использования сторонними разработчиками. Да и то — не всегда удачно. Компилятор — генерит код, который без перекомпиляции может быть использован на разных платформах/языках.

M>Учитывая, что проект "Жаба в мелкомягкой интерпретации" существовал задолго до .NET, я с 99% уверенностью могу сказать, что те жабо-наработки (на знаниях и людях тех лет) были просто допилены до "солидной платформы".
Ну, с той же уверенностью можно говорить что MS Java была просто отладочной площадкой для обкатки сборщика мусора и проверки практической применимости managed-языков. Под капотом у них общего очень мало.

M>Поэтому все ограничения, которые мы имеем сегодня, это не "nobody designed, implemented, etc"
Стоимость введения полей с именем == имени класса я привёл выше. Даже на начальных этапах, до выпуска прототипа, усложнение грамматики ради такой фичи — это очень неразумно.

M>Я тоже как-то баловался со всякими языками, так у меня получилось аж сделать идентификаторы, начинающиеся с цифры! (без пересечения с обычными цифрами) Невелика заслуга, но зато прекрасно говорит о том, каким местом думают, когда что-то проектируют.
О как! А пример можно?