Как известно в Java внутренние (inner) классы имеют доступ к полям и методам содержащего их класса.
Иногда это удобно. Поэтому мой вопрос: насколько возможно реализовать эту фичу в Nemerle, есть ли подводные камни, будет ли работать интеллисенс и т.д.
Речь скорее всего идёт о макросе, который бы добавлял атрибут или кодовое слово.
Например:

public class OuterClass
{
   string outerInstanceVar;
   public inner class InnerClass
   {
      public PrintVars():void
      {
         WriteLine( "Print Outer Class Instance Var.:" + outerInstanceVar);
      }
   } 

  public InvokeInnerMethod():void
  {
    InnerClass.PrintVars();
  }
}

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

R>Как известно в Java внутренние (inner) классы имеют доступ к полям и методам содержащего их класса.
R>Иногда это удобно. Поэтому мой вопрос: насколько возможно реализовать эту фичу в Nemerle, есть ли подводные камни, будет ли работать интеллисенс и т.д.
R>Речь скорее всего идёт о макросе, который бы добавлял атрибут или кодовое слово.
R>Например:
R>

R>public class OuterClass
R>{
R>   string outerInstanceVar;
R>   public inner class InnerClass
R>   {
R>      public PrintVars():void
R>      {
R>         WriteLine( "Print Outer Class Instance Var.:" + outerInstanceVar);
R>      }
R>   } 

R>  public InvokeInnerMethod():void
R>  {
R>    InnerClass.PrintVars();
R>  }
R>}

R>

Ну это не совсем то, джавовские инер классы намного круче, но на макросах сделать очеееень сложно.

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

Вообщем инер классы я давно хотел и думал как... реализовать можно, но вряли будет удобно использовать

пример:

class A{
int i;
class B{
}
}

A a = new A();
A.B b = a.new B();

Незнаю как такое в макросы закрутить, но оно в джаве очень удобно!!

А то что вы предложыли прикольно но не то... Джавовская штука позволяет создать кучу мелких объектов знающих про своего верхнего класса.
Ну это все реализуемо(скорее кeго кроме new) но вот с Зисом будут проблемы как то в джаве это выглядит так:

A.this.i = 5;

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

R>Как известно в Java внутренние (inner) классы имеют доступ к полям и методам содержащего их класса.
R>Иногда это удобно.

На мой взгляд явовские вложенные и анонимные классы — это вариации на тему замыканий (недозамыкания). Смысл в них я вижу только если хочется сделать эдакую реализацию интерфейсов по месту. Попытка создать подобные макросы (решающие эту задачу) была предпринята здесь. Насколько я понимаю до ума она так и не доведена. В прочем, кое что сделано. Результат можно поглядеть в тестах:

    def clone()
    {
      WriteLine("clone");
      null
    }
    def dispose() { WriteLine("dispose") }
    def obj = newobj
      {
        IDisposable : {dispose};
        ICloneable :  {Clone = clone}
      };

    WriteLine(obj is ICloneable);
    obj.Dispose();
    def _ = (obj :> ICloneable).Clone();

Идея макроса newobj очень проста. Мы как бы создаем объект тип которого формируется автоматически. Методы этого типа реализуются через локальные функции (которые могут быть замкнутыми на внешний контекст).

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

VD>Идея макроса newobj очень проста. Мы как бы создаем объект тип которого формируется автоматически. Методы этого типа реализуются через локальные функции (которые могут быть замкнутыми на внешний контекст).

Спасибо, выглядит достаточно интересно. Да, для меня смысл был как раз в реализации интерфейсов по месту, а точнее наследование от абстрактных классов и реализация нужной логики. И чтобы при этом инстанция этого класса была одна (чтобы не создавать кучу объектов, вызывов довольно много) и являлась приватным полем вызывающего класса.
В приведённом примере объект похоже создаётся каждый раз, к сожалению, это не совсем то, что надо.

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

R>Спасибо, выглядит достаточно интересно. Да, для меня смысл был как раз в реализации интерфейсов по месту, а точнее наследование от абстрактных классов и реализация нужной логики. И чтобы при этом инстанция этого класса была одна (чтобы не создавать кучу объектов, вызывов довольно много) и являлась приватным полем вызывающего класса.
R>В приведённом примере объект похоже создаётся каждый раз, к сожалению, это не совсем то, что надо.

То что объект создается многократно — это не проблема. Добавь проверку некоторого поля и если оно заполнено не создавай объект.

Зато такое решение дает возможность создания разных экземпляров. Иногда это может быть полезно.

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

VD>То что объект создается многократно — это не проблема. Добавь проверку некоторого поля и если оно заполнено не создавай объект.
VD>Зато такое решение дает возможность создания разных экземпляров. Иногда это может быть полезно.

Да, верно. Но так получается чуть меньше сахарнутости. Такая полумера. Ведь, получается, что я обычный nested class тоже просто описываю, но не в теле метода, а в теле класса, и также могу манипулировать разными инстансами, хоть и без возможности доступа к внешнему классу, без передачи ссылки на него.
И, всё-таки, меня интересовал скорее прямо этот конкретный случай. Даже не потому, что мне этот так сильно надо, а просто стало интересно возможно ли сделать такое в Nemerle — повторить java inner classes. Более теоретический вопрос, нежели практический.

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

R>И, всё-таки, меня интересовал скорее прямо этот конкретный случай. Даже не потому, что мне этот так сильно надо, а просто стало интересно возможно ли сделать такое в Nemerle — повторить java inner classes. Более теоретический вопрос, нежели практический.

В принципе возможно. Но есть ли в этом необходимость? Решение каких задач это упростит?

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

VD>В принципе возможно. Но есть ли в этом необходимость? Решение каких задач это упростит?

Ну необходимость такая же как и в любом сахаре. На PC такие вещи может не сильно нужны, GC сильный и с поколениями, а вот на микрофреймворке в WinPhone, GC стартует после каждого съеденного одного мегабайта памяти, поэтому реализовывать всяческие callback's удобно кэшированными наследниками нужного интерфейса, а не лямбдами, чтобы не плодить мусор и быть точно уверенным, что не понаделал массу объектов. Поэтому и вспомнились inner classes из Java и подумалось, можно ли такое реализовать на Nemerle.

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

R>Ну необходимость такая же как и в любом сахаре. На PC такие вещи может не сильно нужны, GC сильный и с поколениями, а вот на микрофреймворке в WinPhone, GC стартует после каждого съеденного одного мегабайта памяти, поэтому реализовывать всяческие callback's удобно кэшированными наследниками нужного интерфейса, а не лямбдами, чтобы не плодить мусор и быть точно уверенным, что не понаделал массу объектов. Поэтому и вспомнились inner classes из Java и подумалось, можно ли такое реализовать на Nemerle.

Можно всех обхитрить, создать макрос, который запоминает объект, и использовать его вместе с NewObject.

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

R>Ну необходимость такая же как и в любом сахаре. На PC такие вещи может не сильно нужны, GC сильный и с поколениями, а вот на микрофреймворке в WinPhone, GC стартует после каждого съеденного одного мегабайта памяти, поэтому реализовывать всяческие callback's удобно кэшированными наследниками нужного интерфейса, а не лямбдами, чтобы не плодить мусор и быть точно уверенным, что не понаделал массу объектов. Поэтому и вспомнились inner classes из Java и подумалось, можно ли такое реализовать на Nemerle.

Ну немерле вообще любит плодить много чего, если тебе важен перформенс и количество памяти (в том числе память уходит и на загрузку классов) то лучше писать на C# там компилятор более очевиден.

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

BM>Ну немерле вообще любит плодить много чего, если тебе важен перформенс и количество памяти (в том числе память уходит и на загрузку классов) то лучше писать на C# там компилятор более очевиден.

Дык Nemerle ни разу не навязывает использование высокоуровневых конструкций и ФВП
Скорость работы того же препроцессора C# вообще трудно измерить...

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

BM>Ну немерле вообще любит плодить много чего, если тебе важен перформенс и количество памяти (в том числе память уходит и на загрузку классов) то лучше писать на C# там компилятор более очевиден.

Hardcase прав из-за мультипарадигменности Nemerle и наличию макросистемы, его просто можно использовать как C#++. Без функциональных заковык. Например инлайнинг математики, что достаточно сильно увеличивает производительность.
С учётом, что в Windows Phone 7 теперь есть только managed код, это довольно актуально.