Здравствуйте, stalcer, Вы писали:
S>Ну-ну. А разве CObject имеет поле Config? А? Или может быть поле User. Или может быть CObject можно сравнивать с int (c 16)? Чушь!
FDS>>Root.Config инициализированно? — нет — выйти из условного оператора
FDS>>Root.?Config.?User инициализированно? — аналогично
S>
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, stalcer, Вы писали:
S>>Ну-ну. А разве CObject имеет поле Config? А? Или может быть поле User. Или может быть CObject можно сравнивать с int (c 16)? Чушь!
Я имею ввиду, что для компилятора проверяемое поле — указатель на базовый тип
Здравствуйте, FDSC, Вы писали:
FDS>Повторяю, из условного оператора "if"
А вообще интересная идея — считать условие невыполненным, если оно не может быть вычислено (а не тупо сравнивать числа).
Если нас это устраивает, мы просто пишем
if (a.b > 10)
Если надо наоборот — чтобы оно выполнилось в случае невычислимости, то пишем
if (!(a.b <= 10))
Проблема в том, что будут ситуации, когда некоторые случаи невычислиости должны обязательно выкидывать исключение. Т.е. если a.b === null — исключение, а если a.b.c === null — считать условие невыполненным. И еще не ко всякому условию можно записать обратное через !(...)
Здравствуйте, FDSC, Вы писали:
FDS>Я имею ввиду, что для компилятора проверяемое поле — указатель на базовый тип
Ты ответь на мой вопрос. Какого типа, с точки зрения предполагаемой спецификации языка должно быть каждое из перечисленных мной выражений. И какое значение каждое из них должно вернуть. Особенно <...>.?Age.
С точки зрения логики. Ведь именно с этой точки зрения мы обсуждаем введение нового типа выражения ".?" в язык.
Его синтаксис можно обозначить так:
<primary> ".?" <field-name>
Где <primary> — это тоже выражение. Вот и объясни мне правила выисления этого выражения вне зависимости от контекста (наличия if, ect.). Объясни также как это объяснено для других выражений в спецификации.
Здравствуйте, Кодёнок, Вы писали:
Кё>Проблема в том, что будут ситуации, когда некоторые случаи невычислиости должны обязательно выкидывать исключение. Т.е. если a.b === null — исключение, а если a.b.c === null — считать условие невыполненным. И еще не ко всякому условию можно записать обратное через !(...)
Тогда можно записать так a.b.?c вместо a.?b.?c. Если b == NULL — в первом случае будет поднято исключение
FDS>>Последние два примера не корректны для данной постановки задачи.
S>Почему это, интересно знать?
Согласен. Всякий синтаксически правильный код — корректен.
S>Пучть Root = null, а someBoolVar = true. S>Второй пример: должно получиться if (false || true), т.е. if должен выполниться. S>Третий пример: x = false;
S>Все корректно. И вообще, любое выражение я могу применять в любом контексте. Из любых более мелких выражений я могу конструировать более сложные.
Кодёнок предложил считать условие не выполненным, если соотв. значение некорректно.
Тогда всё получается.
Здравствуйте, stalcer, Вы писали:
S>Его синтаксис можно обозначить так:
S><primary> ".?" <field-name>
S>Где <primary> — это тоже выражение. Вот и объясни мне правила выисления этого выражения вне зависимости от контекста (наличия if, ect.). Объясни также как это объяснено для других выражений в спецификации.
Каким должен быть <EpressionType>? С одной стороны — типом поля Object2. С другой стороны по твоей логике — bool (так как ты ему false присваиваешь). Как я и говорил — чушь.
Здравствуйте, stalcer, Вы писали:
S>Неа. Вот это: S>
S>bool x = (Root.?Config.?User.?Age > 16);
S>
S>Я перепишу так:
S>
S>int age = Root.?Config.?User.?Age;
S>bool x = (age > 16);
S>
S>Утверждаю, что это должно быть абсолютно эквивалентно первому варианту. Об этом даже спорить не буду.
Согласен...
S>Вопрос 1: правильно ли я объявил переменную age типа int. Или должен быть другой тип? S>Вопрос 2: чему будет равно значение переменной age?
Честно говоря, не знаю, как это правильно объявить. Но оператор .? должен возвращать булевский тип. Вообще-то ерудна получается.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>В общем, примерно так:
FDS>><object1>.?<Object2> == if (Object1.Object != NULL) ... ; else return false;
S>А вот и фигушки. Для начала расшифрую твое многоточие. Ты, наверное, имел ввиду следующее:
S>if (Object1.Object2 != NULL) return Object1.Object2; else return false;
S>А вот теперь подумай:
S>
S>Каким должен быть <EpressionType>? С одной стороны — типом поля Object2. С другой стороны по твоей логике — bool (так как ты ему false присваиваешь). Как я и говорил — чушь.
Правильно.
Надо ввести тогда оператор .? ... .?... условие . Тогда оператор станет возвращать bool в обоих случаях. Только как это сделать?
Здравствуйте, FDSC, Вы писали:
FDS>Честно говоря, не знаю, как это правильно объявить. Но оператор .? должен возвращать булевский тип. Вообще-то ерудна получается.
FDS>Надо долго думать...
Нет, оператор не дожен возвращать никакой тип, иначе ничего не выйдет Именно это мне и показалось интересным — не простое вычисление выражения в операторе if по правилам языка, а какое-то более сложное поведение, в данном случае — считать само условие невыполненным в случае невозможности вычислить аргументы.
Т.е. этот код
if (Object1.?Object2.?Object3)
DoSmth();
должен транслироваться в
if (Object1 != null && Object1.Object2 != null)
{
if (Object1.Object2.Object3)
DoSmth();
}
Т.е. .? не просто оператор, который ведет себя каким-то хитрым образом, а изменение поведения компилятора.
Проблема тут сразу очевидна — как отличить "провал" оператора .? от нормального выполнения? Что если провал одного из операторов должен приводить к невыполнению всего условия, а провал другого — к выполнению всего условия? Еще проблема — если этот оператор влияет на способ всего вычисления выражения в if, то могут быть какие-нибудь неочевидные проблемы.
Кё>Т.е. .? не просто оператор, который ведет себя каким-то хитрым образом, а изменение поведения компилятора.
Кё>Проблема тут сразу очевидна — как отличить "провал" оператора .? от нормального выполнения? Что если провал одного из операторов должен приводить к невыполнению всего условия, а провал другого — к выполнению всего условия? Еще проблема — если этот оператор влияет на способ всего вычисления выражения в if, то могут быть какие-нибудь неочевидные проблемы.
Я собственно то же это хотел. Но возникает вопрос синтаксиса при использовании оператора .? вне оператора if.
Можно ввести разновидность оператора .? и .~?, которые будут всё-таки возвращать булевский тип для определённого условия, но работать только в команде с условием.
Здравствуйте, Кодёнок, Вы писали:
Кё>...то могут быть какие-нибудь неочевидные проблемы.
Очевидная проблема, в том, то невозможно формально описать логику поведения такого оператора.
Возможно только если он выполняется обычным образом, и в нашем примере (с Age) возвращает 0 (ноль) типа int.
То есть пусть Object1.?Age выполняется так:
if (Object1 != null)
return Object1.Age;
else
return (AgeType)default_value;
Где, AgeType — тип поля Age, а default_value — значение, зависящее от AgeType. Для ссылочных типов default_value = null, для числовых — 0, для строки — "", для структур — ??? может структура забитая нулями.
Это, ИМХО, единственный нормальный способ описать поведение такого оператора. Только не очень красиво, Age может быть и так равен нулю.
Или же расширить синтаксис до такого, например: Object1.?Age{7}, что будет означать, то вместо default_value использовать 7.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Кодёнок, Вы писали:
Кё>>...то могут быть какие-нибудь неочевидные проблемы.
S>Очевидная проблема, в том, то невозможно формально описать логику поведения такого оператора. S>Возможно только если он выполняется обычным образом, и в нашем примере (с Age) возвращает 0 (ноль) типа int.
S>То есть пусть Object1.?Age выполняется так: S>
S>Где, AgeType — тип поля Age, а default_value — значение, зависящее от AgeType. Для ссылочных типов default_value = null, для числовых — 0, для строки — "", для структур — ??? может структура забитая нулями.
S>Это, ИМХО, единственный нормальный способ описать поведение такого оператора. Только не очень красиво, Age может быть и так равен нулю.
S>Или же расширить синтаксис до такого, например: Object1.?Age{7}, что будет означать, то вместо default_value использовать 7.
Не пойдёт! К сожалению. Смысл в том, что оператор должен прекращать выполнение обработки условного выражения, а не возвращать значение по умолчанию. Как тогда справиться с последовательным вызовом a.?b.?c.? Хранить "нулевые" объекты-значения по умолчанию?
Здравствуйте, FDSC, Вы писали:
FDS>Не пойдёт! К сожалению. Смысл в том, что оператор должен прекращать выполнение обработки условного выражения, а не возвращать значение по умолчанию. Как тогда справиться с последовательным вызовом a.?b.?c.? Хранить "нулевые" объекты-значения по умолчанию?
А чего не пройдет-то? С последовательным вызовом как раз все нормально. Например, a.?b.?c.?Age
Пусть поле 'b' будет равно null.
1) A tmp1 = a; // not null
2) B tmp2 = (tmp1 != null) ? tmp1.b : null; // a.b (== null)
3) C tmp3 = (tmp2 != null) ? tmp2.c : null; // null, так как tmp2 == null
4) int tmp4 = (tmp3 != null) ? tmp3.Age : 0; // 0, так как tmp3 == null
Как тогда справиться с последовательным вызовом a.?b.?c.? Хранить "нулевые" объекты-значения по умолчанию?
