Здравствуйте, Mckey, Вы писали:
M>Вы будете удивлены, но в C# уже есть:
M>
M> public int X {get;set;}
M>
Фигня полная. Его же нельзя переопределить. Нельзя задать отдельно getter или отдельно setter, чтоб второй был обычный. Физическое поле не доступно.
Вот если бы можно было что-то вроде
protected int X { public get; public set;}
protected int Y { public get; public set { if (Y > 0) throw ...; Y = val; }}
генерирующий
protected int _X;
public int get$X() { return _X;}
public void set$X(int val) { _X = val;}
тогда мы имеем нормальный доступ и к физическому полю и к свойству.
Трудно себе представить, где могут понадобится такие автоматические проперти, кроме как для имплементации интерфейса.
Здравствуйте, VGn, Вы писали:
A>>Было бы здорово, если бы можно было бы ограничивать область видимости члена класса свойством. Не пойму, почему в C# так не сделали
VGn>Патамучта! VGn>Потому что свойства — только фича C#, но не CLR. Тупо сахар над методами.
Даже если предположить, что это так, то что могла помешать это сделать?
Здравствуйте, VGn, Вы писали:
VGn>Патамучта! VGn>Потому что свойства — только фича C#, но не CLR. Тупо сахар над методами.
А метод GetProperties класса System.Type, да и сам тип System.Reflection.PropertyInfo надо пологать галлюцинации?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Свойства в C# или аналогичные set/get в Java. Они ведь чаще всего выглядят так
class A {
private int x;
public int X
{
get {return x;}
set { x = value;}
}
ну и в Яве аналогично.
Я не говорю — всегда. Но в большинстве случаев так.
В итоге посмотришь на некий класс — сотни строк. А разберешься — структура (в смысле С) из десятков двух полей плюс эти свойства.
А почему бы не ввести в язык "генерируемое по умолчанию свойство" ? Например, есть поле x — неявно в классе уже есть свойство X с соответсвующим кодом (см. выше).
Устраивает — пользуйтесь. Не устраивает — перекройте, явное описание отменяет неявное.
А с помощью аттрибутов (аннотаций) можно пометить поле как несоздающее свойство. Или весь класс пометить.
В IDE есть средства для автоматической генерации таких свойств. Почему не перенести эту генерацию в компилятор и не создавать эти сотни лишних строк вообще ?
Здравствуйте, Mckey, Вы писали:
M>Вы будете удивлены, но в C# уже есть:
M>
M> public int X {get;set;}
M>
M>Еще больше возможностей по управлению такими пропертями есть в Nemerle.
В Scala каждое объявление переменной-члена класса автоматически оборачивается в get/set, которые можно переопределять в теле класса. А можно и не переопределять. Также имеется такая приятность, как параметры класса:
class User(id: int, nick: String) {
}
Эквивалент на Java:
class User {
private int _id;
private String _nick;
User(int id, String nick) {
_id = id;
_nick = nick;
}
int id() { return _id; }
String nick() { return _nick; }
}
Почти эквивалент, т.к. вызовы getters в Scala пишутся, естественно, без '()'. Т.е. здесь параметры класса — это read-only свойства.
Здравствуйте, mkizub, Вы писали:
M>Фигня полная. Его же нельзя переопределить. Нельзя задать отдельно getter или отдельно setter, чтоб второй был обычный. Физическое поле не доступно. M>Вот если бы можно было что-то вроде M>
M> protected int X { public get; public set;}
M> protected int Y { public get; public set { if (Y > 0) throw ...; Y = val; }}
M>
Было бы здорово, если бы можно было бы ограничивать область видимости члена класса свойством. Не пойму, почему в C# так не сделали —
public int X
{
int x;
get { return x; }
set { x = value; Invalidate(); }
}
Здравствуйте, VGn, Вы писали:
A>>Было бы здорово, если бы можно было бы ограничивать область видимости члена класса свойством. Не пойму, почему в C# так не сделали
VGn>Патамучта! VGn>Потому что свойства — только фича C#, но не CLR. Тупо сахар над методами.
А свойства в других языках программирования как-то принципиально по-другому реализуются?
G>А свойства в других языках программирования как-то принципиально по-другому реализуются?
Есть языки, в которых их вообще нет. Поэтому CLS их поддерживает, но в таких случаях маапирует на методы.
Т. е. даже если ввести приведённую конструкцию в язык, она будет не CLSCompliant.
Здравствуйте, VGn, Вы писали:
VGn>Есть языки, в которых их вообще нет. Поэтому CLS их поддерживает, но в таких случаях маапирует на методы. VGn>Т. е. даже если ввести приведённую конструкцию в язык, она будет не CLSCompliant.
Extension methods тоже не CLSCompliant, тем не менее это не особо мешает их использовать.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А почему бы не ввести в язык "генерируемое по умолчанию свойство" ? Например, есть поле x — неявно в классе уже есть свойство X с соответсвующим кодом (см. выше).