Last active
January 1, 2016 01:28
-
-
Save controlflow/8072635 to your computer and use it in GitHub Desktop.
Primary ctors
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
class ReverseForLookupItem : ForLookupItemBase | |
{ | |
public ReverseForLookupItem([NotNull] PrefixExpressionContext context, | |
[NotNull] LiveTemplatesManager templatesManager, | |
[CanBeNull] string lengthPropertyName) | |
: base("forR", context, templatesManager, lengthPropertyName) { } | |
protected override IForStatement CreateStatement(CSharpElementFactory factory, ICSharpExpression expression) | |
{ | |
... | |
} | |
} | |
// vs. | |
class ReverseForLookupItem([NotNull] PrefixExpressionContext context, | |
[NotNull] LiveTemplatesManager templatesManager, | |
[CanBeNull] string lengthPropertyName) | |
: ForLookupItemBase("forR", context, templatesManager, lengthPropertyName) | |
{ | |
protected override IForStatement CreateStatement(CSharpElementFactory factory, ICSharpExpression expression) | |
{ | |
... | |
} | |
} |
Я не знаю точно, но скорее всего список полей будет определяться как в F# - если параметр класса использован только в вызове базового класса или инициализаторе поля/свойства (если такие будут в C# 6.0), то поле для него создаваться не будет.
class Point(int x, int y, int z) : PointBase(x) { // поля для x создано не будет
public readonly int FieldY = y + 1; // поля для y тоже не будет создано
// чтобы параметры классов были более полезными, логично ожидать что
// в C# 6.0 появятся инициализаторы для автосвойств, аналогичные инициализаторам полей:
public string MutableAutoPropertyZ { get; set; } = z.ToString(); // поля для z тоже не должно быть
// про инициализаторы автосвойст не было информации,
// но то что показали на NDC London об этом свидетельствует:
public string ReadOnlyAutoPropertyZ { get; } = z; // поля для z по-прежнему не будет
// это автосвойство без одного акцессора - без сеттера.
// я сомневаюсь, что им можно будет присваивать в конструкторах
// (как-то странно выглядело бы, сеттера нет, а присваивать можно),
// но при этом их можно инициализировать как поле (нету никаких причин
// не расширить эту фичу на обычные автосвойства). Будет полезно для коллекций:
public List<string> Tags { get; } = new List<string>();
}
// и да, тут два readonly поля (которые явно написаны):
class Point(int x, int y) {
public readonly int X = x;
public readonly int Y = y;
}
// тут тоже два поля (readonly backing-поле автосвойства):
class Point(int x, int y) {
public int X { get; } = x;
public int Y { get; } = y;
}
// тут два backing-поля автосвойства (мутабельные):
class Point(int x, int y) {
public int X { get; set; } = x;
public int Y { get; set; } = y;
}
// тут два поля, получившиеся из параметров класса (скорее всего мутабельные):
class Point(int x, int y) {
public int X { get { return x; } }
public int Y { get { return y; } }
}
// абсолютно то же самое, только короче (показывали на NDC):
class Point(int x, int y) {
public int X => x;
public int Y => y;
}
// скорее всего можно будет так (два поля из параметров классов):
class Point(int x, int y) {
public int X {
get { return x; }
set { x = value; }
}
public int Y {
get { return y; }
set { y = value; }
}
}
Кажется, слишком наворочено. Поживём-увидим :о)
Так не работает
class Point(int x, int y) {
public int X { get { return x; } }
public int Y { get { return y; } }
}
(7,31): error CS9007: Parameters of a primary constructor can only be accessed in instance variable initializers and arguments to the base constructor.
(8,31): error CS9007: Parameters of a primary constructor can only be accessed in instance variable initializers and arguments to the base constructor.
Последние 3 примера не работают
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Хм, если параметры праймари-конструктора автоматом делаются полями, что смысл в этом вот:
хотя очень логично, конечно же.
А если всё и взаправду так, как ты говоришь, то тем более выбирать праймари ктор по методе "что читабельнее/компактнее/более ёмко" так же не верно. Раз праймари ктор определяет не просто синтаксис создания экземпляра, но и наполнение (список полей) то и выбираться должен не из эстетичеких понятий.
Ну, поживём-увидим :о))