Здравствуйте, _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>Вот тема

Автор:
Дата: 09.12.11

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

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

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

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

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

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

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

Mumitroller

Здравствуйте, 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

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

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

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

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

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

Mumitroller

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

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

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