Galkov писал(а):
Есть у элемента IndexToChanel св-во Data
Во-первых, это какой же тип мы должны назначать при Data=NUL
И пусть подключена верхняя точка и с нее всегда идет String.
Оппа, а пользователь забыл, что Data = real(1.0). И что характерно - и не надо до этого ему было помнить.
Заморочка ведь.
До слов "Оппа" понятно дальше нет. Поэтому не могу ничего тут ответить.
Galkov писал(а):
Плюс к вышесказанному, это не более чем личное мнение, что в правилах без исключений путаешься меньше, чем в правилах с исключениями.Не согласен. Видимо имеет смысл кроме уровней пользователя определить еще и уровень оптимизации, о котором идет речь. Как я уже говорил для "тех кто путается" всегда существует тип TData. Не охото разбираться, вставляем этот тип и все будет прекрасно автоматом во все конвертироваться. Оптимизация же к сожалению вся построена на исключениях и частностях поэтому на данный момент аргумент весомым не считаю.
Galkov писал(а):
Засыпание - это изменение интерфейса пользователя второго уровня.Видимо этот вопрос стоит обсуждать не ранее, чем будет полностью понятен пример и после слов "Оппа". Иначе боюсь о разных вещах совершенно беседа идти будет.
Galkov писал(а):
Если таких элемента 2, для обоих есть вызов этого метода, и константные значения св-ва X у них РАЗНЫЕ (тоже важно) - это должен быть функциональный вызов метода, для которого X - это переменная.тоже не уловил смысла проблемы:
// где-то в коде программы вставлен функциональный вызов метода с данными из потока положим:
doMethod(s23 + s34);
...
// далее где-то в коде тот же метод со св-ом по умолчанию:
doMethod('test');
...
// и наконец тот же метод с данными с точки:
doMethod(res4);
// в скрипте FTCG стоит:
println('doMethod(', X, ');')
// метод реализован так:
procedure doMethod(X:string);
begin
...
Message(X);
...
end;получаем: да действительно в коде элемента св-во X это переменная. Но с точки зрения программы св-во X в строке println('doMethod(', X, ');') как было константой так ей и осталось. Чему и как это противоречит не понимаю совершенно.
Galkov, наверно стоит всетаки вставлять поменьше теории и побольше практики. Ибо только код гарантирует однозначное трактование и понимание ситуации. Кроме того хотелось бы перед высказываниями делать пометку о том, к чему оно: просто соображение о некой культуре написания элементов, или соображение о возможной ошибки. По-умолчанию я все отношу ко второй группе из-за чего видимо так же возникает недопонимание ситуации.
Galkov писал(а):
Давай конкретно: может ли быть "особачено" св-во, имеющее одноименную верхнюю точку Вопрос хороший. Думаю, что нет.
[size=-2]------ Добавлено в 17:49
Galkov, нашел действительно реальное практическое исключение из правил при автоматическом кодирование на данный момент времени. Положим реализуя FTCG пакет на базе C++ мы вынуждены ввести некий класс string, который нам предоставит возможность использовать оператор + для обоих операндов при конкатенации строк. Как только мы введем такой класс и условимся, что тип data_str будет иметь внутреннее представление string, то мы сразу же наступаем на грабли:
func doStrCat()
event(onStrCat, Str1 & Str2)
end
func doMessage()
println('Message(', Text, ');')
end
// положим Str1 - задано по-умолчанию, а Str2 берется с верхней точки. Получаем код:
Message("text" + int_to_str(i34));а должны были бы по хорошему получить string("text").
Однако это всетаки исключение более высокого порядка, связанное с изначальным нарушением концепции, основанной на том, что типы статических св-в элемента, определяемых в среде тождественно равны типам этих свойств в коде.
Поиск
Друзья
Администрация