Объявляю класс

public partial module WorkingClass[T] where T: Form, new()
    {
        i: int = 1;
        public I: System.Int32
        {
            get
            {
                i
            }
        }

        public mainWorking(): void
        {
            using (def testInstance = ThirdPartyLibrary.TestClass())
            {
                testInstance.open();
            }
        }

        public class InnerClass
        {
        }

        public event Event: int -> int
        {
            add
            {
                _ = value
            }
            remove
            {
                _ = value
            }
        }

        public variant SSS
        {
            | A {}
            | B {}
        }

        public enum ClassEnumeration { | verybad = -2 | bad | noRating | well | verywell}
    }

На два последних вложения ругается
error : enums cannot have generic type parameters
error : wrong number of type parameters to `SSS'

Если убрать генерик, то всё нормально работает
В чём проблема?

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

FDS>В чём проблема?

Это баг (возможно дизайна). Параметры генериков протаскиваются через все вложенные типы. Т.е. тут получается что в энум приезжает неявный параметр T.
Я пока не знаю как исправить этот баг (не поломав все к чертям).

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

FDS>В чём проблема?

В гугловском багтреке это один из самых старых багов. Поляки как-то по-своему понимали концепцию генериков дотнета.

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

FDS>>В чём проблема?

H>В гугловском багтреке это один из самых старых багов. Поляки как-то по-своему понимали концепцию генериков дотнета.

На мой взгляд, нормально понимаю. Если мы объявляем вложенный класс, то по шарповской иделогии он наследует внешний парамтр типов. Так почему с энумами должно быть по другому? Ну, а создать парметризованный энум в донете нельзя.

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

FDS>>>В чём проблема?
H>>В гугловском багтреке это один из самых старых багов. Поляки как-то по-своему понимали концепцию генериков дотнета.

VD>На мой взгляд, нормально понимаю. Если мы объявляем вложенный класс, то по шарповской иделогии он наследует внешний парамтр типов. Так почему с энумами должно быть по другому? Ну, а создать парметризованный энум в донете нельзя.

А почему тогда в шарпе можно создать енам в дженерик-классе?

class Program
{
  static void Main() {
    var e1 = X<int>.E.V;
    var e2 = X<string>.E.V;
    var ee = e1 == (X<int>.E)e2;
  }
}

class X<Y>
{
    public enum E { V, }
}

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

VD>На мой взгляд, нормально понимаю. Если мы объявляем вложенный класс, то по шарповской иделогии он наследует внешний парамтр типов. Так почему с энумами должно быть по другому? Ну, а создать парметризованный энум в донете нельзя.

Хмм, действительно, значит я заблуждаюсь (я как-то ковырял этот баг да безрезультатно — опыта мало было). Вот IL для кода:

public class Outer<T>
{
  public class Inner { }
  
  public enum X { A ,B }
}

.class public auto ansi beforefieldinit Outer`1<T>
    extends [mscorlib]System.Object
{
    // Nested Types
    .class nested public auto ansi beforefieldinit Inner<T>
        extends [mscorlib]System.Object
    {
        // Methods
        .method public hidebysig specialname rtspecialname 
            instance void .ctor () cil managed 
        {
            // Method begins at RVA 0x2058
            // Code size 7 (0x7)
            .maxstack 8

            IL_0000: ldarg.0
            IL_0001: call instance void [mscorlib]System.Object::.ctor()
            IL_0006: ret
        } // end of method Inner::.ctor

    } // end of class Inner

    .class nested public auto ansi sealed X<T>
        extends [mscorlib]System.Enum
    {
        // Fields
        .field public specialname rtspecialname int32 value__
        .field public static literal valuetype Outer`1/X<!T> A = int32(0)
        .field public static literal valuetype Outer`1/X<!T> B = int32(1)

    } // end of class X


    // Methods
    .method public hidebysig specialname rtspecialname 
        instance void .ctor () cil managed 
    {
        // Method begins at RVA 0x2050
        // Code size 7 (0x7)
        .maxstack 8

        IL_0000: ldarg.0
        IL_0001: call instance void [mscorlib]System.Object::.ctor()
        IL_0006: ret
    } // end of method Outer`1::.ctor

} // end of class Outer`1

Значит просто компилятор не различает внешние параметры типа и объявленные для enum-а.

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

FDS>В чём проблема?

Ок. я поправлю

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

_FR>А почему тогда в шарпе можно создать енам в дженерик-классе?

_FR>

_FR>class Program
_FR>{
_FR>  static void Main() {
_FR>    var e1 = X<int>.E.V;
_FR>    var e2 = X<string>.E.V;
_FR>    var ee = e1 == (X<int>.E)e2;
_FR>  }
_FR>}

_FR>class X<Y>
_FR>{
_FR>    public enum E { V, }
_FR>}
_FR>

По дури, на мой взгляд. Смысла в этом нет ни грамма.

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

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

FDS>>В чём проблема?

H>Ок. я поправлю

Это косяк в SRE. При попытке сгенерировать такой энум приезжает исключение из внутренностей System.Reflection.Emit.TypeBuilder:

C:\!Proj\nemerle>bin\Debug\net-3.5\Stage1\ncc.exe "C:\!Proj\nemerle\bin\p1.n" -out:C:\!Proj\nemerle\bin\p1.exe -t:exe
←[01;31merror←[0m: internal compiler error: got some unknown exception of type System.NotSupportedException: Указанный метод не поддерживает
ся.
   в System.Reflection.Emit.TypeBuilderInstantiation.IsSubclassOf(Type c)
   в System.Reflection.Emit.TypeBuilder.SetConstantValue(Module module, Int32 tk, Type destType, Object value)
   в System.Reflection.Emit.FieldBuilder.SetConstant(Object defaultValue)
   в Nemerle.Compiler.FieldBuilder.CreateEmitBuilder(TypeBuilder tb) в C:\!Proj\nemerle\ncc\generation\HierarchyEmitter.n:строка 1229

Такая фигня происходит при попытке установить значение в поле, отвечающее за отдельное значение перечисления.

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

H>Такая фигня происходит при попытке установить значение в поле, отвечающее за отдельное значение перечисления.

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

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

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

H>>Такая фигня происходит при попытке установить значение в поле, отвечающее за отдельное значение перечисления.

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

Он с генериком, посмотри внимательно на листинг, что я привел выше.

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

_FR>>А почему тогда в шарпе можно создать енам в дженерик-классе?

VD>По дури, на мой взгляд. Смысла в этом нет ни грамма.

Даже приватный не нужен, да? Суров ответ

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

VD>>По дури, на мой взгляд. Смысла в этом нет ни грамма.

_FR>Даже приватный не нужен, да? Суров ответ

Не понял.

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

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

VD>>>По дури, на мой взгляд. Смысла в этом нет ни грамма.

_FR>>Даже приватный не нужен, да? Суров ответ

VD>Не понял.

Приватный энум может быть полезен в контейнерных классах:

public class MyCollection<T>
{
  private enum ItemStates { Foo, Bar, Baz }
}

Где ItemStates используется исключительно для некоторой внутренней логики.

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

VD>>>По дури, на мой взгляд. Смысла в этом нет ни грамма.
_FR>>Даже приватный не нужен, да? Суров ответ

VD>Не понял.

Внутри реализиции дженерик-класса

class X<Y>
{
  private enum E { V, }

  private E State { get; set; }

  public M() {
    switch(State) {
      // …
    }//switch
  }
}

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

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

H>Приватный энум может быть полезен в контейнерных классах:
H>

H>public class MyCollection<T>
H>{
H>  private enum ItemStates { Foo, Bar, Baz }
H>}
H>

H>Где ItemStates используется исключительно для некоторой внутренней логики.

И что даст такая инкапсуляция? Что случится если этот enum будет internal?

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

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

H>>Приватный энум может быть полезен в контейнерных классах:
H>>

H>>public class MyCollection<T>
H>>{
H>>  private enum ItemStates { Foo, Bar, Baz }
H>>}
H>>

H>>Где ItemStates используется исключительно для некоторой внутренней логики.

VD>И что даст такая инкапсуляция? Что случится если этот enum будет internal?

А, собственно, что в этом плохого? Мы просто хотим структурировать программу, вводя некоторый вложенный Enum, как и в других классах. Что даст инкапсуляция перечисления в нешаблонный класс?

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

VD>И что даст такая инкапсуляция? Что случится если этот enum будет internal?

То, что данный enum можно спрятать от классов внутри сборки.

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

VD>По дури, на мой взгляд. Смысла в этом нет ни грамма.

А почему это в Nemerle сделать нельзя?

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

VD>>По дури, на мой взгляд. Смысла в этом нет ни грамма.

IT>А почему это в Nemerle сделать нельзя?

SRE не позволяет. Да и не нужно никому.

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

FDS>А, собственно, что в этом плохого? Мы просто хотим структурировать программу, вводя некоторый вложенный Enum, как и в других классах. Что даст инкапсуляция перечисления в нешаблонный класс?

Ну, тогда надо было разрешать только private-энумы. Это в компиляторе можно разрулить. Сам энум сделать internal, но сделать вид, что он доступен только из конкретного типа.

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

VD>>И что даст такая инкапсуляция? Что случится если этот enum будет internal?

C>То, что данный enum можно спрятать от классов внутри сборки.

Если у сборки нет друзей, то никакой разницы не будет. Да и не ясно зачем прятать константы.

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

IT>>А почему это в Nemerle сделать нельзя?

VD>SRE не позволяет. Да и не нужно никому.

У меня встречный вопрос к _FRED_ и IT. Сколько в написанных вами проектов enum-ов вложенных в дженерик-типы?

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

IT>>А почему это в Nemerle сделать нельзя?

VD>SRE не позволяет. Да и не нужно никому.

Первое мне понятно. А вот как ты догодался про никому не нужно никак в толк не возьму

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

IT>Первое мне понятно. А вот как ты догодался про никому не нужно никак в толк не возьму

Было бы нужно, хоть кто-то за 7 лет попросил бы.

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

IT>>Первое мне понятно. А вот как ты догодался про никому не нужно никак в толк не возьму
VD>Было бы нужно, хоть кто-то за 7 лет попросил бы.

Ну вот просят. Что теперь?

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

IT>Ну вот просят. Что теперь?

Никто ничего не просит. Орел просто перебирает доступные варианты. Он вот еще баг нашел появляющийся если класс назвать new и использовать его в констрэйнах. Баг конечно, но воспроизвести его смогут только знатные извращенцы.

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

VD> Никто ничего не просит. Орел просто перебирает доступные варианты.

Ну, здесь ты прав: я вообще Enum не люблю, просто вяло пишу описание деклараций AST. Хотя если всё делать с перечисляемыми типами, а не простыми int-ами, то это и понадобится может.

VD> Он вот еще баг нашел появляющийся если класс назвать new и использовать его в констрэйнах. Баг конечно, но воспроизвести его смогут только знатные извращенцы.

Кстати, я таких извращенцев видел: человек 15 со словом base, когда переносили код с Java на C# с помощью "автоматического" трансформатора, который не знал, что с ним делать. А ведь в C# такой Enum создать можно, что будет, если код начнут переносить с C# на Nemerle?
Нереально?

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

FDS>Кстати, я таких извращенцев видел: человек 15 со словом base, когда переносили код с Java на C# с помощью "автоматического" трансформатора, который не знал, что с ним делать. А ведь в C# такой Enum создать можно, что будет, если код начнут переносить с C# на Nemerle?
FDS>Нереально?

Конкретно эта ситуация с этим перечислением вряд ли будет доставлять проблемы (вынос перечисления вне класса тривален). Проблемы трансляции switch-а с goto значительно реальнее.

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

H>Конкретно эта ситуация с этим перечислением вряд ли будет доставлять проблемы (вынос перечисления вне класса тривален). Проблемы трансляции switch-а с goto значительно реальнее.

Заменить base на @base — тоже тривиально. Но мучений с этим что-то было не мало.
Я вот например, никаких switch с goto у себя в коде не припомню: для меня это как раз нереально.

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

VD>Баг конечно, но воспроизвести его смогут только знатные извращенцы.

Одному такому извращенцу Хейльсбрг подарил стандарт C# с личной благодарностью. Видимо от создателей Немерле этого в принципе не стоит ожидать.

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

FDS>Я вот например, никаких switch с goto у себя в коде не припомню: для меня это как раз нереально.

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

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

FDS>Кстати, я таких извращенцев видел: человек 15 со словом base, когда переносили код с Java на C# с помощью "автоматического" трансформатора, который не знал, что с ним делать. А ведь в C# такой Enum создать можно, что будет, если код начнут переносить с C# на Nemerle?
FDS>Нереально?

Этого просто не надо делать. C# можно подключить к проекту в исходном виде. Далее можно использовать partial-классы или переносить нужные (мелкие) части.

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

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

VD>>Баг конечно, но воспроизвести его смогут только знатные извращенцы.

IT>Одному такому извращенцу Хейльсбрг подарил стандарт C# с личной благодарностью. Видимо от создателей Немерле этого в принципе не стоит ожидать.

Да, это точно. Дарить стандарт C#, лично я никому не намерен .

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

VD>Еще раз повторюсь, что мир на тебе не заканчивается.

Да я как раз это и говорю: кто-то считает, что незначительно, а мой опыт говорит об обратном. Для кого-то значительно, а для меня — нет.

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

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

VD>Да, это точно. Дарить стандарт C#, лично я никому не намерен .

Нисколечки в этом не сомневаюсь.

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

VD>Еще раз повторюсь, что мир на тебе не заканчивается. У тебя нет, у других может быть. В прочем, пока что никто не жаловался вроде.

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

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

VD>Если у сборки нет друзей, то никакой разницы не будет. Да и не ясно зачем прятать константы.

Это называется инкапсуляция. Иногда код прячется не только от сторонних сборок, но и от сторонних классов. Ключевое слово private (а не internal) именно для этого есть в ОО-языках программирования.

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

VD>>Еще раз повторюсь, что мир на тебе не заканчивается. У тебя нет, у других может быть. В прочем, пока что никто не жаловался вроде.

IT>Да уж. Хороший язык Немерле, жаль только, что он попался в руки людям с феноменальными способностями отбивать у других желание его использовать.

IT, ты или по троллить сегодня захотел, или читать разучился. Если последнее, то попробую выразить свою мысль более прямолинейно. Язык не должен быть заточен на прихоти одного конкретного человека. Он должен удовлетворять потребности всех потребителей. И если эти потребности входят в противоречие, то нужно или искать компромисс, или выбирать решения удобные для большинства.

Так понятнее? Если, да, то с чем ты не согласен то?

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

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

VD>>Если у сборки нет друзей, то никакой разницы не будет. Да и не ясно зачем прятать константы.

C>Это называется инкапсуляция. Иногда код прячется не только от сторонних сборок, но и от сторонних классов. Ключевое слово private (а не internal) именно для этого есть в ОО-языках программирования.

Я в курсе как это называется. Но инкапсуляция констант — это и есть дурь. Нечего там инкапсулировать.

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

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

VD>>Еще раз повторюсь, что мир на тебе не заканчивается.

FDS>Да я как раз это и говорю: кто-то считает, что незначительно, а мой опыт говорит об обратном. Для кого-то значительно, а для меня — нет.

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

Да разработчики то как раз по своему опыту и не судят. Лично я давно понял, что мои предпочтения в расчет брать бессмысленно. Я исхожу только из двух факторов — приемлемости для большинства и статистики. Скажем, если кто-то выражает "фэ" по поводу некоторой фичи, то я смотрю на три фактора:
1. Можно ли угодить ему не задев чужих интересов.
2. Насколько выраженное фэ часто встречается на практике.
3. Насколько сложно исправить ситуацию.

Если исправить легко, ничьи интересы не затронуты, то пункт 2 в расчеты может не браться.

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

Да, да. Зачастую лучше послать чувака предлагающего на фиг никому не нужные изменения требующие много работы. И как не странно, это делается исключительно из лучших побуждений. Возможности наши ограничены. И делая что-то мы не делаем что-то другое. Плюс, если изменения, могут навредить кому-то еще, то то тоже не факт, что эти изменения не стоит отвергнуть.

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

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

VD>Так понятнее? Если, да, то с чем ты не согласен то?

С формой.

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

VD>Да разработчики то как раз по своему опыту и не судят. Лично я давно понял, что мои предпочтения в расчет брать бессмысленно. Я исхожу только из двух факторов — приемлемости для большинства и статистики. Скажем, если кто-то выражает "фэ" по поводу некоторой фичи, то я смотрю на три фактора:

Влад, может ты и смотришь на три фактора, но если оценка их тебя не устраивает, то ты начинаешь говорить, что ничего не нужно вне зависимости от того, нужно это или нет. Это очень хорошо видно со стороны.


VD>Зачастую лучше послать чувака предлагающего на фиг никому не нужные изменения требующие много работы.

Зачастую лучше сделать это вежливо и не говоря, что эти изменения никому не нужны. Люди часто просят как раз то, что нужно. А то, что это попросили раз в пять лет, не значит, что нет людей, которые просто свыклись с этим ограничением и не просят, потому что знают, что некий чувак Влад пошлёт всех чуваков подальше.

VD> И как не странно, это делается исключительно из лучших побуждений.

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

VD> Возможности наши ограничены. И делая что-то мы не делаем что-то другое.

Согласен. Дак давай честно говорить, что нет возможностей, а не что "никому не нужно" — это сугобо разные вещи. Может быть не очень нужно, а сделать трудно: это не значит, что никому не нужно, это значит, что сейчас есть значительно более приоритетные направления. А ты постоянно говоришь, что "никому не нужно".

VD>Собственно подобный выбор осуществляют все дизайнеры языков (да и вообще программных систем).
Но они делают это вежливо. Когда я посылаю ошибку в Microsoft, мне не говорят "да вы что, эта структура описана в справке уже десять лет, раз вы первый, кто заметил, значит никому не нужно исправлять эту ошибку". Мне говорят, пожалуйста, в следующем релизе. Не стесняйтесь, приходите ещё.

VD> Я вот объясняю. Впрочем, может, и зря.
Как раз не фига не объясняешь, просто делаешь вид, что объясняешь, т.к. отказать без видимости объяснений твой характер не позволяет.

VD> Глядишь домыслов меньше будет, если делать все молча. Но не в моем это характере.

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

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

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

VD>>>Если у сборки нет друзей, то никакой разницы не будет. Да и не ясно зачем прятать константы.

C>>Это называется инкапсуляция. Иногда код прячется не только от сторонних сборок, но и от сторонних классов. Ключевое слово private (а не internal) именно для этого есть в ОО-языках программирования.

VD>Я в курсе как это называется. Но инкапсуляция констант — это и есть дурь. Нечего там инкапсулировать.

Знаешь, Влад, по-моему у тебя всё дурь: как раз константы инкапсулировать иногда вполне нужно. Лично я делаю это регулярно. Только не говори, что у меня опыта программирования мало. Не нравится, указывай, что эта твоя личная точка зрения и объяснять не хочешь, а не ссылайся на своё личное неопровержимое мнение, что это "дурь" или "никому не нужно".

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

Бездоказательно: это личное мнение для чего ИМЕННО ТЕБЕ требуется инкапсуляция.

Инкапсуляция перечислений избавляет от того, что ты на них смотришь и думаешь: а нафига они здесь, к чему они относятся, где они используются?
Если они в классе и приватные, я знаю, что никому не наврежу, если исправлю как надо и не внесу ошибок именно внутри класса, а если они вне класса, то мне надо уже думать, что и где и не используются ли они вообще вовне сборки.

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

FDS>Влад, может ты и смотришь на три фактора, но если оценка их тебя не устраивает, то ты начинаешь говорить, что ничего не нужно вне зависимости от того, нужно это или нет. Это очень хорошо видно со стороны.

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

С энумами же все просто очевидно. Их нельзя реализовать пока Н генерирует код через SRE. А раз так, то остается только понять насколько это критично. Мой вывод банален. Это вообще не критично, так как легко обходится и не приносит заметного вреда.

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

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

FDS>>Влад, может ты и смотришь на три фактора, но если оценка их тебя не устраивает, то ты начинаешь говорить, что ничего не нужно вне зависимости от того, нужно это или нет. Это очень хорошо видно со стороны.

VD>Нет. Не так.

Нет. Так!

VD>С энумами же все просто очевидно. Их нельзя реализовать пока Н генерирует код через SRE. А раз так, то остается только понять насколько это критично. Мой вывод банален. Это вообще не критично, так как легко обходится и не приносит заметного вреда.

Вот, сразу бы и хотелось слышать что-то подобное: не "никому не нужно", а "некритично и т.п."
Разница очевидна: я объявляю enum очень редко и практически всегда стараюсь его скрыть. Т.е. функциональность такую я использую. Редко-редко, потому что вообще не люблю enum и он мне редко требуется.
Но это действительно не принципиально. Не "не нужно", не "неподнадобится", а именно не принципиально и сложно реализовать.
Это очень большая разница: отказ всё равно даёшь, но верно его аргументируешь.
Грубо говоря, если бы ты по этим трём пунктам провёл публично анализ и вынес решение — к тебе лично от меня точно вопросов бы вообще не было. Но ты этого не сделал и начались споры про инкапсуляцию и т.п., потому что решение принял по трём пунктам, а аргументировать их начал совсем по-другому. Аналогично по вопросу о вычислении типа if.

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

FDS>Знаешь, Влад, по-моему у тебя всё дурь: как раз константы инкапсулировать иногда вполне нужно. Лично я делаю это регулярно. Только не говори, что у меня опыта программирования мало. Не нравится, указывай, что эта твоя личная точка зрения

Любые мои слова не ссылающиеся на других — это моя личная точка зрения. Твои — тоже. Мне кажется — это очевидно.

FDS>и объяснять не хочешь, а не ссылайся на своё личное неопровержимое мнение, что это "дурь" или "никому не нужно".

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

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

Но почему-то ты даже не заикаешься об это, но вот уже какое сообщение поддерживаешь флэйм по поводу реально не значительного недостатка, который к тому же еще и крайне сложно устранить в следствии ошибки в библиотеках МС.

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

FDS>Бездоказательно: это личное мнение для чего ИМЕННО ТЕБЕ требуется инкапсуляция.

Да, нет, батенька. Это общепринятое определение:

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

(с) Википедия

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

В случае же перечислений декларация и реализация — это практически одно и то же. По сему говорить о сокрытии сложности просто не приходится.

FDS>Инкапсуляция перечислений избавляет от того, что ты на них смотришь и думаешь: а нафига они здесь, к чему они относятся, где они используются?
FDS>Если они в классе и приватные, я знаю, что никому не наврежу, если исправлю как надо и не внесу ошибок именно внутри класса, а если они вне класса, то мне надо уже думать, что и где и не используются ли они вообще вовне сборки.

Ой, да ладно. Ты используешь статически типизированный язык. Он и так позволит тебе в лучшем виде узнать где используется константа. На то есть и интеллисенс в IDE, и банальная возможность временно переименовать константу и получить список ее вхождений в виде сообщений об ошибках.

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

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

FDS>Вот, сразу бы и хотелось слышать что-то подобное: не "никому не нужно", а "некритично и т.п."

Да вы батенька педант! (с)

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

FDS>Разница очевидна: я объявляю enum очень редко и практически всегда стараюсь его скрыть. Т.е. функциональность такую я использую. Редко-редко, потому что вообще не люблю enum и он мне редко требуется.

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

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

FDS>Но это действительно не принципиально. Не "не нужно", не "неподнадобится", а именно не принципиально и сложно реализовать.

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

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

FDS>Это очень большая разница: отказ всё равно даёшь, но верно его аргументируешь.
FDS>Грубо говоря, если бы ты по этим трём пунктам провёл публично анализ и вынес решение — к тебе лично от меня точно вопросов бы вообще не было. Но ты этого не сделал и начались споры про инкапсуляцию и т.п., потому что решение принял по трём пунктам, а аргументировать их начал совсем по-другому. Аналогично по вопросу о вычислении типа if.

Таких решений приходится делать море. Если их все разжевывать, то вся оставшаяся жизнь уйдет на объяснения.

Вот лично ты ни разу еще не похвалил язык за что-то, что раньше тебе не встречалось в на практике (например, в шарпе), но постоянно ищешь какие-то поводы покритиковать его и тех кто пытается его развивать. А ведь я даже не автор этого языка. Я взялся за него только потому, что нашел, в свое время, множество действительно ценных возможностей, но при практическом использовании нарвался на горы (для того времени — это правильный, хотя опять таки не педантично-точный эпитет) проблем.

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

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

VD>Но почему-то ты даже не заикаешься об это, но вот уже какое сообщение поддерживаешь флэйм по поводу реально не значительного недостатка, который к тому же еще и крайне сложно устранить в следствии ошибки в библиотеках МС.


Ммм. Погоди, локальные функции в Nemerle есть. Ты ведь об этом? Зачем мне о них заикаться? Я заикаюсь о том, что мне неудобно в Nemerle, т.к. программирую на нём, а не что неудобно в других языках.
В том-то и дело, что Немерле настолько удобен, что ради одних вложенных функций, частичного применения и вывода типом, можно уже на нём начинать программировать. Именно так, как хочется мне, а не кому-то ещё. Я вижу основное достоинство этого языка именно в этом.

FDS>>Бездоказательно: это личное мнение для чего ИМЕННО ТЕБЕ требуется инкапсуляция.

VD>Да, нет, батенька. Это общепринятое определение:
VD>

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

А, вот как раз общепринятое определение тут подходит к моему мнению, а вот то, что ты сказал изначально — нет. Есть сложность реализации и сокрытие, а есть избавление от ошибок. Ты сказал про избавление от ошибок, а вот про сложность и её сокрытие — нет.
[тебе ещё не надоело спорить? Мне уже да]

VD>В случае же перечислений декларация и реализация — это практически одно и то же. По сему говорить о сокрытии сложности просто не приходится.

Приходится: у меня появляется вне типа некоторый Enum, который никому не нужен и просто так болтается. Или он нужен, и мне его приходится искать в выпадающем списке членов namespace вместо выпадающего списка класса (последнее всегда легче).

FDS>>Инкапсуляция перечислений избавляет от того, что ты на них смотришь и думаешь: а нафига они здесь, к чему они относятся, где они используются?
FDS>>Если они в классе и приватные, я знаю, что никому не наврежу, если исправлю как надо и не внесу ошибок именно внутри класса, а если они вне класса, то мне надо уже думать, что и где и не используются ли они вообще вовне сборки.

VD>Ой, да ладно. Ты используешь статически типизированный язык. Он и так позволит тебе в лучшем виде узнать где используется константа. На то есть и интеллисенс в IDE, и банальная возможность временно переименовать константу и получить список ее вхождений в виде сообщений об ошибках.

Влад, я же специально написал: "используется ли они вообще вовне сборки". Внутри сборки — да, а вовне чёрт знает, где там что используется.
К тому же, одно дело, выполнять поиск по проекту, а другое дело, просто увидеть, что всё скрыто. Мне гораздо легче на душе становится, когда всё, что нужно пользователю , сокрыто.

VD>Единственная реальная ошибка которая может возникнуть при использовании перечислений — это попытка манипулировать их значениями в целочисленном виде.

1. Не единственная. Я могу поменять enum в использующей сборке. А если учесть, что вся группа проектов перекомпилируется не всегда, то я даже сразу не узнаю, что у клиентского кода enum этот где-то использовался. Вот будет кому-то радость, когда он скомпилирует (кстати, аналогичные случаи, правда не с Enum, у нас на одной из работ бывали постоянно)
2. Дело не только в ошибках.
2.1. Мне легче искать Enum, вложенный в нужный класс, чем Enum, болтающийся меж пары десятков других классов в namespace
2.2. Мне легче понять по коду, для чего нужен этот Enum, если он внутри класса (я знаю, что это основной его пользователь, а не какой-то другой рядом находящийся класс). Если же он снаружи, то я могу думать, что этот Enum вообще может быть объявлен для использования в другом классе или сборке специально и умышленно вынесен из объявления класса.

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

VD>Да вы батенька педант! (с)

Да, ты ещё не знаешь какой

VD>Когда я говорил никому не нужно, то имел в виду, что не было ни одной жалобы. Можешь расценивать — это как "никому из тех кто использовал язык на практике не было нужно".

Вот в этом всё и дело, что "не было ни одной жалобы" сначала превращается в "никому не было нужно", а затем говориться "что это вообще не нужно"
Таким образом делается две ошибки:
1. Отсутствие жалоб приравнивается к отсутствию проблемы. Это грубейшая ошибка, особенно когда жаловаться можно много (люди часто просто перестают жаловаться вообще, хотя жалоб может быть много и разработчики их, в общем-то, исправляют).
2. То, что никому это не потребовалось воспринимается как отсутствие необходимости (т.е. отсутствие необходимости в будущем, когда расширится список пользователей или расширится само сознание пользователей)

Поэтому "никому не нужно" лучше вообще никогда не говорить. Обычно если пользователь знает, что "никому не нужно" он даже тему поднимать не будет (с тем же new я поднял тему исключительно по причине того, что хотел разобраться, как отличить одно от другого; хотя в целом, конечно, хорошо, что бага исправлена)

FDS>>Разница очевидна: я объявляю enum очень редко и практически всегда стараюсь его скрыть. Т.е. функциональность такую я использую. Редко-редко, потому что вообще не люблю enum и он мне редко требуется.

VD>К теме не относится, но само по себе показательно. Я бы назвал это извращенным пониманием энумов. Лично я (и надеюсь большинство программистов) использую энуму в основном в интерфейсе типов для выражения доменов значений.

Э, собственно я тоже использую для выражения классов некоторого множества. Только вот мне обычно приходится использовать их внутри типа в реализации, а не вовне. Да и даже если вовне, я бы предпочёл сделать Enum подтипом.

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

К сожалению, Влад, вариантный тип тоже нельзя объявить в шаблонном классе.

Кстати, обрати внимание на то, что в модуле Getopt nemerle_repository\lib определён вложенный вариант CliOption, в модуле TwoThreeTree определены вложенные перечисления и варианты InsertOptions, DeleteOptions, Node[T]; в классе Test.Expressions определено вложенное перечисление TestEnum .

Всё это в проекте Nemerle. Естественно, всё это вовне шаблонных типов (т.к. компилятор иначе не позволяет), однако, как видишь, вложенные перечисления и варианты вполне используются.

FDS>>Но это действительно не принципиально. Не "не нужно", не "неподнадобится", а именно не принципиально и сложно реализовать.

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

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

VD>А то всей жизни ведь не хватит, чтобы выразить своем мнение для педанта.

Да брось, наоборот, часто внимательное отношение к формулировкам в их сути экономит такую кучу времени, что можно даже заняться созданием справочника корректных формулировок

FDS>>Это очень большая разница: отказ всё равно даёшь, но верно его аргументируешь.
FDS>>Грубо говоря, если бы ты по этим трём пунктам провёл публично анализ и вынес решение — к тебе лично от меня точно вопросов бы вообще не было. Но ты этого не сделал и начались споры про инкапсуляцию и т.п., потому что решение принял по трём пунктам, а аргументировать их начал совсем по-другому. Аналогично по вопросу о вычислении типа if.

VD>Таких решений приходится делать море. Если их все разжевывать, то вся оставшаяся жизнь уйдет на объяснения.

Тогда лучше вообще ничего не говорить, чем говорить неверно.
Представляешь себе, если артиллерист скажет, что "у меня море целей, если я буду заботиться о точности попадания, то вся жизнь уйдёт на пристрелку"? Думаю, никому не хотелось бы оказаться рядом с таким воякой.
От неверных формулировок иногда очень много очень трудно выявляемых проблем.

VD>Вот лично ты ни разу еще не похвалил язык за что-то, что раньше тебе не встречалось в на практике (например, в шарпе),
Влад, ну нафига мне его хвалить? И, кстати, хвалил. Искать лень, но думаю, если поискать сообщения в этой теме года так 2007 то вполне найдётся.
По-моему, достаточно того, что я этим языком пользуюсь и интересуюсь (скажем, хаскелем я даже не интересуюсь).

VD>но постоянно ищешь какие-то поводы покритиковать его и тех кто пытается его развивать.

С чего ты взял? Я лишь говорю о недостатках, пытаясь сделать свою среду разработки комфортной. Что касается критики людей, его развивающих, то, мне кажется, она по-делу (я и не помню, чтобы критиковал кого-то, кроме тебя ). Ты ведь и сам часто говоришь о кривом дизайне: тоже критикуешь поляков (и не ты один).
А то что находятся такие выкрутасы, как с @new и new() : извини, это моя специальность — качество ПО, это уже получается само собой, кроме этого, я просто хотел разобраться, как отличить такую ситуацию (в отличие от разработчиков Nemerle, которые этим вопросом не задавались ).

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

Да, к сожалению, я уже третий или четвёртый раз пытаюсь заняться этим языком, и только сейчас вижу, что что-то у него начало получаться (но и C# не стоит на месте) и с ним можно работать.

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

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

Зачем параметризировать нечто формально, что не параметризируется по сути? Объяви недженерик-класс, в нем определи enum и уже от него наследуй свой дженерик. Я бы сделал так.