например
property DataSource: TDataSource read GetDataSource write SetDataSource;
т.е. при чтении DataSource возвращается результат метода GetDataSource
а при присваивании чего либо DataSource оно передается в качестве параметра SetDataSource
ИМХО очень удобно.
Как вариант перегрузка метода
int Class::DataSource() {} void Class::DataSource(int data) {}
Если меня склироз не подводит :D
- www.mql5.com
Удобно, очень. Но тут скорей всего будут траблы с безопасностью :(
Какие тут могут быть траблы с безопасностью?
назначать метод чтения и метод записи свойства при описании класса и не вызывать его потом
в чем уязвимость-то?
нет, я не об этом
Какие тут могут быть траблы с безопасностью?
назначать метод чтения и метод записи свойства при описании класса и не вызывать его потом
в чем уязвимость-то?
property DataSource: TDataSource read GetDataSource write SetDataSource;
Прежде всего разработчики стараются делать "безопасную" среду.
Начнем с того что:
1. Никто не гарантирует отсутствие возможности подмены типа TDataSource;
2. Никто не гарантирует отсутствие возможности подмены GetDataSource или(и) SetDataSource;
3. Разработчики действительно пошли по пути решения подобных ситуаций при помощи двух "безопасных" с их точки зрения вариантов:
а) наличие двух функций (процедур) - GetDataSource и SetDataSource;
б) Перегрузка методов (как правильно отметил mrProF выше).
PS
На мой взгляд, в подавляющем большинстве случаев наилучшим вариантом будет именно перегрузка.
Конечно разработчики могут ответить более подробно, но на мой взгляд и этого вполне хватит.
PPS
Не помню обращался или нет с подобной просьбой я в сервисдеск, во всяком случае хотел.
например
property DataSource: TDataSource read GetDataSource write SetDataSource;
т.е. при чтении DataSource возвращается результат метода GetDataSource
а при присваивании чего либо DataSource оно передается в качестве параметра SetDataSource
ИМХО очень удобно.
Моё мнение, что таки да, в дельфи эта штука гораздо приятнее чем в си.
В C++ можно сделать аналог ручками. В MQL конечно не получится.
А вообще использование методов Get и Set нагляднее. И кстати, зело тормозные они -- свойства, по кр. мере в делфях.
Но если сделают, я не против :)
Interesting:
1. Никто не гарантирует отсутствие возможности подмены типа TDataSource;
Interesting:
2. Никто не гарантирует отсутствие возможности подмены GetDataSource или(и) SetDataSource;
Разумеется, но и сейчас в MQL их можно переписать
иначе на фига все эти заморочки с ООП если нельзя переписывать методы и обращаться к унаследованным потомками метода через тип предка?
В C++ можно сделать аналог ручками. В MQL конечно не получится.
А вообще использование методов Get и Set нагляднее. И кстати, зело тормозные они -- свойства, по кр. мере в делфях.
Но если сделают, я не против :)
Да не, не тормозные. Не более чем остальные методы класса. Просто форма очень удобная, при программировании.
Единственно, я не уверен, решаться ли дельфийскую штучку прикрутить к си-образному. Надо глянуть, в си-шарп что то такое есть или нет.
- www.mql5.com
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
например
property DataSource: TDataSource read GetDataSource write SetDataSource;
т.е. при чтении DataSource возвращается результат метода GetDataSource
а при присваивании чего либо DataSource оно передается в качестве параметра SetDataSource
ИМХО очень удобно.