Здравствуйте, adontz, Вы писали:
IT>>Здесь мы в рантайм получим NullReferenceException. A>Это особенность реализации.
Особенно реализации чего? Компилятора? Следующий код это тоже особенность реализации? :
string s = null;
s.Substring(1);
IT>>Так почему же такой код должен работать так как хотят мои оппоненты в linq 2 sql?
A>Вообще-то, если бы код в linq2objects работал возвращая null, я не был бы против. Почему ты решил, что мы хотим разного поведения у разных провайдеров linq? Оно везде неправильное, просто в linq2sql это заметнее.
Это просто какой-то капец!
IT>>Бред ведь. Тут не linq и C# нужно выправлять, а мозги. A>Игорь, давай без переходов на личности. Кому надо мозги поменять — недостойная тема.
Это ты прежде всего своему единомышленнику скажи. Похоже он начал сливать, но втихую слить ему ЧСВ не позволяет и он начал переключаться на личности. Что же касается мозгов, то их действительно периодически приходится подправлять. Ничего необычного и постыдного в этом нет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Мои, ну и что? Я тебе пытался лишь сказать, что смотреть на мир нужно шире, а не зацикливаться лишь на left join.
Я прекрасно понимаю твои намерения, однако, тебе не удалось показать, что в данном случае проблема шире, чем я ее описываю. Я бы с удовольствием расширил бы взгляд на мир, если бы на то были основания.
Здравствуйте, IT, Вы писали:
IT>Особенно реализации чего? Компилятора?
Вобщем-то, да.
IT>Следующий код это тоже особенность реализации? : IT>
IT>string s = null;
IT>s.Substring(1);
IT>
Безусловно. Я не вижу ничего плохого в null.Substring(1) == null. Собственно, это не что-то новое в программировании. Специальная обработка пограничных значений достаточно обычная практика. У нас, например, уже есть разные виды NaN, включая +Infinity и -Infinity. Если +Inf — 1 == +Inf, то что странного в том что null.Substring(1) == null? Компилятору, кстати говоря, было бы очень легко поддерживать такое поведение. Есть оператор ?? для упрощения ручной поддержки. При работе с древовидными структурами вместо null может использоваться другой элемент как я уже описывал в статье
.
A>>Вообще-то, если бы код в linq2objects работал возвращая null, я не был бы против. Почему ты решил, что мы хотим разного поведения у разных провайдеров linq? Оно везде неправильное, просто в linq2sql это заметнее. IT>Это просто какой-то капец!
Да нет, это абсолютно логичное поведение при обработке множеств. Более того, это исторически сложившееся практика, что делает текущее поведение linq ещё более неприемлемым. SELECT NULL + 4 возвращает NULL. Так мы работает с данными. Это логично, это удобно.
То что ты говоришь тоже, по своему, логично, в том смысле что это однообразное поведение. Но это менее удобно, и, к тому же, в области обработки данных уже сложилась другая традиция.
IT>>>Бред ведь. Тут не linq и C# нужно выправлять, а мозги. A>>Игорь, давай без переходов на личности. Кому надо мозги поменять — недостойная тема. IT>Это ты прежде всего своему единомышленнику скажи.
Если тебя обидел кто-то другой срываться на мне не надо. Он — Александр, я — Роман. Как "Война и Мир", только человек. Перепутать сложно.
IT>Что же касается мозгов, то их действительно периодически приходится подправлять. Ничего необычного и постыдного в этом нет.
Я думаю, мне нет необходимости объяснять тебе суть формата вежливой дискуссии или напоминать об обязательности соблюдения данного формата при общении, в частности, между нами. Давай сконцентрируемся на профессиональных темах.
Здравствуйте, IT, Вы писали:
IT>Но по большому счёту всё это фигня.
Твое поведение странное: сначала ты пишешь, что проблема шире, теперь пишешь, что проблемы вообще нет. Если ее нет, то как она может быть шире той, которую сформулировал я?
Здравствуйте, Alexander Polyakov, Вы писали:
IT>>Но по большому счёту всё это фигня. AP>Твое поведение странное: сначала ты пишешь, что проблема шире, теперь пишешь, что проблемы вообще нет. Если ее нет, то как она может быть шире той, которую сформулировал я?
Давай я перефразирую, чтобы тебе было понятней. Проблемка, малюсенькая такая проблемочка, которую в принципе даже не видно в микроскоп, немного шире, чем ты думаешь. Так устроит?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
A>>Безусловно. Я не вижу ничего плохого в null.Substring(1) == null. IT>Тогда тебе нужно обсуждать C# в целом, а не linq в частности.
Linq — это ведь не просто библиотека, синтаксис был существенно расширен ради linq, компилятор переделан. Так что обсуждать, почему не добавили всё необходимое для обработки запросов, в рамках обсуждения linq ИМХО вполне примлемо. Хотя если ты настаиваешь, можем завершить обсуждение вопроса с формулировкой "too epic subject".
MC>>Т.е. использование left join делает запись мягко говоря неудобной и заставляет использовать какие-то хаки, чтобы добиться желаемого. Можно ли сделать как-то проще?
IT>Мои оппоненты путают тёплое с мягким, а именно семантику языка с библиотечной реализацией конкретного провайдера. Они приводят логически кривой код, а потом возмущаются, что с ним неудобно работать. Вот такой код не будет работать в linq 2 object:
IT>
IT>...
IT>left join t ...
IT>select t.Aaa
IT>
IT>Здесь мы в рантайм получим NullReferenceException. Так почему же такой код должен работать так как хотят мои оппоненты в linq 2 sql? Бред ведь. Тут не linq и C# нужно выправлять, а мозги.
А если эгоистично вернуться к моему вопросу на который я дал ссылку, ты не мог бы на него ответить? Или проще никак не сделать?
Здравствуйте, adontz, Вы писали:
A>>>Безусловно. Я не вижу ничего плохого в null.Substring(1) == null. IT>>Тогда тебе нужно обсуждать C# в целом, а не linq в частности.
A>Linq — это ведь не просто библиотека, синтаксис был существенно расширен ради linq, компилятор переделан. Так что обсуждать, почему не добавили всё необходимое для обработки запросов, в рамках обсуждения linq ИМХО вполне примлемо. Хотя если ты настаиваешь, можем завершить обсуждение вопроса с формулировкой "too epic subject".
Компилятор был именно расширен. Ты же предлагаешь изменить текущее поведение компилятора. Такие вещи в принципе можно делать, но только не в C#, а сами знаете в чём. Кстати, Влад недавно добавил в сами знаете во что оператор '?.' (а может '.?'), довольно удобная штука, позволяющая записывать выражения типа a?.b?.c?.d. Но это всё всё равно сахар.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
A>>Linq — это ведь не просто библиотека, синтаксис был существенно расширен ради linq, компилятор переделан. Так что обсуждать, почему не добавили всё необходимое для обработки запросов, в рамках обсуждения linq ИМХО вполне примлемо. Хотя если ты настаиваешь, можем завершить обсуждение вопроса с формулировкой "too epic subject". IT>Компилятор был именно расширен. Ты же предлагаешь изменить текущее поведение компилятора.
Расширили бы компилятор этим вашим ?. или .? А так получается недоделка.
Если нам не помогут, то мы тоже никого не пощадим.
