У меня есть метод и класс с тем же именем. В одном случае компилятор понимает, что я использую имя класса, но не в другом случае:
using System;
using DTO;
namespace DTO
{
public class Foo
{
public string Bar { get; set; }
}
}
namespace Tests
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
private void Foo()
{
var foo = new Foo // Ok
{
Bar = nameof(Foo.Bar) // Not ok
};
}
}
}
Ошибка:
CS0119 'Program.Foo()' is a method, which is not valid in the given context
Я получаю ту же ошибку со статическим свойством:
public class Foo
{
public static string Bar = "Hello";
}
// ...
private void Foo()
{
var bar = Foo.Bar; // Error
}
Если компилятор понимает в контексте, что Foo
в new Foo
является классом, почему он не может понять, что Foo
в nameof(Foo.Bar)
также является классом? Это обозначение не имеет смысла, если Foo
- это метод.
@ RenéVogt Готово.
Это предположение, поэтому не добавляется в качестве ответа, но Foo.Bar
предложит статическое свойство, которым не является Bar
и, следовательно, не то, что компилятор считает допустимым. foo.Bar
(F в нижнем регистре) является экземпляром Foo
, поэтому Bar
является допустимым видимым свойством.
@Diado Я пробовал использовать статическое свойство, оно тоже вызывает ошибку. Я могу добавить эту информацию к вопросу.
@Boiethios Вы пробовали nameof(foo.Bar)
просто из интереса?
@Diado Это работает (если я инициализирую свойство после создания объекта, конечно)
В первом случае компилятор знает, что вы имеете в виду класс из-за ключевого слова new
. То, что следует за new
имеет, должно быть именем типа.
Во втором случае такого ограничения нет: Foo
может быть любой переменной, членом, полем или типом. (Обратите внимание, что если это вообще должно работать, Bar
должен быть свойством static
класса Foo
).
Но поскольку метод Foo
находится в ближайший объем, компилятор думает, что вы имеете в виду эту группу методов, в которой нет члена с именем Bar
.
У вас есть пример, где можно использовать свойство метода?
Теперь, конечно, разработчики компилятора могли бы написать для этого сложную эвристику, сказав, что «Хорошо, это может быть не (метод) .Bar, так как это выглядит странно, и мы можем найти, что существует тип с именем Foo. , поэтому мы будем использовать вместо этого то, что заставляет код компилироваться », первая и основная причина, по которой они этого не сделали, заключается в том, что они этого не сделали.
@Boiethios нет, это то, что говорится в сообщении об ошибке: вы не можете получить доступ к «членам» группы методов, это не имеет смысла ... не смешивайте это с членами MethodInfo
, полученными через отражение или делегат.
@ LasseVågsætherKarlsen Хм, в этом есть смысл
@ LasseVågsætherKarlsen Я полагаю, что причины, по которым вы этого не сделали: 1) как разработчик вы можете быть очень удивлены, что в итоге используется вместо того, что вы ожидали, 2) может быть очень дорого с очень небольшой выгодой
Какое точное сообщение об ошибке?