Здравствуйте, Аноним, Вы писали:
А>int x = 0;
А>{ А> int x = 1; А> println(x); // 1 А> println(.x); // 0 А> // . — это оператор scope А>}
А оно реально нужно? Ввел себе переменную и нет проблем.
В прочем, для личного пользования такой макрос должно быть можно сделать. В этом случае "." вроде как унарный оператор. Надеюсь, что в парсере для него закладок нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, catbert, Вы писали:
C>>Оператор scope интересный. Может реализовать такой?
VD>Смотреть мултики не охота. Есть ссылка на описание?
Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.
Здравствуйте, catbert, Вы писали:
C>Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.
А зачем их писать в больших количествах, да еще и вложенными? Сдается мне они там фигней занимаются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Интересная презентация о D
От:
Аноним
Дата:
13.04.12 23:37
Оценка:
Здравствуйте, catbert, Вы писали:
C>Нет. Смотри мультик.
Искал в гугле по "language d", "scope operator"
Посмотрел мультик.
С чем-то подобным, вроде, боролся Александреску, вводя ScopeGuard'ы на ресурсы.
Здравствуйте, catbert, Вы писали:
C>Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.
в с++ finally нет, там для этого деструкторы
в c# я не так давно сделал тоже самое, но в Dispose() (тут надо признаться нет такой надёжности, но и место там не такое важное, да и использую я это строго)
в немерле мне кажется было бы удобнее решать эту проблему так
Здравствуйте, catbert, Вы писали:
C>Подразумевается что в первом блоке try-catch будет что-то делаться с raii1. И если случится какая-то пакость, то нужно откатить изменения.
Возможно. Но я по-прежнему не вижу, зачем городить все эти вложенные try/catch, когда для отката пакостей есть деструкторы.
Если не поможет, будем действовать током... 600 Вольт (C)
Здравствуйте, catbert, Вы писали:
C>Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.
Там суть не столько в try-catch-finally а в том что рассматривается ситуация когда кроме операции очистки (clean) есть
операция отката (rollback). Когда отката нет то RAII из C++ (да и в D он доступен) выглядит красиво и чисто, с откатом
же приходится городить try-catch-finally.
D'шный же scope все позволяет делать красиво:
scope(exit){
writeln("exit: срабатывает всегда на выходе");
}
scope(success){
writeln("success: срабатывает если не было исключений");
}
scope(failure){
writeln("success: срабатывает в случае исключений");
}
Здравствуйте, FR, Вы писали:
FR>Там суть не столько в try-catch-finally а в том что рассматривается ситуация когда кроме операции очистки (clean) есть FR>операция отката (rollback). Когда отката нет то RAII из C++ (да и в D он доступен) выглядит красиво и чисто, с откатом FR>же приходится городить try-catch-finally.
Как-то не встречал такой проблемы. Чем откат вдруг стал отличаться от другой очистки ресурсов?
В том же шарпе отлично работает стратегия:
using (var connection = DbManager.GetConnection())
{
... // делаем что хотим...if (что-то_не_так)
{
connection.Rollback();
return;
}
connection.Commit();
} // по любому исключению - Rollback
Никаких try-на при этом вообще заводить не приходится.
Где проблема то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Как-то не встречал такой проблемы. Чем откат вдруг стал отличаться от другой очистки ресурсов?
Часто ничем.
Но бывает что нужен кроме очистки и откат, который срабатывает только при ошибке.
VD>В том же шарпе отлично работает стратегия:
... VD>Никаких try-на при этом вообще заводить не приходится.
Эта стратегия прекрасно работает, и не только в шарпе, только если обработка ошибок построена
на кодах возврата, если же она основывается на исключениях то будет как и продемонстрировал
Александреску вложенные try.
VD>Где проблема то?
Проблема возникает если используешь исключения.
Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или
одноразовых RAII оберток.
Здравствуйте, FR, Вы писали:
FR>Часто ничем. FR>Но бывает что нужен кроме очистки и откат, который срабатывает только при ошибке.
Дык, может в этом и дело? Почему только при ошибке? Откат должен быть всегда, если не было комита. И все! Проблем больше нет.
FR>Эта стратегия прекрасно работает, и не только в шарпе, только если обработка ошибок построена FR>на кодах возврата, если же она основывается на исключениях то будет как и продемонстрировал FR>Александреску вложенные try.
Мне плевать на тараканов в голове у Александреску. Описанная мной стратегия прекрасно работает в любом случае. Исключения ничем не мешают ей.
VD>>Где проблема то?
FR>Проблема возникает если используешь исключения.
Не возникает.
Давай без заявлений. Покажи проблему. Я пока что ее в упор не вижу.
FR>Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или FR>одноразовых RAII оберток.
Я использую try finally в чистом виде раз в год по чайной ложке. Что толку от улучшения этой чайной ложки?
Потом, чем лучше?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или FR>одноразовых RAII оберток.
Да ладно.
Просто нужно к построению логики подходить с другой стороны.
Нужно вызывать в коде не rollback, а commit. Вызов rollback произойдет при откате, если не было commit.
И сразу вся вложенность пропадает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
FR>>Проблема возникает если используешь исключения.
VD>Не возникает.
using (var connection = DbManager.GetConnection())
{
... // делаем что хотим...// тут вылетело исключение, откат обязателен, как ловим без try?if (что-то_не_так)
{
connection.Rollback();
return;
}
connection.Commit();
} // по любому исключению - Rollback
VD>Давай без заявлений. Покажи проблему. Я пока что ее в упор не вижу.
В пдфке и выше в коде проиллюстрировано.
FR>>Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или FR>>одноразовых RAII оберток.
VD>Я использую try finally в чистом виде раз в год по чайной ложке. Что толку от улучшения этой чайной ложки?
Я кстати тоже так стараюсь, но писатели библиотек часто думают по другому
VD>Потом, чем лучше?
Для меня очень удобным оказался банальный scope(exit)
FR>using (var connection = DbManager.GetConnection())
FR>{
FR> ... // делаем что хотим...
FR> // тут вылетело исключение, откат обязателен, как ловим без try?
FR> if (что-то_не_так)
FR> {
FR> connection.Rollback();
FR> return;
FR> }
FR> connection.Commit();
FR>} // по любому исключению - Rollback !!! ЭТО ДЛЯ КОГО БЫЛО НАПИСАНО?
FR>
FR>В пдфке и выше в коде проиллюстрировано.
Ты меня извини, но ПДФ-ка эта меня не трогает. Я не намерен убивать время на чтение бредней тех кто не додумался посмотреть как делают другие.
FR>Я кстати тоже так стараюсь, но писатели библиотек часто думают по другому
Пускай учатся программировать. Или это намек на то, что они тебя заставляют делать плохое?
FR>Для меня очень удобным оказался банальный scope(exit)
Дык и файнали делает тоже самое. А учитывая редкую надобность я вообще не понимаю чем они там занимаются.
Думаю, что Ди сдохнет, если они и дальше такой фигней будут заниматься.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ругань пропускаю, итог по ней ты просто не понимаешь, так как не программируешь
в подобном стиле, в общем тут говорить не о чем.
FR>>Для меня очень удобным оказался банальный scope(exit)
VD>Дык и файнали делает тоже самое. А учитывая редкую надобность я вообще не понимаю чем они там занимаются.
scope(exit) удобнее, но согласен это из разряда бантиков.
VD>Думаю, что Ди сдохнет, если они и дальше такой фигней будут заниматься.
Это было еще в самых первых по моему версиях.
Насчет сдохнет, не раньше чем немерли
Здравствуйте, FR, Вы писали:
FR>Ругань пропускаю, итог по ней ты просто не понимаешь, так как не программируешь FR>в подобном стиле, в общем тут говорить не о чем.
Ну, типа я дурак, а ты д'ртаньян.
Это ты просто не понимаешь, что делая ролбэк в автомате, а комит явно проблемы даже не возникнет.
FR>scope(exit) удобнее, но согласен это из разряда бантиков.
Чем?
VD>>Думаю, что Ди сдохнет, если они и дальше такой фигней будут заниматься.
FR>Это было еще в самых первых по моему версиях. FR>Насчет сдохнет, не раньше чем немерли
В Н такой фигней никто не занимается. Так что если и сдохнет, то явно не от овердизайна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В общем чисто мелкие локальные удобства.
FR>>Насчет сдохнет, не раньше чем немерли
VD>В Н такой фигней никто не занимается. Так что если и сдохнет, то явно не от овердизайна.
Ну пока повторяете путь D со второй версией.
Да сдохнуть никому не желаю, наоборот
Это уже интереснее. Вопрос только в том насколько удобно будет такой код поддерживать. Ведь очистка будет разнесена по коду. Да и легко забыть добавить этот блок и ресурсы не освободятся. Тут RAII все же удобнее, мне кажется.
FR>В общем чисто мелкие локальные удобства.
ОК, убедил. Как мелкие локальные удобства может оно и хорошо.
FR>Ну пока повторяете путь D со второй версией.
Язык то мы менять не намерены. Н2 будет работать в Nemerle до тех пор пока мы не сможем воспроизвести компилятор Nemerle на Н2.
Ди же был плохо спроектирован как язык. И 2.0 было созданием нового языка (глубокого редизайна). При этом даже в 2.0 ди по функциональности и удобству до Nemerle 1.0 не дотягивает. О их макросисетме я вообще молчу. Как бы сравнивать эти скопы с такими вещами как паттерн-матчингом и вариантами как-то не смешно. Это какой-то пшик супратив мега-фичи. Теперь то, по программировав на ОКамле, ты это должен осознавать.
В прочем, все это никак не связано с выживанием языка. Иначе С++ сдох бы в страшных муках .
FR>Да сдохнуть никому не желаю, наоборот
И на том спасибо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Посмотрел заодно презентацию "самого" Уолтера! Прямо скажем, презентация получилась УГ. Мне, как знающему сами фичи, было не интересно. А незнающие даже не поняли, что и зачем там придумано. Плюс, Уолтер практически читал скупые слайды (вначале вообще отдающие маркетоидной тупизной), вместо пояснения каких-нибудь красивых примеров. В любом случае, D намного ближе к мэйнстриму, чем Не — куча сахаринок над простым по сути языком делает его понимабельным сотням кодеров. Миксины и CTFE не в счёт, конечно. И вот так навскидку, generative programming у D мне кажется как раз тем _наиболее_юзабельным_ оптимумом между Немерловым мета-мета-метазавихрением и отсутствием макросов как таковых.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что Ди сдохнет, если они и дальше такой фигней будут заниматься.
Презентация называется "Три неожиданно успешных фичи D". Александреску рассказывает, что они сами сомневались, вводить ли эти фичи в язык, но пользователям они очень понравились. А пользователи Ди, как правило, не идиоты, по тем же причинам, что и пользователи Немерле.
Так что можно сколько угодно теоретизировать на тему "это никому не пригодится", но оно уже пригодилось.
Здравствуйте, matumba, Вы писали:
C>>http://channel9.msdn.com/Events/Lang-NEXT/....
M>Посмотрел заодно презентацию "самого" Уолтера! Прямо скажем, презентация получилась УГ. Мне, как знающему сами фичи, было не интересно. А незнающие даже не поняли, что и зачем там придумано. Плюс, Уолтер практически читал скупые слайды (вначале вообще отдающие маркетоидной тупизной), вместо пояснения каких-нибудь красивых примеров. В любом случае, D намного ближе к мэйнстриму, чем Не — куча сахаринок над простым по сути языком делает его понимабельным сотням кодеров. Миксины и CTFE не в счёт, конечно. И вот так навскидку, generative programming у D мне кажется как раз тем _наиболее_юзабельным_ оптимумом между Немерловым мета-мета-метазавихрением и отсутствием макросов как таковых.
Библия более юзабельна, чем учебник по механике, но читатели библии — бесполезны как инженеры и конструкторы чего-то более сложного, чем собачьи будки.
А системы с мета-завихрением (программные конструкторы с ЕЯ интерфейсами) в конечном итоге вытеснят "простых" программистов, и им придется пойти в мясники и в управдомы. К счастью для них еще лет десять они могут резвиться в программистах.
Здравствуйте, catbert, Вы писали:
C>Так что можно сколько угодно теоретизировать на тему "это никому не пригодится", но оно уже пригодилось.
Обычно хорошую фичу хотят много народа параллельно. Пока что я вижу только случай "Поглядите как у конкурентов есть фича Х. Мы не должны от них отставать!".
Это плохое основание для введения новой фичи. Предлагаю немного подождать. Если запросы на фичу будут появлаться и дальше, то сделаем.
Потом мне кажется, что более востребованным было бы ввести механизм работы с скопами в макросе. В Н2 мы уже такой механизм запланировали.
Имея такой механизм можно будет делать фичи вроде скопов или use из F# в виде макросов. Это, на мой взгляд, куда полезнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
_C_>А системы с мета-завихрением в конечном итоге вытеснят "простых" программистов...
Знаем, слышали, ржали всей деревней. Наверное, то же самое грезилось и ЛИСПерам, у которых другие языки — это "переизобретение ЛИСПа, только сильно урезанное".
Дело в том, что большинство программ написано как раз "средними" профессионалами на средних языках. Кулхацкеры-хаскелянты конечно бы поржали над ними, но практический результат — мерило любых теорий.