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

> Может лучше вложить время в поддержку WPF?
Да, однозначно — лучше... (а так же silverlight, vs 2010, WP7)

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

__>Так синтаксис J : int { get; set; } и так уже рабочий.

га Почувствуй себя кэпом! (это я про свои инновации) Ну и хорошо! А какое имя даётся хранилищу проперти J?

__>Мое предложение было в унифицировании имен полей.
__>Но все же видится мне более правильным решением указывать их явно.

Мне кажется, вы хотите сделать что-то смешное: сначала сократить объявление проперти, а потом его же и раздуть всякими прибамбасами доступа, именем хранилища... а смысл? Уже есть полный синтаксис описания проперти, сахар нужен лишь тем, кто согласен с дефолтовыми настройками. Вот по дефолту и сделайте _j — вполне нормальное имя (тем более, что ему не с чем пересекаться — другой проперти J не будет, а поля класса будут с другими именами.

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

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

__>>Так синтаксис J : int { get; set; } и так уже рабочий.

M>га Почувствуй себя кэпом! (это я про свои инновации) Ну и хорошо! А какое имя даётся хранилищу проперти J?

__>>Мое предложение было в унифицировании имен полей.
__>>Но все же видится мне более правильным решением указывать их явно.

M>Мне кажется, вы хотите сделать что-то смешное: сначала сократить объявление проперти, а потом его же и раздуть всякими прибамбасами доступа, именем хранилища... а смысл? Уже есть полный синтаксис описания проперти, сахар нужен лишь тем, кто согласен с дефолтовыми настройками. Вот по дефолту и сделайте _j — вполне нормальное имя (тем более, что ему не с чем пересекаться — другой проперти J не будет, а поля класса будут с другими именами.

Если бы все согласны были, то по умолчнию _j это хорошо, но не все согласны.
Хотя наиболее распростанненые случаи когда поле называется _j или j, и очень редки когда называется по другому.

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

__>Если бы все согласны были, то по умолчнию _j это хорошо, но не все согласны.

А какие варианты "несогласных" уже озвучены и чем они лучше текущего? (я именно про именование, а не ввод кучи атрибутов, вводящих те же яйца, но в профиль)

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

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

__>>Если бы все согласны были, то по умолчнию _j это хорошо, но не все согласны.

M>А какие варианты "несогласных" уже озвучены и чем они лучше текущего? (я именно про именование, а не ввод кучи атрибутов, вводящих те же яйца, но в профиль)

Абстрагироваться от именования вообще, так как в get-only свойствах переменные нужны лишь один раз — в конструкторе.

Вариант 1:

class Foo
{
    public Blah { get; } // компилятор генерирует get { _N_Blah_189273; }
    private _N_Blah_189273; // поле генерируется компилятором

    public this()
    {
        Blah = DateTime.Now.Seconds; // Blah подменяется на _N_Blah_189273
        InitializeField(out Blah); // Blah подменяется на _N_Blah_189273, все работает
    }
}

Вариант 2:

class Bar
{
    public Blah { get; } // компилятор генерирует get { _N_Blah_189273; }
    private _N_Blah_189273; // поле генерируется компилятором

    public this()
    {
        field(Blah) = DateTime.Now.Seconds; // макрос field магически возвращает нужное поле для свойства
        InitializeField(out field(Blah)); // все опять же магически работает
    }
}

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

M>catbert, спасибо, ХОТЯ БЫ СКОМПИЛИРОВАЛОСЬ!

C>>Ты создаешь макрос уровня выражения.

M>Это-то и пугает! Разве не унифицированным должен быть подход к макросам?

Ну, по-хорошему оно вроде как и да. Но Nemerle (как бы нам того не хотелось) не совершенен.

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

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

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

__>>>Если бы все согласны были, то по умолчнию _j это хорошо, но не все согласны.

M>>А какие варианты "несогласных" уже озвучены и чем они лучше текущего? (я именно про именование, а не ввод кучи атрибутов, вводящих те же яйца, но в профиль)

C>Абстрагироваться от именования вообще, так как в get-only свойствах переменные нужны лишь один раз — в конструкторе.

C>Вариант 1:

Должна быть возможность отделить поле от свойства.
Хотя бы для атрибутов как указал hi_octane.

C>Вариант 2:

+1
Это выглядит хорошим решением.

[AttributeUsage(AttributeTargets.Property)]
class SpecialAttribute : Attribute { }

abstract class Base
{
  [Special] public virtual PublicIntGetSet : int { get; set; } 
  public abstract PublicIntGet : int { get; }

  internal virtual InternalIntGetSet : int { get; set; } 
  protected abstract ProtectedIntGet : int { get; }
}

class Derived : Base
{
  [Special] public override PublicIntGetSet : int { get; set; }
  
  public override PublicIntGet : int { get; }

  internal override InternalIntGetSet : int { get; set; }
  
  protected override ProtectedIntGet : int { get; }
  
  public this()
  {
    field(PublicIntGetSet) = 1;
    field(PublicIntGet) = 2;
    field(InternalIntGetSet) = 3;
    field(ProtectedIntGet) = 4;
  }  
}

Я попытался сделать Derived на основе макроса Accessor, но увы не получилось.
Если кто-то сможет сделать для сравнения, будет очень показательным.

Nemerle Enhancement Proposal 1 Revision 2

Цель
Заменить макрос Accessor на автосвойства.
Некоторые возможности на сегодня недоступны при использовании макроса Accessor: указание модификаторов internal, protected, new.
Можно доделать макрос, но его использование неинтуитивно и неуклюже.

Автосвойства для чтения
Разрешить создания автосвойств только для чтения. (get only)
Наряду с автосвойством для чтения-записи (get set)

class MyClass
{
  public MyGetProperty : int { get; }
}

Доступ к полю
Предоставить специальный макрос для доступа к полям автосвойств.
Это позволит:
1. Инициализировать автосвойства только для чтения.
2. Добраться до поля автосвойства, что не представляется возможным сегодня.

class MyClass
{
  public MyGetProperty : int { get; }

  public this()
  {
    fieldof(MyGetProperty) = 1;
  }
}

Макрос Record
Описанный метод позволит описывать классы понятней:

class Immutable
{
  public Prop1 : string { get; }
  public Prop2 : int { get; }
}

Пример
Полный пример с учетом всех предложенией:

[AttributeUsage(AttributeTargets.Property)]
class SpecialAttribute : Attribute { }

interface ISome
{
  StringGetSet : string { get; set; }
  StringGet : string { get; }
}

abstract class Base
{
  public virtual PublicIntGetSet : int { get; set; } 
  public abstract PublicIntGet : int { get; }

  internal virtual InternalIntGetSet : int { get; set; } 
  protected abstract ProtectedIntGet : int { get; }
}

[Record]
class Derived : Base, ISome
{
  #region ISome
  
  [Special] public StringGetSet : string { get; set; }
  
  public StringGet : string { get; }
  
  #endregion
    
  #region Base
  
  [Special] public override PublicIntGetSet : int { get; set; }  
  public override PublicIntGet : int { get; }
  
  internal new InternalIntGetSet : int { get; set; }  
  protected override ProtectedIntGet : int { get; }
  
  #endregion Base
  
  #region Derived
  
  public virtual OtherProp : int { get; }
  
  #endregion
  
  public this()
  {
    fieldof(StringGsetSet) = "a";
    InitValueOut(out fieldof(StringGet), "b");
      
    fieldof(PublicIntGetSet) = 1;
    InitValueRef(ref fieldof(PublicIntGet) = 2;
    fieldof(InternalIntGetSet) = 3;
    InitValueOut(out fieldof(ProtectedIntGet), 4);
    
    fieldof(OtherProp) = 10;
  }
  
  static InitValueRef[T](s : ref T, value : T) : void { s = value; }  
  static InitValueOut[T](s : out T, value : T) : void { s = value; }
}

module Program
{
    Main() : void
    {
        def d1 = Derived();
        def d2 = Derived("a", "b", 1, 2, 3, 4, 10);
    }
}

Variant
В variant вместо задания полей, будут задаваться свойства.
Значение будет таким же как и автосвойства только для чтения (get only).
Для доступа к переменной следует использовать макрос fieldof:

variant A
{
  | X
    {
      i : int; j : int; // Определение свойств
      public new this(i : int, j : int)
      {
        fieldof(i) = i;
        fieldof(j) = j;
      }
    }
  | Y
    {
      K : int; L : int; // Определение свойств
      public new this(k : int, l : int)
      {
        fieldof(K) = k;
        fieldof(L) = l;
      }
    }
}

def x = A.X(1, 2);
def i = x.i;
def j = x.j;

def y = A.Y(1, 2);
def k = y.K;
def l = y.L;

Надеюсь учел все пожелания участников дискуссии.
Пишите.

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

__>Nemerle Enhancement Proposal 1 Revision 2

Ну выглядит удобно. Мне нравится.

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

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

>> Может лучше вложить время в поддержку WPF?
D>Да, однозначно — лучше... (а так же silverlight, vs 2010, WP7)

Дык, подключайтесь! Поддержку гарантируем. У нас на все времени не хватит по любому.