Можно ли сделать автоматическое приведение типов?

[Владимир Ситников]

Сейчас OL требует явно расставлять приведения типов. Зачем?
Честно говоря, это сильно мешает программировать.

Можно ли так, чтобы "to float"/"to int"/"to bool" надписи появлялись поверх соединительных линий, если тип входа и выхода различается?

1) Т.е. сделали GT(x, y). Тянем результат к какому-нибудь fMUL, и оно само поняло, что нужно добавить toFloat.
2) Протянули результат BOOL операции на аналоговый выход ПР -- оно показало "to float". Поменяли настройку выхода на "дискретный" -- to float пропало.

Возможность добавить to xxx вручную, конечно, нужно оставить. Но в подавляющем количестве случаев должно само определяться.

[rovki]

Одно из преимуществ ОЛ -это не возможность сделать ошибки в проекте (не алгоритмические) ,иногда это важнее удобства ,за которое всегда приходиться платить ..

[Владимир Ситников]

А в чём заключается ошибка?
Ну, реально. Можно пример?

[rovki]

Это описание типов ,иногда .на автомате можно не к тому типу подключить ,особенно в макросах ,где куча входов разных типов может быть .Потянул за связь ,не довел до нужного входа и связь зацепилась за соседний вход ,например...

[Scream]

ну это больше человеческий фактор, от такого никто не застрахован.
да, добавим перегрузку, потом ооп...

[capzap]

ну это больше человеческий фактор, от такого никто не застрахован.
да, добавим перегрузку, потом ооп...

другими словами: пользуйтесь плк

[Владимир Ситников]

Это описание типов ,иногда .на автомате можно не к тому типу подключить ,особенно в макросах ,где куча входов разных типов может быть .Потянул за связь ,не довел до нужного входа и связь зацепилась за соседний вход ,например...

И как тут ошибка "несовпадает тип данных" вам поможет?
Правильный ответ -- никак, ведь народ их подсознательно научится отсеивать.

Вот вам пример: в МЭК 61131 было всё жутко типизировано.
В стандарте на столько типизировано, что на вход ADD_INT можно подавать только INT, и оператор преобразования типа это не просто TO_INT, а BOOL_TO_INT, FLOAT_TO_INT.
Но:
1) Никто из основных производителей не стал настолько жёстко следовать стандарту. У всех разрешены неявные преобразования. Где-то, конечно, доходит до глупостей вроде "автопреобразование даты в bool"
2) В очередной версии стандарта правильно поняли что указывать тип "входного" аргумента это лишнее. И там можно вместо прежних BOOL_TO_INT, FLOAT_TO_INT использовать просто TO_INT

Чтобы выходы не зацеплялись "куда не положено", нужно не типами данных вопрос решать, а ещё как-то.
Вот хотя бы была возможность переименовать I1 в "кнопка пуск" -- уже было бы в 100500 раз понятнее.
Или возможность подкрасить вход, чтобы все подключённые провода тоже красились в этот цвет.

[Scream]

И как тут ошибка "несовпадает тип данных" вам поможет?
Правильный ответ -- никак, ведь народ их подсознательно научится отсеивать.

Вот вам пример: в МЭК 61131 было всё жутко типизировано.
В стандарте на столько типизировано, что на вход ADD_INT можно подавать только INT, и оператор преобразования типа это не просто TO_INT, а BOOL_TO_INT, FLOAT_TO_INT.
Но:
1) Никто из основных производителей не стал настолько жёстко следовать стандарту. У всех разрешены неявные преобразования. Где-то, конечно, доходит до глупостей вроде "автопреобразование даты в bool"
2) В очередной версии стандарта правильно поняли что указывать тип "входного" аргумента это лишнее. И там можно вместо прежних BOOL_TO_INT, FLOAT_TO_INT использовать просто TO_INT

Чтобы выходы не зацеплялись "куда не положено", нужно не типами данных вопрос решать, а ещё как-то.
Вот хотя бы была возможность переименовать I1 в "кнопка пуск" -- уже было бы в 100500 раз понятнее.
Или возможность подкрасить вход, чтобы все подключённые провода тоже красились в этот цвет.

насчет подкрасить связи поддерживаю, только чтобы делалось в 2 щелчка и выбиралось из заранее заданых цветов, а не тыкать стандартную палитру на другом конце экрана.