О возможности обращаться к статическим членам через ссылку - Nemerle

_C_>это следствие C# мышления. для любого программиста, минувшего С# доступ через экземпляр к статике —
_C_>и не ошибка и не грех, а вполне заурядная вещь.

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

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

VD>>Вот тема демонстрирующая почему это правильное решение.

_C_>это следствие C# мышления. для любого программиста, минувшего С# доступ через экземпляр к статике —
_C_>и не ошибка и не грех, а вполне заурядная вещь.

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

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

Если отвлечься от конкретного момента, то у нас спор-дискуссия о сложностяж-длительностях обряда. и ты готов обсуждать уменьшение сложности,
но не готов усомниться в целесообразности оного вообще. Если мы посмотрим на тенденцию языкостроения, но увидим два отчетливых тренда,
строгие языки стремятся к расслаблению, расслабленные к строгости. это не спроста и вытекает из существования двух плохо сочетаемых потребностей
— быстрого прототипирования и точного описания. в гугло-Dart изначально зашита идея их сращивания и поэтому в будущем это будет реально серьезный конкурент.
что противопоставить взамен? против режима быстрого прототипирования — ничего кроме него самого. поэтому всякие строгости / непонятности,
которые тянутся из .net, c#, ... должны быть отключаемы в режиме, в котором будет работать половина или большинство. это у тебя большинство программ создается для показа /использования программистами, поэтому соблюдение всех канонов вполне обосновано. большинство же создает программы для конкретных нужд, где лишняя писанина и понимание глубоких вещей только мешает и отвлекает. вспомним идеи вирта, которые являются следствием бритвы Оккама, и опционально без необходимости не будем требовать усложнения. в будущем, разумеется.

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

_C_>строгие языки стремятся к расслаблению, расслабленные к строгости. это не спроста и вытекает из существования двух плохо сочетаемых потребностей

Это C# чтоли? Так они dynamic по сути для простого COM-интеропа прикрутили и паритета с фичей VB.NET.

_C_>>строгие языки стремятся к расслаблению, расслабленные к строгости. это не спроста и вытекает из существования двух плохо сочетаемых потребностей

H>Это C# чтоли? Так они dynamic по сути для простого COM-интеропа прикрутили и паритета с фичей VB.NET.

для с# добавили кроме dynamic добавляли автовывод типов и LINQ, а то что внутри оно строго, как мы знаем, это ничего,
снаружи стало менее строго ( = меньше писать).

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

_C_>для с# добавили кроме dynamic добавляли автовывод типов и LINQ, а то что внутри оно строго, как мы знаем, это ничего,
_C_>снаружи стало менее строго ( = меньше писать).

Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.

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

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

_C_>>для с# добавили кроме dynamic добавляли автовывод типов и LINQ, а то что внутри оно строго, как мы знаем, это ничего,
_C_>>снаружи стало менее строго ( = меньше писать).

H>Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.

Какая разница прикладному программисту Какая типизация если он Просто пишет

def a=1

Здравствуйте, Аноним, Вы писали:

А>Какая разница прикладному программисту Какая типизация если он Просто пишет

А>def a=1

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

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

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

H>Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.

В случае _Claus_ проблема, видимо, в том, что его понятие о выводе типов ассоциируется с Бу. А в нем вывод типов вещь весьма условная, так как в случае неудачи Бу переходит на динамику.

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

C>Здравствуйте, Аноним, Вы писали:

А>>Какая разница прикладному программисту Какая типизация если он Просто пишет

А>>def a=1

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

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

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

Здравствуйте, Аноним, Вы писали:

А>круто но для программиста который пишет без ошибок понятный код пофиг. Диномический в принципе эквивалентнен полиморфизму высшего порядка

Все прекрасно до тех пор пока не потребуется изменить программу на динамически типизированном языке.

H>>Извини, но написан какой-то бред. Я рекомендую изучить простую классификацию "типизации": статическая/динамическая, слабая/строгая. Вывод типов не делает строгую типизацию менее строгой — он просто работает.

Мое утверждения о стремлении строгих языков к расслаблению подразумевает в случае С# и опциональную динамику, и упрощения с типами, и LINQ.
Если это все не упрощения (уменьшение нужного кода для программы, уменьшение требований и знаний к программисту) — тогда я конный полицай. И доказываю я то, что упрощения, опциональные хотя бы, полезны. не надо их бояться. сложные языки рано или поздно вымирают, не оставив потомков, если не находят способа быть проще. если для H2 будет возможно написать систему макросов, эмулирующую CoffeeScript, больше никому ничего не придется доказывать,
что Н- лучший, у вас на руках будет то, чего никто, никогда не сможет ни оспорить, ни замолчать.

VD>В случае _Claus_ проблема, видимо, в том, что его понятие о выводе типов ассоциируется с Бу. А в нем вывод типов вещь весьма условная, так как в случае неудачи Бу переходит на динамику.

это не так. Бу переходит на динамику, если метод или поле в объекте не обнаружено и а) объект имеет динамик-интерфейс или б) глобально установлен флаг,
все объекты трактующий как динамик.

Здравствуйте, Аноним, Вы писали:

А>круто но для программиста который пишет без ошибок понятный код пофиг.

То есть для Идеального Программиста? Ну-ну.

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

_C_>Мое утверждения о стремлении строгих языков к расслаблению подразумевает в случае С# и опциональную динамику, и упрощения с типами, и LINQ.

Это следствие использования неверной терминологии.

Все эти "расслаблению", "упрощения" — это все выдуманные тобой термины смысл которых ты и сам не можешь четко сформулировать.

_C_>Если это все не упрощения (уменьшение нужного кода для программы, уменьшение требований и знаний к программисту) — тогда я конный полицай.

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

_C_>И доказываю я то, что упрощения, опциональные хотя бы, полезны.

Определись с тем что ты понимаешь под упрощением. Думаю, что под этим термином скрывается — повышение гибкости.

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

Можно не значит нужно.

У Немерла есть проблемы и мы их знаем. Но это никак не строгость типизации или отсутствие багофич к которым привыкли пользователи хреново спроектированных языков.

VD>>В случае _Claus_ проблема, видимо, в том, что его понятие о выводе типов ассоциируется с Бу. А в нем вывод типов вещь весьма условная, так как в случае неудачи Бу переходит на динамику.

_C_>это не так. Бу переходит на динамику, если метод или поле в объекте не обнаружено

Ну, да. А это любая ошибка в коде. Плюс еще есть "б)", "в)", "г)" и т.п. Вот пример с неявным даункастом очень характерен.

Такого "расслабления" нам не надо.

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

VD>Такого "расслабления" нам не надо.
VD>Вот внятный АПИ для макросов, качественные сообщения компилятора, гибкость синтаксического расширения.

тогда вот об этом нужно забыть —

В качестве внешних DSL-ей смогут выступать не только простейшие HTML/XML, но даже полноценные языки программирования вроде VB, Delphi или C#. При этом
для внешних DSL-ей будет обеспечена автоматическая поддержка IDE (подсветка, подсказки и т.п.).

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

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

_C_>тогда вот об этом нужно забыть -
_C_>

_C_> В качестве внешних DSL-ей смогут выступать не только простейшие HTML/XML, но даже полноценные языки программирования вроде VB, Delphi или C#. При этом
_C_>для внешних DSL-ей будет обеспечена автоматическая поддержка IDE (подсветка, подсказки и т.п.).

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

Ну почему же? Просто типизацию нужно будет писать свою. Если Немерле2-тим осилит и сделает DSL для типизации, то это будет даже несложно.

C>Ну почему же? Просто типизацию нужно будет писать свою. Если Немерле2-тим осилит и сделает DSL для типизации, то это будет даже несложно.

этого мало. нужен встроенный механизм перехвата управления/разрешения ситуаций, где N-логика не подходит.
например
неизвестный метод -> обработка
неизвестная переменная -> ..
передается не тот тип -> ..
...
логики макросов мало, нужен контроль над поведением компилятора. если его не продумать, то

По сути, Nemerle 2.0 будет фрэймворком для разработки новых языков.

хорошо не получится. а если не хорошо, то смысла мало — кода много. мне это нужно для дела, поэтому такой нудный.

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

_C_> логики макросов мало, нужен контроль над поведением компилятора. если его не продумать, то

Семантика кода определяется тем как он типизируется и тем как код преобразуется в более низкоуровневый код. Как тебе правильно заметил catbert в N2 будет декларативная система типизации которая позволит задать ту логику которая будет нужна.

_C_>

_C_>По сути, Nemerle 2.0 будет фрэймворком для разработки новых языков.

_C_>хорошо не получится. а если не хорошо, то смысла мало — кода много. мне это нужно для дела, поэтому такой нудный.

Давай ты не будешь высказывать общие суждения пока не разберешься в предмете? И вообще, общие суждения они мало толку несут.

Пойми на общие суждения крайне сложно отвечать. Можно только ответить — "ты не прав". Тебя такой ответ устроит?

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

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

_C_>> логики макросов мало, нужен контроль над поведением компилятора. если его не продумать, то

VD>Семантика кода определяется тем как он типизируется и тем как код преобразуется в более низкоуровневый код. Как тебе правильно заметил catbert в N2 будет декларативная система типизации которая позволит задать ту логику которая будет нужна.

_C_>>

_C_>>По сути, Nemerle 2.0 будет фрэймворком для разработки новых языков.

_C_>>хорошо не получится. а если не хорошо, то смысла мало — кода много. мне это нужно для дела, поэтому такой нудный.

VD>Давай ты не будешь высказывать общие суждения пока не разберешься в предмете? И вообще, общие суждения они мало толку несут.

VD>Пойми на общие суждения крайне сложно отвечать. Можно только ответить — "ты не прав". Тебя такой ответ устроит?

N2 будет декларативная система типизации. можно подробности?

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

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

VD>Вот тема демонстрирующая почему это правильное решение.

Вообще мне кажется что обращаться к членам принадлежащим типу (статические), концептуально возможно обращаться через ссылку на экземпляр, так было в С++. Потому как экземпляр имеет явное родство с типом к которому он принадлежит и обратиться к статическому члену через ссылку не должно давать сложностей, это наоборот упростит операцию доступа к члену.

То было бы так:

SomeSmartType.Member

а то так:

obj.Member

Вопрос только в реализации, это надо реализовывать.

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

CU>Вообще мне кажется что обращаться к членам принадлежащим типу (статические), концептуально возможно обращаться через ссылку на экземпляр, так было в С++.

А как быть в случае, если ссылка на экземпляр получается в результате некоторого вычисления?
Выбрасываем вычисление или оставляем на всякий случай (побочные эффекты и все такое)?

F().StaticMember

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

H>А как быть в случае, если ссылка на экземпляр получается в результате некоторого вычисления?
H>Выбрасываем вычисление или оставляем на всякий случай (побочные эффекты и все такое)?

H>F().StaticMember

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

def obj = F();
obj.StaticMember

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

H>А как быть в случае, если ссылка на экземпляр получается в результате некоторого вычисления?
H>Выбрасываем вычисление или оставляем на всякий случай (побочные эффекты и все такое)?

H>F().StaticMember

Здесь важно понять, что для доступа к статическому члену объект не нужен, поэтому он должен оптимизироваться компилятором, как если бы мы создали переменную, но ее не использовали.

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

CU>Конечно выбрасываем, такая запись означает тоже если бы обращались к статическому методу через тип. Тот кто пишет такой код, должен будет осознать, что так нельзя обращаться к статическим полям, пытаясь еще получить какой то эффект.

Т.е. вызывая метод я буду не уверен что будет ли вообще this-ссылка вычисляться? Это потенциальный багодром. Вот потому и запрещены вызовы статических методов у экземпляров. Если ты хочешь дергать статические методы как экземплярные — то этот механизм есть у нас, называется Extension Methods.

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

H>Т.е. вызывая метод я буду не уверен что будет ли вообще this-ссылка вычисляться? Это потенциальный багодром. Вот потому и запрещены вызовы статических методов у экземпляров. Если ты хочешь дергать статические методы как экземплярные — то этот механизм есть у нас, называется Extension Methods.

Можно быть уверенным что this ссылка не будет вычисляться, потому что для вызова статического метода она не нужна. Extension Methods не для того чтобы использовать статические методы как экземплярные, это механизм расширения экземплярных методов за счет статических внешних. В нем есть параметр со ссылкой, это другой случай и этот параметр явно передается. В обычных же статических методах this ссылка не нужна, если где то в коде написано что вызывается на объекте статический метод, то сам объект не используется, только тип. Но чтобы это реализовать правильно, не допуская потенциальных багов, сделать непросто.

Здравствуйте, Аноним, Вы писали:

А>N2 будет декларативная система типизации. можно подробности?

Описания пока нет.

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

CU>Можно быть уверенным что this ссылка не будет вычисляться, потому что для вызова статического метода она не нужна.

Как ты визуально (просматривая код) отличишь вызов статического метода от метода экземпляра? Скажи на милость, зачем заставлять программиста на ровном сомневаться в том, что выражение слева от точки может быть просто выброшено компилятором?

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

CU>>Можно быть уверенным что this ссылка не будет вычисляться, потому что для вызова статического метода она не нужна.

H>Как ты визуально (просматривая код) отличишь вызов статического метода от метода экземпляра? Скажи на милость, зачем заставлять программиста на ровном сомневаться в том, что выражение слева от точки может быть просто выброшено компилятором?

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

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

_C_>это следствие C# мышления. для любого программиста, минувшего С# доступ через экземпляр к статике —
_C_>и не ошибка и не грех, а вполне заурядная вещь.

А что полезного даёт такая возможность? Лично я, в силу своей c#-закостенелости, ничего, кроме дополнительных возможностей для ошибки не вижу.

class Foo
{
    public static mutable Field : int;
}

main() : void
{
    def foo1 = Foo();
    def foo2 = Foo();
    foo1.Field = 1;
    foo2.Field = 2;
    when (foo1.Field == foo2.Field)
        throw Exception("Что за хрень?...");
}

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

С другой стороны, если сделать так:

class Foo
{
    public mutable Field : int;
}

main() : void
{
    def foo1 = Foo();
    def foo2 = foo1;
    foo1.Field = 1;
    foo2.Field = 2;
    when (foo1.Field == foo2.Field)
        throw Exception("Что за хрень?...");
}

то получаем аналогичный результат. Иммутабельные объекты рулят!

Mumitroller

... << RSDN@Home 1.2.0 alpha 4 rev. 0>>

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

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

Можно пример, когда это может быть полезно?

Mumitroller

... << RSDN@Home 1.2.0 alpha 4 rev. 0>>

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

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

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

M>Можно пример, когда это может быть полезно?

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

M>А что полезного даёт такая возможность? Лично я, в силу своей c#-закостенелости, ничего, кроме дополнительных возможностей для ошибки не вижу.

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

пишем пример для новичка:

a = MyComplexObject()

a. z(..)

a. x = 5

a.d = 25 //нельзя !!! d — static

MyComplexObject.d = 25 //только так — забудь что думал до этого и запомни навсегда!!!

_C_> со ссылкой дело имеем или с классом

update:

со ссылкой дело имеем или с структурой

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

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

В этом случае нужно что-то вроде оператора typeof.

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

M>>А что полезного даёт такая возможность? Лично я, в силу своей c#-закостенелости, ничего, кроме дополнительных возможностей для ошибки не вижу.

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

_C_>пишем пример для новичка:

_C_>a = MyComplexObject()
_C_>a. z(..)
_C_>a. x = 5
_C_>a.d = 25 //нельзя !!! d — static
_C_>MyComplexObject.d = 25 //только так — забудь что думал до этого и запомни навсегда!!!

Ну так и отлично — совершенно чётко видно, что это глобальная переменная, а не поле экземпляра класса! Лично для меня это только облегчает чтение и понимание кода. Так в чём всё-таки полезность такой фичи? В каких случаях она может помочь?

Mumitroller

... << RSDN@Home 1.2.0 alpha 4 rev. 0>>

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

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

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

C>В этом случае нужно что-то вроде оператора typeof.

Согласен, в таком случае применение некоего подобия typeof выглядит логичнее. Однако, сама фича для меня всё ёще выглядит вредной — ведь при чтении кода каждый раз придется разбираться на что именно ссылается такое выражение. Нафиг-нафиг — лучше уж один раз написать абсолютно понятную ссылку (пусть даже и поднапрягшись, чтобы вспомнить большое и кудрявое имя типа) и больше не заморачиваться.

Mumitroller

... << RSDN@Home 1.2.0 alpha 4 rev. 0>>

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

C>В этом случае нужно что-то вроде оператора typeof.

typeof в .net возвращает экземпляр Type, сам тип так не получить, придется изгаляться.

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

M>Согласен, в таком случае применение некоего подобия typeof выглядит логичнее. Однако, сама фича для меня всё ёще выглядит вредной — ведь при чтении кода каждый раз придется разбираться на что именно ссылается такое выражение. Нафиг-нафиг — лучше уж один раз написать абсолютно понятную ссылку (пусть даже и поднапрягшись, чтобы вспомнить большое и кудрявое имя типа) и больше не заморачиваться.

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

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

C>>В этом случае нужно что-то вроде оператора typeof.

CU>typeof в .net возвращает экземпляр Type, сам тип так не получить, придется изгаляться.

Это понятно, что typeof для этого не подойдет. Речь шла о новом похожем операторе (что-то вроде typerefof), который в compile-time будет вычислять класс и подставлять его вместо выражения. У меня есть ничем не обоснованное интуитивное предположение, что это можно сделать макросом, то есть желающие могут попробовать добавить фичу самостоятельно. Пусть знатоки меня поправят, если это принципиально невозможно.

Mumitroller

... << RSDN@Home 1.2.0 alpha 4 rev. 0>>

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

M>>А что полезного даёт такая возможность? Лично я, в силу своей c#-закостенелости, ничего, кроме дополнительных возможностей для ошибки не вижу.

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

Для свойства, поля, виртуального вызова вычисление self-ссылки необходимо. Для обращения к статическому члену — нет. Зачем позволять программисту писать код который заведомо не будет исполняться, либо будет, но результат его исполнения не будет никак использоваться? Кстати говоря, второй случай компилятор отлавливает и заставляет программиста писать следующую идиому: _ = expr(). Выходит что для когерентности нынешнему поведению нужно будет для всех статических вызовов с экземпляром кидать предупреждение? Т.е. по сути мы будем требовать от программиста явно писать обращение к статическим членам используя класс?

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

H>Зачем позволять программисту писать код который заведомо не будет исполняться, либо будет, но результат его исполнения не будет никак использоваться?

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

H>>Зачем позволять программисту писать код который заведомо не будет исполняться, либо будет, но результат его исполнения не будет никак использоваться?

H>И при том маскировать его под код, исполнение которого совершенно необходимо для продолжения вычисления.

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

От:	VladD2	www.nemerle.org
Дата:	09.12.11 22:15
Оценка:

	От:	catbert
	Дата:	10.12.11 08:16
	Оценка:

	От:	_Claus_
	Дата:	10.12.11 12:03
	Оценка:

	От:	_Claus_
	Дата:	10.12.11 12:15
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	10.12.11 13:15
Оценка:

От:	hardcase	http://nemerle.org
Дата:	10.12.11 19:50
Оценка:

	От:	Аноним
	Дата:	11.12.11 09:38
	Оценка:	-2

	От:	Аноним
	Дата:	13.12.11 07:10
	Оценка:

	От:	CodingUnit
	Дата:	13.12.11 10:07
	Оценка:

	От:	CodingUnit
	Дата:	13.12.11 11:05
	Оценка: