1) Делали раньше ReadXXX, теперь тоже обязаны делать нечто подобное - e_xxx.
2) Разработчику кодов элемента нужно непременно указывать тип приведение вручную - иначе он запутается.
Galkov писал(а):
Ровно в тот момент как произошли интерфейсные изменения - ДА, засыпаемт.е. под этим понимается расширение количества типов для точек? Было 5 типов стало 19 - засыпали дорогу. Совершенно глупый вопрос напрашивается: а если бы типов стало 6 это тоже засыпание дороги
Galkov писал(а):
И меньше путаницы бы было у автора элемента.не доказано и не показано.
Galkov писал(а):
Если бы не было интерфейсных изменений ("слез ребенка"), то "богатства мира" были бы совершенно уместны.
Иначе - нет, думается
повторяю вопрос: каким образом расширение количества типов касается пользователя? Показ типов точек по умолчанию отключен. Включают его совсем не многие. В итоге вывод сделан не понятно из каких соображений.
Хотелось бы всетаки конкретизировать свои высказывания на примерах. На данный момент абсолютно не ясно, что будет вызывать у разработчика путаницу и когда, а так же почему у пользователя возникнут трудности с интерфейсом. Не понятно так же почему явное указание типов в коде скрипта - это более правильно и логично, нежели тоже самое задание типа в ECreator.
Galkov писал(а):
Но если представить себе на секунду, что, хоть и потом, но это будет, тогда получается, что св-во элемента уже не есть константа в кодахВ каких случаях это не константа?
Galkov писал(а):
Не считая случаев наличия методов do<Prop>Такие точки должны определяться только для св-тв, являющихся начальными инициализаторами полей объекта. Во всех иных случаях это уже будет комбо элемент с основным ф-лом + встроенной ячейкой памяти.
Поиск
Друзья
Администрация