Предложения по будущему MQL - страница 2

Новый комментарий
 

dll - это костыли. dll, работающая с веб, - это дыра в безопасности компьютера. Я бы не стал ставить у себя эксперта с такой dll. Конечно, поддержка mysql и т.п. в mql будет излешней.

Нужна нативная поддержка веба в клиентах для межклиентских взаимодействий и прочего.

 

По мне бы, отойти в MT от Windows, как "единственной и неповторимой" (да, я про Линух), а в язык добавить структуры/классы.

Без них чот совсем неприкольно.

 
В дополнение к возможности блокировать инвесторский пароль из эксперта следует добавить функцию, возвращающую текущую версию терминала. Версия терминала в функции должна быть защищена от подмены.
 

Хотелось бы в MQL5 увидеть обектноориентированный подход

 
Выскажу своё тупое и непросвещенное мнение.
В первую очередь - отладчик. Без него пользоваться языком - мучение. Я сейчас вообще перестал что-либо разрабатывать на mql и на 100% ушел на матлаб в качестве платформы разработчика. И в первую очередь именно по этой причине.
Во вторую очередь - это структуры языка С. Объекты С++ по-моему это уже лишнее. А вот структуры штука жизненно необходимая. Ведь разрабатываемые системы имеют дело с барами. А бары сами по себе есть структуры.
В третью очередь - веб-интерфейс. Возможно какой-то высокоуровневый, типа http или ftp, но лучше наверное самый базовый - TCP/IP. Сейчас это у меня реализованно через dll и именно по TCP/IP я получаю двустороннюю связь с матлабом и управляю терминалом с мобильного телефона. Хотелось бы иметь TCP/IP как стандартное средство языка. Согласен с теми, кто считает поддержку TCP/IP потенциальной дырой в безопасности, а так же нарушением правил чемпионата. А потому подключение TCP/IP должно быть опциональным. Точно так же, как сейчас можно разрешить или запретить импорт из dll.

Наеонец последнее. Во времена MT3 распространялась dll протокола связи и даже Java-интерфейс. Очень хотелось бы, чтобы эта традиция была возобновлена в MT5. Особенно это касается интерфейса для Явы.
 
MQL не следует мигрировать в сторону сложного и "навороченного" языка с объектами и низкоуровневыми интерфейсами. Ясно, что на с++ пишут только программисты ;) , а кто использует mql ? Многие, я полагаю, - это люди, которые не считают себя программистами. Совместить интересы и тех и других в одном решении невозможно.  
 
ArtemRG:
MQL не следует мигрировать в сторону сложного и "навороченного" языка с объектами и низкоуровневыми интерфейсами. Ясно, что на с++ пишут только программисты ;) , а кто использует mql ? Многие, я полагаю, - это люди, которые не считают себя программистами. Совместить интересы и тех и других в одном решении невозможно.

Почему же. те кто пишет сейчас на обычном уровне "1 класса", там и могут писать .. а вот объекты было бы хорошо. никто не заставляет тебя их использовать же. и структуры тоже очень надо. сам столкнулся .. с теми же файлами и виртуальным ведением позиции. очень сложно реализовать и отладить обычными средставами это, не имея обычного отладчика и простых возможностей реализации хотябы структуры. бар то структура, а я даже такую не могу сделать.. только массив одного типа.
 
ArtemRG:
MQL не следует мигрировать в сторону сложного и "навороченного"
языка с объектами и низкоуровневыми интерфейсами. Ясно, что
на с++ пишут только программисты ;) , а кто использует mql ? Многие,
я полагаю, - это люди, которые не считают себя программистами.
Совместить интересы и тех и других в одном решении невозможно.
Зачем в одном? Если принцип наследственной совместимости с предыдущими mql-языками будет последовательно 
поддерживаться разработчиками, то "наворачивайте" вы хоть черта!
Если я не потяну MQL5, буду себе спокойно продолжать писать на MQL4, используя более продвинутый терминал и
потихонечку осваивать новации.
 

1. Ввести фукцию возвращающую текущий список инструментов в маркетвоч.


2. Ввиду множества уже инструментов, не просчитывали Вы
назначить свои расширения?

Для скриптов например *.mqs, а для советников *.mqa,
*.mqi соответственно для индикаторов... и т.д...

Ибо попадается сборный архив, пока разберёшь чё к чему
полгода пройдёт... а там уже новый архив на подходе... :)

Совместимость с нынешними обеспечится тем что
терминал скушает .mq4 как общий тип расширения...

 

вставлю и я свои 5 копеек:

- тут уже говорили про структуры/классы, тоже страдаю от их отсутствия. Хотелось бы видеть реализацию близкую к ... javascript :
1. возможность создавать на лету без предварительного объявления - Obj = {} или Obj = {"count" : 0, "name" : "Vasya Pupkin" }
2. гибкость - в отличии от структур Си, которые имеют жесткую структуру, в яваскрипте можно менять на лету и добавлять/удалять свойства/методы
Obj = { "count": 0}; Obj["name"] = "Vasya Pupkin"; delete Obj["count"]; delete Obj.name;

- ссылки на функции:
int getNNResponse(double in[]){
}
Obj = {"getResponse" : getNNResponse}; Obj.getNNResponse( myin);
int getAlternativeResponse(double in[]){
}
myResponse = boolAlternative ? getAlternativeResponse : getNNResponse;
myResponse( myin);

- интерактивность:
хотя бы возможность создаваемым графическим объектам назначить вызов функции по клику;
тогда можно будет гибко управлять экспертом или менять параметры на лету;
я уж молчу :-) об интефейсных элементах - кнопках, листбоксах и пр. Хотя бы отрабатывать клики на граф. объектах

- оператор вопроса
не сильно важно, но удобно использовать вместо простых if и прямо по месту:
Comment( " used " + (boolAlternative ? "alternative" : "regular") + " approach" )

- пофиксить оператор присваивания += для работы со строками:
string global_comment = "";
global_comment += "first line"; //сейчас не работает

- несколько наложенных друг на друга плоскостей для вывода графики, чтобы можно было на лету включать/выключать определенные плоскости, менять их уровни

123
Новый комментарий
Причина обращения: