Да, первая как в C#. Можно перекрыть, скажем, поле класса переменной внутри метода, но внутри самого метода перекрытия недопустимы.
Кстати, в мире дотнета альтернативный подход представляет Немерле — там код второго вида компилируется. И например для match-ей такой подход кажется очень даже правильным:
def z = match(exp) {
| Cons(x) => ...
...
};
Если бы скопинг был как в шарпе, то было бы неясно, что такое x — она объявляется внутри блока вхождения match-а, или это "внешняя" переменная. И если это внешняя переменная, то используется ее значение, а если нет — то объявляется новая? Короче, как-то неочевидно.
С другой стороны, в шарпе в свое время убрали шейдинг как бы из соображений читабельности и безопасности.
ВВ>>>var x = 0;
ВВ>>>{
ВВ>>> var x = 2; //ОК, variable x in parent block is shaded
ВВ>>>}
ВВ>>>
VD>>Что значит "is shaded"?
Q>Это значит, что внешняя переменная сокрыта «в тени» одноимённой переменной внутреннего блока. (Ваш Кэп.)
Если бы она была неизменяемой, то еще куда не шло. А для изменяемой это может привести к проблемам. С этим дизайнеры шарпа намеренно боролись (еще в первой версии).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если бы она была неизменяемой, то еще куда не шло. А для изменяемой это может привести к проблемам. С этим дизайнеры шарпа намеренно боролись (еще в первой версии).
Здравствуйте, VladD2, Вы писали:
Q>>Это значит, что внешняя переменная сокрыта «в тени» одноимённой переменной внутреннего блока. (Ваш Кэп.)
VD>Если бы она была неизменяемой, то еще куда не шло. А для изменяемой это может привести к проблемам. С этим дизайнеры шарпа намеренно боролись (еще в первой версии).
Что-то я к вечеру пятницы соображаю туговато... А какие могут быть проблемы? При чём тут изменяемость? Изменяемость — это категория времени выполнения, а shading — времени компиляции. В C++ можно скрывать переменные.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
VD>>Если бы она была неизменяемой, то еще куда не шло. А для изменяемой это может привести к проблемам. С этим дизайнеры шарпа намеренно боролись (еще в первой версии).
ВВ>Можно пример таких проблем?
Было:
var x = 1;
{
... много кода
x++;
}
Стало:
var x = 1;
{
... много кода
var x = 2;
... много кода
x++;
}
и ранее работавший код перестает работать корректно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Если бы она была неизменяемой, то еще куда не шло. А для изменяемой это может привести к проблемам. С этим дизайнеры шарпа намеренно боролись (еще в первой версии).
Вообще было бы интересно, если бы рассказал, какие были причины для введения именно второго варианта (с перекрытием) в Немерле, когда вот создатели Шарпа сочли его опасным. (Я подозреваю, что это может быть косвенно связано с матчем).
И наконец какие все же могут быть потенциальные проблемы у кода:
mutable x = 0;
_ = x;
{
mutable x = 1;
_ = x;
}
Который компилируется, но при этом выдает ворнинг (если заменить на def, ворнингов нет).
Здравствуйте, VladD2, Вы писали:
ВВ>>Можно пример таких проблем? VD>Было: VD>
VD>var x = 1;
VD>{
VD> ... много кода
VD> x++;
VD>}
VD>
VD>Стало: VD>
VD>var x = 1;
VD>{
VD> ... много кода
VD> var x = 2;
VD> ... много кода
VD> x++;
VD>}
VD>
VD>и ранее работавший код перестает работать корректно.
А как от этого защищает иммутабельность? Пример с инкрементом ты можешь заменить на любой другой код, не создающий побочных эффектов, но использующий значение x, и этот код также перестанет работать корректно.
Здравствуйте, Qbit86, Вы писали:
Q>Что-то я к вечеру пятницы соображаю туговато... А какие могут быть проблемы? При чём тут изменяемость? Изменяемость — это категория времени выполнения, а shading — времени компиляции. В C++ можно скрывать переменные.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А как от этого защищает иммутабельность? Пример с инкрементом ты можешь заменить на любой другой код, не создающий побочных эффектов, но использующий значение x, и этот код также перестанет работать корректно.
Василий, почему вы постите мои комменты? Только я его подумал, а вы его уже напечатали. Некрасиво чужие комменты постить!
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вообще было бы интересно, если бы рассказал, какие были причины для введения именно второго варианта (с перекрытием) в Немерле, когда вот создатели Шарпа сочли его опасным.
А как я могу за других людей что-то рассказывать?
Потом изменяемые переменные в Nemerle тоже выдают предупреждения (правда только предупреждения) при их перекрытии. Так что, если предупреждения не игнорировать, то грабли исключены.
Я могу только предположить. Nemerle наследник ML не в меньшей мере нежели C#-а. Неизменяемые переменные пришли оттуда. Точнее оттуда пришла конструкция def (там она называлась let).
def определяет новую сущность в месте объявления. Это справидливо не только для переменных, но и для функций. Как побочный эффект — это приводит к невозможности создания перегруженных локальных функций.
На практике это довольно удобно. Но есть одна проблема. Мы так и не смогли качественно представить переименованные переменные в отладчике и с ними иногда бывают проблемы (нельзя узнать их значения).
ВВ>(Я подозреваю, что это может быть косвенно связано с матчем).
В какой-то мере наверно — да. Только вряд ли match стал причиной чего-то. Это целостный дизайн. Дизайн ML-я. В нем уже были и match и def (let) и локальные функции и многое другое.
Дизайн немерла потому и хорош (в отличии, например, от С++ или Ди), что он сводит воедино две уже неплохо до этого проработанные концепции. Все что оставалось авторам — это увидеть ошибки авторов раодительских языков и попытаться избежать их.
ВВ>И наконец какие все же могут быть потенциальные проблемы у кода: ВВ>
ВВ>mutable x = 0;
ВВ>_ = x;
ВВ>{
ВВ> mutable x = 1;
ВВ> _ = x;
ВВ>}
ВВ>
ВВ>Который компилируется, но при этом выдает ворнинг (если заменить на def, ворнингов нет).
Ну так выдает же?
ЗЫ
Ты я смотрю решил изучить Немерле и по ходу выдаешь свое обозрение его дизайна. Это конечно похвально, но уверяю тебя, что твое мнение будет несколько более объективно, если ты прежде попробуешь язык на практике. Уверяю тебя, что большая часть вопросов отпадет сама собой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Вообще было бы интересно, если бы рассказал, какие были причины для введения именно второго варианта (с перекрытием) в Немерле, когда вот создатели Шарпа сочли его опасным. VD>А как я могу за других людей что-то рассказывать?
А ты разве не задавал им "неправильные вопросы"?
VD>На практике это довольно удобно. Но есть одна проблема. Мы так и не смогли качественно представить переименованные переменные в отладчике и с ними иногда бывают проблемы (нельзя узнать их значения).
Кстати, интересный вопрос. Я так понимаю — они сейчас просто не показываются? Т.е. если x в дочернем скопе перекрывает x в родительском скопе, то значение родительского x видно не будет.
ВВ>>(Я подозреваю, что это может быть косвенно связано с матчем). VD>В какой-то мере наверно — да. Только вряд ли match стал причиной чего-то. Это целостный дизайн. Дизайн ML-я. В нем уже были и match и def (let) и локальные функции и многое другое.
Сейчас мне начинает казаться, что вариант с перекрытием все же более логичный что ли. Mr. Cat тут приводил ссылку на запись в блоге Липперта:
for (var m in from m in list select m) {}
Понятно, *почему* такой код работает, но ведь с т.з. пользователя тут не создается никаких функций и это выглядит так, как если бы некоторые лексические блоки были "более равны" чем другие.
Аналогично и с match. Match, на мой взгляд, конструкция, которой очень нужен лексический скоп, именно перекрывающий родительский. Причем каждому вхождению match-а. Вместо того, чтобы вводить match как некий "особенный" лексический скоп, имеющий больше прав, чем какой-нибудь if, вполне логично сделать все блоки перекрывающими.
Пока вот у меня складывается такое мнение.
ВВ>>Который компилируется, но при этом выдает ворнинг (если заменить на def, ворнингов нет). VD>Ну так выдает же?
Выдает, но непонятно, чем опасна именно мутабельность переменных. Ведь на def он не выдает. По твоему примеру, честно, это непонятно.
VD>Ты я смотрю решил изучить Немерле и по ходу выдаешь свое обозрение его дизайна. Это конечно похвально, но уверяю тебя, что твое мнение будет несколько более объективно, если ты прежде попробуешь язык на практике. Уверяю тебя, что большая часть вопросов отпадет сама собой.
Нет, эти вопросы напрямую не связаны с Немерле. Просто он тут под руку все время подворачивается. На самом деле я пишу свой интерпретатор
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А ты разве не задавал им "неправильные вопросы"?
А зачем задавать вопросы относительно того что меня и так устраивает?
ВВ>Кстати, интересный вопрос. Я так понимаю — они сейчас просто не показываются? Т.е. если x в дочернем скопе перекрывает x в родительском скопе, то значение родительского x видно не будет.
У неизменяемых? Если определены в одной области видимости, то новая переменная полностью скрывает старую. Если во вложенной, то только до выхода из вложенности.
ВВ>Сейчас мне начинает казаться, что вариант с перекрытием все же более логичный что ли. Mr. Cat тут приводил ссылку на запись в блоге Липперта:
ВВ>
ВВ>for (var m in from m in list select m) {}
ВВ>
А это как раз пример где переменная не изменяемая. "from m in list select m" — это порождающий код. Его можно рассматривать как функцию.
ВВ>Понятно, *почему* такой код работает, но ведь с т.з. пользователя тут не создается никаких функций и это выглядит так, как если бы некоторые лексические блоки были "более равны" чем другие.
Я в этом тоже виноват? Или мне нужно было спросить о причинах у Липперта или Меерса?
ВВ>Аналогично и с match. Match, на мой взгляд, конструкция, которой очень нужен лексический скоп, именно перекрывающий родительский. Причем каждому вхождению match-а. Вместо того, чтобы вводить match как некий "особенный" лексический скоп, имеющий больше прав, чем какой-нибудь if, вполне логично сделать все блоки перекрывающими.
Еще неплохо вспомнить о том, что if — это макрос реализованные через match.
ВВ>Пока вот у меня складывается такое мнение.
Оно снова какое-то подчеркнуто бездельное. Довольно рассуждать о коцепциях чистоты когда люди шли от концепций сокращения граблей. Изменяемая переменная грабли однозначно вносит. Не изменяемая проблем создает намного меньше (если вообще создает).
ВВ>>>Который компилируется, но при этом выдает ворнинг (если заменить на def, ворнингов нет). VD>>Ну так выдает же?
ВВ>Выдает, но непонятно, чем опасна именно мутабельность переменных. Ведь на def он не выдает. По твоему примеру, честно, это непонятно.
На этот вопрос я уже отвечал. Не нравится мой ответ — гугль тебе в руки.
def не имеет семантики присвоения (изменения значения) и не подвержен синдрому случайного изменения. Что тут непонятного?
VD>>Ты я смотрю решил изучить Немерле и по ходу выдаешь свое обозрение его дизайна. Это конечно похвально, но уверяю тебя, что твое мнение будет несколько более объективно, если ты прежде попробуешь язык на практике. Уверяю тебя, что большая часть вопросов отпадет сама собой.
ВВ>Нет, эти вопросы напрямую не связаны с Немерле. Просто он тут под руку все время подворачивается. На самом деле я пишу свой интерпретатор
А, ну, успехов. Но все равно, если ты пытаешься понять дизайн другого языка, то лучше это делать на практике.
Кстати, немерле идеальный язык для создания интерпретаторов и компиляторов. Вот мог бы его и применить. За одно изучил бы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Потом изменяемые переменные в Nemerle тоже выдают предупреждения (правда только предупреждения) при их перекрытии. Так что, если предупреждения не игнорировать, то грабли исключены.
С одной стороны, я полностью солидарен с создателями Sea Octothorp в вопросе опасности сокрытия переменных. Но с другой стороны, когда я писал на C++, мне это ни разу не доставило проблем. И с третьей стороны — больше всего в моей практике этот запрет доставляет неудобств, когда «внутренний скоуп» — это тело однострочной лямбды. Частый сценарий: есть «общий» представитель некоторого класса, скажем «IMeowable cat = new Cat();» Далее в этой же функции надо использовать ФВП, обрабатывающую таких же мяукающих. В Шарпе не так удобно работать в point-free стиле, поэтому часто приходится вводить имена для «безымянных» переменных. И приходится вместо естественного «cat => Feed(cat, food)» использовать «cat_ => ...» или «_ => ...» какой-нибудь.
Здравствуйте, Qbit86, Вы писали:
Q>С одной стороны, я полностью солидарен с создателями Sea Octothorp в вопросе опасности сокрытия переменных. Но с другой стороны, когда я писал на C++, мне это ни разу не доставило проблем. И с третьей стороны — больше всего в моей практике этот запрет доставляет неудобств, когда «внутренний скоуп» — это тело однострочной лямбды. Частый сценарий: есть «общий» представитель некоторого класса, скажем «IMeowable cat = new Cat();» Далее в этой же функции надо использовать ФВП, обрабатывающую таких же мяукающих. В Шарпе не так удобно работать в point-free стиле, поэтому часто приходится вводить имена для «безымянных» переменных. И приходится вместо естественного «cat => Feed(cat, food)» использовать «cat_ => ...» или «_ => ...» какой-нибудь.
На то он и не функциональный язык. Когда его проектировали о лямбдах вообще не думали.
Другое дело в Немерле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
На самом деле я пишу свой интерпретатор 