Несогласованная область видимости полей класса
От: Mumitroller Беларусь  
Дата: 01.02.11 16:44
Оценка:
Компилятор не дает сделать вложенные в свойства поля с одинаковыми именами:
class Class1
{
    public Prop1 : int
    {
        mutable fld : int;
        get { fld; }
        set { fld = value; }
    }
    
    public Prop2 : int
    {
        mutable fld : int; // <== field: static mutable fld : int; redefined in `Program'
        get { fld; }
        set { fld = value; }
    }
}

Тем не менее ругается на попытку обратиться к полю, вложенному в другое свойство:
class Class2
{
    public Prop1 : int
    {
        mutable fld : int;
        get { fld; }
        set { fld = value; }
    }
    
    public Prop2 : int
    {
        get { fld; }         // <== unbound name `fld'
        set { fld = value; } // <== unbound name `fld'
    }
}

Ошибка во втором случае выглядит логичной, так как видимость поля fld ограничена свойством Prop1.

А вот ошибка в первом случае выглядит странной. Проблема, конечно, некритичная, но заставляет в таких случаях выдумывать более длинные имена полей.

Mumitroller
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.02.11 20:48
Оценка:
Здравствуйте, Mumitroller, Вы писали:

M>Компилятор не дает сделать вложенные в свойства поля с одинаковыми именами:


Ругается только IDE. К сожалению, если сделать в IDE переименование такое же, как при компиляции, то для таких полей не будет доступен комплит. Мы решили пойти простым путем и просто не переименовывать такие поля в IDE.

Откровенно говоря, на мой взгляд хорошей идеей было бы давать разные имена полям. Иначе как потом читать код?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Несогласованная область видимости полей класса
От: Mumitroller Беларусь  
Дата: 02.02.11 13:00
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Откровенно говоря, на мой взгляд хорошей идеей было бы давать разные имена полям. Иначе как потом читать код?


Так и приходится делать. Но для меня в случае, когда есть несколько однотипных свойств, удобнее использовать в них поля с одинаковыми именами, так как в этом случае технология copy-paste лучше работает.

Mumitroller
Re[3]: Несогласованная область видимости полей класса
От: Аноним  
Дата: 02.02.11 13:33
Оценка:
Здравствуйте, Mumitroller, Вы писали:

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


VD>>Откровенно говоря, на мой взгляд хорошей идеей было бы давать разные имена полям. Иначе как потом читать код?


M>Так и приходится делать. Но для меня в случае, когда есть несколько однотипных свойств, удобнее использовать в них поля с одинаковыми именами, так как в этом случае технология copy-paste лучше работает.


Для однотипных свойств можно создать макрос

M>Mumitroller
Re[4]: Несогласованная область видимости полей класса
От: Mumitroller Беларусь  
Дата: 02.02.11 13:44
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Для однотипных свойств можно создать макрос


Они не настолько однотипные. Да и не вижу я смысла писать макрос для нескольких применений — только лишний уровень косвенности при чтении кода будет без реальной выгоды. К тому же, не умею я макросы писать (точнее, не пробовал пока еще).

Mumitroller
Re[3]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.11 20:56
Оценка: -1
Здравствуйте, Mumitroller, Вы писали:

M>Так и приходится делать. Но для меня в случае, когда есть несколько однотипных свойств, удобнее использовать в них поля с одинаковыми именами, так как в этом случае технология copy-paste лучше работает.


Nemerle — это язык для тех кто не любит копипэстить.

Так что мой совет, или попробуй обойтись автосвойствами, или напиши макрос который автоматизирует генерацию кода для однотипных свойств (и не только).

Что за задача то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.02.11 00:46
Оценка:
Здравствуйте, Mumitroller, Вы писали:

M>Они не настолько однотипные. Да и не вижу я смысла писать макрос для нескольких применений — только лишний уровень косвенности при чтении кода будет без реальной выгоды.


Или они однотипны, или нет. Третьего не дано .

M>К тому же, не умею я макросы писать (точнее, не пробовал пока еще).


Дык, самое время освоить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Несогласованная область видимости полей класса
От: Mumitroller Беларусь  
Дата: 03.02.11 09:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Nemerle — это язык для тех кто не любит копипэстить.


Это хорошо, но отсутствие скопированного кода — не самоцель, хотя, конечно же, в общем случае его лучше избегать.

VD>Так что мой совет, или попробуй обойтись автосвойствами, или напиши макрос который автоматизирует генерацию кода для однотипных свойств (и не только).


VD>Что за задача то?


Есть класс и несколько его предопределенных instances, которые оформлены в виде статических свойств класса. Эти instances создаются только при первом обращении к ним. Выглядит это как-то так:

class Class1
{
    static Inst1 : Class1
    {
        mutable inst1Field : Class1;
        get
        {
            when (inst1Field == null)
            {
                inst1Field = Class();
                // ... здесь инициализация inst1Field
            }
            instField;
        }
    }
    
    static Inst2 : Class1
    {
        mutable inst2Field : Class1;
        get
        {
            when (inst2Field == null)
            {
                inst2Field = Class();
                // ... здесь инициализация inst2Field
            }
            instField;
        }
    }
}


Инициализация может различаться весьма значительно. Учитывая то, что таких instances немного (сейчас 2, в перспективе — до пары десятков), то писать макрос смысла не вижу, так как это займет намного больше времени, чем копирование и затруднит чтение и понимание кода. Изменить имя поля вместе с логикой инициализации гораздо проще и не создает никаких проблем. Просто для меня это чуть-чуть менее удобно. Кстати, Nemerle ведь не требует, чтобы имена полей вложенного класса не пересекались с именами полей класса-контейнера. Мне это кажется прямой аналогией.

В общем, в данном контексте эта проблема выеденного яйца не стоит. Забейте.

Mumitroller
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[4]: Несогласованная область видимости полей класса
От: Ziaw Россия  
Дата: 03.02.11 16:32
Оценка:
Здравствуйте, VladD2, Вы писали:

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


M>>Так и приходится делать. Но для меня в случае, когда есть несколько однотипных свойств, удобнее использовать в них поля с одинаковыми именами, так как в этом случае технология copy-paste лучше работает.


VD>Nemerle — это язык для тех кто не любит копипэстить.


VD>Так что мой совет, или попробуй обойтись автосвойствами, или напиши макрос который автоматизирует генерацию кода для однотипных свойств (и не только).


Вот это, имхо, неверная позиция. Признай, что IDE косячно работает в данном, вполне корректном с точки зрения языка, моменте. Навязывать кому-то дизайн приложения изза косяков в IDE позиция ненормальная
Re[5]: Несогласованная область видимости полей класса
От: Ziaw Россия  
Дата: 03.02.11 17:54
Оценка: 2 (1)
Здравствуйте, Mumitroller, Вы писали:

M>Учитывая то, что таких instances немного (сейчас 2, в перспективе — до пары десятков), то писать макрос смысла не вижу, так как это займет намного больше времени, чем копирование и затруднит чтение и понимание кода.


На самом деле облегчит. Да и макрос такой есть уже, но работает но только с методами, а не свойствами. Зато потокобезопасен, хотя это отключаемо.

using Nemerle;
using System.Console;

module Program
{
  [Memoize]
  Inst1() : string
  {
    WriteLine("Init Inst1");
    "Inst1"
  }
  Main() : void
  {
    WriteLine("Hi!");
    WriteLine(Inst1());
    WriteLine(Inst1());
  }
}


В принципе ничто не мешает допилить именно этот макрос со свойствами.
Re[6]: Несогласованная область видимости полей класса
От: Ziaw Россия  
Дата: 03.02.11 20:15
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>В принципе ничто не мешает допилить именно этот макрос со свойствами.


Кстати, кто что думает насчет синтаксического memoize?
using Nemerle;
using System.Console;

module Program
{
  Inst1() : string
  {
    memoize 
    {
      WriteLine("Init Inst1");
      "Inst1"
    }
  }
  Inst2 : string
  {
    get 
    {
      memoize (Scope = Class, Synchronized = false)
      {
        WriteLine("Init Inst1");
        "Inst1"
      }
    }
  }

  Main() : void
  {
    WriteLine("Hi!");
    WriteLine(Inst1());
    WriteLine(Inst1());
    WriteLine(Inst2);
    WriteLine(Inst2);
  }
}


Могу добавить, если Влад разрешит, новые фичи вроде закрыты.
Re[7]: Несогласованная область видимости полей класса
От: hardcase Пират http://nemerle.org
Дата: 03.02.11 20:50
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Z>>В принципе ничто не мешает допилить именно этот макрос со свойствами.


Z>Кстати, кто что думает насчет синтаксического memoize?


Он вроде был, да только хреново работал.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.02.11 23:19
Оценка: 2 (1)
Здравствуйте, Mumitroller, Вы писали:

M>Есть класс и несколько его предопределенных instances, которые оформлены в виде статических свойств класса. Эти instances создаются только при первом обращении к ним. Выглядит это как-то так:


M>
M>class Class1
M>{
M>    static Inst1 : Class1
M>    {
M>        mutable inst1Field : Class1;
M>        get
M>        {
M>            when (inst1Field == null)
M>            {
M>                inst1Field = Class();
M>                // ... здесь инициализация inst1Field
M>            }
M>            instField;
M>        }
M>    }
M>


Понятно. Просто используй макрос Memoize. Тогда код будет очень простым:
using Nemerle;

class Class1
{
  static Inst1 : Class1
  {
    [Memoize]
    get
    {
        inst1Field = Class();
        // ... здесь инициализация inst1Field
    }
  }



M>Инициализация может различаться весьма значительно. Учитывая то, что таких instances немного (сейчас 2, в перспективе — до пары десятков), то писать макрос смысла не вижу,


Макрос уже есть.

M>так как это займет намного больше времени, чем копирование и затруднит чтение и понимание кода. Изменить имя поля вместе с логикой инициализации гораздо проще и не создает никаких проблем.


Как я уже говорил — это недоработка IDE. Сам компилятор это перенесет.

M>Просто для меня это чуть-чуть менее удобно. Кстати, Nemerle ведь не требует, чтобы имена полей вложенного класса не пересекались с именами полей класса-контейнера. Мне это кажется прямой аналогией.


Нет не требует. Но это отдельный тип. Тут же тип один. Реально поля просто переименовываются. К ним дописывается что-то вроде _N_мяПоля_4323. Как ты понимаешь, при этом комплит уже работать не будет. Конечно можно было бы реализовать комплит для подобных случаев отдельно. Но мы схалтурили и просто выключили переименование в IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.02.11 23:21
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>В принципе ничто не мешает допилить именно этот макрос со свойствами.


Да нет никаких проблем со свойствами. Просто макру нужно применять не к свойству, а к эксесорам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.02.11 23:23
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Могу добавить, если Влад разрешит, новые фичи вроде закрыты.


Да до релиза не надо внсоить изменений.

Сама идея сделать memoize еще и выражением — не плохая идея. Иногда это может пригодиться. Например, когда нужно мемоизировать результат вложенной функции или подвыражения.

Но приведенные тобой юзкейзы и так работают. Memoize можно применять к геттерам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.02.11 23:32
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Вот это, имхо, неверная позиция. Признай, что IDE косячно работает в данном, вполне корректном с точки зрения языка, моменте.


А никто ничего и не отрицал.

Z>Навязывать кому-то дизайн приложения изза косяков в IDE позиция ненормальная


Не навязывать, а подсказывать правильные подходы. Назвать копипэст дизайном у меня язык не поворачивается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Несогласованная область видимости полей класса
От: Ziaw Россия  
Дата: 03.02.11 23:38
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Да до релиза не надо внсоить изменений.

VD>Сама идея сделать memoize еще и выражением — не плохая идея. Иногда это может пригодиться. Например, когда нужно мемоизировать результат вложенной функции или подвыражения.
VD>Но приведенные тобой юзкейзы и так работают. Memoize можно применять к геттерам.

Естественно выражение не для этих юзкейсов, а для того, чтобы мемоизация могла применяться не только в "источнике", но и в "приемнике". А то, что она покроет юзкейсы атрибута, это просто в плюс.

То, что на геттер можно повесить я подозревал, но что-то с ходу не получилось, скорее всего какая-то глупая ошибка, я не пытался понять даже.
Re[9]: Несогласованная область видимости полей класса
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.02.11 00:37
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Естественно выражение не для этих юзкейсов, а для того, чтобы мемоизация могла применяться не только в "источнике", но и в "приемнике". А то, что она покроет юзкейсы атрибута, это просто в плюс.


Откровенно говоря кроме мемоизацию локальных функций я реальных применений особо не вижу. Возможно фантазии не хватает.

Z>То, что на геттер можно повесить я подозревал, но что-то с ходу не получилось, скорее всего какая-то глупая ошибка, я не пытался понять даже.


Странно. Там ошибиться то можно только если не открыть пространство имен Nemerle или не верно имя макроса написать. В общих случаях будет сообщение о том, что нет атрибута.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Несогласованная область видимости полей класса
От: Ziaw Россия  
Дата: 04.02.11 05:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Откровенно говоря кроме мемоизацию локальных функций я реальных применений особо не вижу. Возможно фантазии не хватает.


Ну любая локальная функция, вызываемая 1 раз за вызов глобального метода отличается от выражения лишь предпочтениями программиста. Профит в том, чтобы взять то же значение при следующем вызове метода не вычисляя заново.



Допустим у нас в базе есть огромный справочник заведомо не меняющийся за время ее работы.

[Memoize] // тут прекрасно подойдет атрибут
getMyDictionary() : IList[MyDictionary]
{
  db.GetTable.[MyDictionary]().ToList()
}

getMyDictionaryString(key : int) : string
{
  memoize // а тут уже не очень
  {
    getMyDictionary().ToDictionary(d => d.Id, d => d.Text)
  }[key]
}

getMyDictionaryKey(str : string) : int
{
  memoize 
  {
    getMyDictionary().ToDictionary(d => d.Text, d => d.Id)
  }[str]
}


Делать локальные функции тут не вижу смысла, создавать новый хэш на каждый getMyDictionaryХхх бесполезно, проще перебором.
Re[6]: Несогласованная область видимости полей класса
От: Mumitroller Беларусь  
Дата: 04.02.11 07:58
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>На самом деле облегчит. Да и макрос такой есть уже, но работает но только с методами, а не свойствами. Зато потокобезопасен, хотя это отключаемо.


Z>using Nemerle;
Z>using System.Console;

Z>module Program
Z>{
Z>  [Memoize]
Z>  Inst1() : string
Z>  {
Z>    WriteLine("Init Inst1");
Z>    "Inst1"
Z>  }
Z>  Main() : void
Z>  {
Z>    WriteLine("Hi!");
Z>    WriteLine(Inst1());
Z>    WriteLine(Inst1());
Z>  }
Z>}


Про Memoize я даже и не подумал. Спасибо, так и сделаю.

Mumitroller
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.