Perl vs Delphi
Сейчас тебя с чем-нибудь смешают мне кажется
Надо либо переформулировать задачу, либо использовать другой язык
Надо либо переформулировать задачу, либо использовать другой язык
Я вот что придумал.
Основано это будет на той конструкции, но она будет генериться на перле на основе xml-описания, где будут перечислены возможные классы-свойства, а потом ее инклудить в исходник дельфевый и перекомпилить.
Основано это будет на той конструкции, но она будет генериться на перле на основе xml-описания, где будут перечислены возможные классы-свойства, а потом ее инклудить в исходник дельфевый и перекомпилить.
грамотно организованная типизация и наследование призваны избежать организации геморроя.
Лучше скажи, что тебе на самом деле нужно, и дай возможность рюхам в ООП рассказать, как это правильно делать с помощью паттернов или как это у них называется.
В этом ты прав, но дело не в этом 
Дело в том, что хотелось бы описание класса засунуть в хмл, а потом в дельфи изменять свойства.
Это для расширяемости - в хмл записать новое свойство гораздо легче, чем изменять всю прогу.
Дело в том, что хотелось бы описание класса засунуть в хмл, а потом в дельфи изменять свойства.
Это для расширяемости - в хмл записать новое свойство гораздо легче, чем изменять всю прогу.
Да, можно, если в постановке задачи заменить слово класс, на слово компонент. Можно загрузить компонент из DLL (при этом название DLL и тем более название компонента может быть неизвестно на этапе компиляции создать экзампляр этого компонента, узнать названия и типы его полей, изменять их и т.п. Именно это и делает сама система Delphi (кстати написанная на Delphi когда ты добавляешь в палитру компонентов новый компонент. Как конкретно это делать, должно быть написано в документации. А вообще, использование в программах такого рода приёмов обычно является признаком плохого проектирования.
make & automake; delphi & autodelphi
Плохое-не плохое, но и готу тоже может быть полезен, правда крайне редко (когда его использование скажем заменяет пару десятков строк кода и усложнение структуры - нагромождение ифоф, циклов...). Помнится в паскале была как-то фича - дальний готу, когда можно было ставить что-то вроде чекпойнта и потом на него прыгать.
Значит, класс должен быть наследником Tcomponent? А где это в документации, не скажешь? Она большая, копаться в поисках ох как надоело
Значит, класс должен быть наследником Tcomponent? А где это в документации, не скажешь? Она большая, копаться в поисках ох как надоело
не понял тебя я
Маза если хочешь получить полезный ответ, опиши задачу и напиши, как бы ты её закодировал, если бы в языке были нужные фичи.
нужные фичи? а-ля перл :
$obj = eval( "$TypeName.create");
eval( "obj.$propname = \$value;);
Почему бы в следующей версии компилятора обжект паскаля не осуществить евал?..
а-ля перл :$obj = eval( "$TypeName.create");
eval( "obj.$propname = \$value;);
Почему бы в следующей версии компилятора обжект паскаля не осуществить евал?..
> нужные фичи? а-ля перл :
это понятно; повторяю вопрос: для какой задачи и как ты собирался это использовать?
> Почему бы в следующей версии компилятора обжект паскаля не осуществить евал?..
потому что smalltalk давно уже есть
это понятно; повторяю вопрос: для какой задачи и как ты собирался это использовать?
> Почему бы в следующей версии компилятора обжект паскаля не осуществить евал?..
потому что smalltalk давно уже есть
Ладно, тогда попробую формализовать поконкретнее.
Есть внешний хмл, в нем описаны типы (их имена, какие свойства они содержат); но - сами эти типы реализованы в поставляемом модуле (то есть хмл - описание этой библиотеки интерфейс, набор методов известен и меняться не может. То есть расширение может происходить только по свойствам и типам (нужен тип - в хмл пишем, от какого абстрактного наследуется).
Далее хочется сотворить виндовый интерфейс - дерево свойств, где в узле-свойстве можно задавать его значение, а в узле-методы - кнопочка, его вызывающая.
Вроде это требуется - пока творчество мысли, основная задача - прога-автоматический тестер библиотеки. Вот я хочу, чтобы можно было библиотеку расширять, и при этом вносить минимум изменений в исходники проги.
Есть внешний хмл, в нем описаны типы (их имена, какие свойства они содержат); но - сами эти типы реализованы в поставляемом модуле (то есть хмл - описание этой библиотеки интерфейс, набор методов известен и меняться не может. То есть расширение может происходить только по свойствам и типам (нужен тип - в хмл пишем, от какого абстрактного наследуется).
Далее хочется сотворить виндовый интерфейс - дерево свойств, где в узле-свойстве можно задавать его значение, а в узле-методы - кнопочка, его вызывающая.
Вроде это требуется - пока творчество мысли, основная задача - прога-автоматический тестер библиотеки. Вот я хочу, чтобы можно было библиотеку расширять, и при этом вносить минимум изменений в исходники проги.
> Почему бы в следующей версии компилятора обжект паскаля не осуществить евал?..
Потому, что eval возможет только в интерпретаторах. Встраивание eval в Object Pascal, потребует встраивания компилятора Object Pascal, в каждый исполяемый файл, использующий eval!
Потому, что eval возможет только в интерпретаторах. Встраивание eval в Object Pascal, потребует встраивания компилятора Object Pascal, в каждый исполяемый файл, использующий eval!
Описанная задача решается без использования eval на основе хорошо известной и многократно опробованной системы pluginов.
а обязательно ли встраивать компилятор в каждый исполняемый файл? пускай будет известно, что на компе, где исполняется, компилятор есть
большой проблемы, честно говоря, не вижу
хотя я конечно не занимаюсь разработкой компиляторов я их использую 
большой проблемы, честно говоря, не вижу
хотя я конечно не занимаюсь разработкой компиляторов
я их использую расскажи подробнее
не сталкивался
не сталкивался
> но и готу тоже может быть полезен
В языках типа C goto незаменим. Есть языки, в которых без goto вполне можно обойтись, не жертвуя размером программы. Например в тех языках, где грамотно реализованы исключения.
В языках типа C goto незаменим. Есть языки, в которых без goto вполне можно обойтись, не жертвуя размером программы. Например в тех языках, где грамотно реализованы исключения.
Ааа...
Ну тогда запуск внешнего компилятора из скрипта - IMHO самое прямое и надёжное решение.
Ну тогда запуск внешнего компилятора из скрипта - IMHO самое прямое и надёжное решение.
а что, в с исключения плохо реализованы?
Что за языки ты имеешь виду?
Что за языки ты имеешь виду?
> а что, в с исключения плохо реализованы?
Они там вообще не реализованы (по крайней мере в последней версии стандарта про них ни слова)
> Что за языки ты имеешь виду?
Java
Они там вообще не реализованы (по крайней мере в последней версии стандарта про них ни слова)
> Что за языки ты имеешь виду?
Java
Так ты имел в виду с без плюсов? Тогда да, но ведь это вчершний день, с плюсами гораздо удобнее.
А с явой знаком плохо, но вед в ней евала тоже нет?
А с явой знаком плохо, но вед в ней евала тоже нет?
> по крайней мере в последней версии стандарта
Задавив в себе природную скромность, вопрошу: "Неужели ты прочитал документ по той сцылке?"
Задавив в себе природную скромность, вопрошу: "Неужели ты прочитал документ по той сцылке?"
> Так ты имел в виду с без плюсов?
Да
> с плюсами гораздо удобнее
Не спорю. Я только сказал, что в C goto незаменим. Я не говорил, что C удобнее, чем C++
> А с явой знаком плохо, но вед в ней евала тоже нет?
Нет, и не может быть по той же самой причине. Java -- компилируемый язык.
Да
> с плюсами гораздо удобнее
Не спорю. Я только сказал, что в C goto незаменим. Я не говорил, что C удобнее, чем C++
> А с явой знаком плохо, но вед в ней евала тоже нет?
Нет, и не может быть по той же самой причине. Java -- компилируемый язык.
С++ вчерашний день, а С живет и здравствует.
Для динамического вызова методов необязательно, чтобы язык был интерпретируемым. COM и .NET умеют это. Правда все равно это уродски выглядит, если интерфейс заранее не известен.
Для динамического вызова методов необязательно, чтобы язык был интерпретируемым. COM и .NET умеют это. Правда все равно это уродски выглядит, если интерфейс заранее не известен.
Ну и как сделать-то?
Хотя с комом связываться неохота...
Но если не слишком сложно, то можно
Хотя с комом связываться неохота...
Но если не слишком сложно, то можно
В данном случае COM использовать крайне нецелесообразно. Для автоматического тестирования лучше всего написать прогу, которая будет генерировать тест по твоему xml. Если бы твоя библиотека была под .NET, то можно бы ло бы обойтись и без промежуточного этапа и вообще без xml.
Генерировать тест?
Об этом я тоже думал, но тогда ведь придется генерить паскалевский исходник, потом его компилить и запускать.
Еще геморнее.
Об этом я тоже думал, но тогда ведь придется генерить паскалевский исходник, потом его компилить и запускать.
Еще геморнее.
> генерить паскалевский исходник
по шаблону - одна строчка
> потом его компилить
одна строчка
> и запускать.
одна строчка
итого - три строчки, гемора нет
по шаблону - одна строчка
> потом его компилить
одна строчка
> и запускать.
одна строчка
итого - три строчки, гемора нет
>по шаблону - одна строчка
Да ну?
Это что же за шаблон у тебя такой волшебный?
Результаты еще интерпретировать надо.
Это далеко не одна строчка.
Да ну?
Это что же за шаблон у тебя такой волшебный?
Результаты еще интерпретировать надо.
Это далеко не одна строчка.
> Это что же за шаблон у тебя такой волшебный?
да типа того, что ты выше написал, куда нужно подставить имя класса и имя свойства
> Результаты еще интерпретировать надо.
это надо в любом случае
да типа того, что ты выше написал, куда нужно подставить имя класса и имя свойства
> Результаты еще интерпретировать надо.
это надо в любом случае
Ну-ка поведай-ка, что это за шаблоны такие в дельфи...
И вообще, не в тему, но почему в дельфи нету шаблонов-классов?
И вообще, не в тему, но почему в дельфи нету шаблонов-классов?
слово шаблон я использовал в обобщённом смысле, т.е. текст, куда можно что-то подставить
фишка называется "поздним связыванием" и вовсю, например, используется в VB и VB.Net.
зы
Может стоит на VB посмотреть?
зы
Может стоит на VB посмотреть?
> Встраивание eval в Object Pascal, потребует встраивания компилятора Object Pascal, в каждый исполяемый файл, использующий eval!
В следующей версии Дельфей все так и будет.
В следующей версии Дельфей все так и будет.
Что такое "позднее связывание"?
А таких словей-то не знаю
Конкретно в этом случае, думаю, смотреть не стоит на вб - задание было конкретно на дельфи, да и данная библиотека - дельфевая.
А таких словей-то не знаю
Конкретно в этом случае, думаю, смотреть не стоит на вб - задание было конкретно на дельфи, да и данная библиотека - дельфевая.
Ты хочешь сказать, евал будет в дельфи?
ya.ru?text=позднее связывание ?
да. вернее в дельфи.net
> ya.ru?text=позднее связывание ?
Звучит, знаешь ли, как "пошел на хуй"
Звучит, знаешь ли, как "пошел на хуй"
такого рода задачи очень легко делать на .net-е (C# или VB.Net)
на дельфях реальным решением будет уже предложеный способ: генерировать по xml-ю дельфевые исходники.
на дельфях реальным решением будет уже предложеный способ: генерировать по xml-ю дельфевые исходники.
в двух словах у меня не получается объяснить, а на лекцию нет времени.
Ладно, черт с ней, с лекцией.
Все более склоняюсь к этой идее - сгенерить перлом куски кода, которые инклудом вставить куда надо в дельфевый проект.
Все более склоняюсь к этой идее - сгенерить перлом куски кода, которые инклудом вставить куда надо в дельфевый проект.
> Для динамического вызова методов необязательно, чтобы язык был интерпретируемым.
А при чём тут динамический вызов? Я говорил, что eval можно реализовать только в интерпретируемом языке. А динамический вызов -- это есть почти везде
А при чём тут динамический вызов? Я говорил, что eval можно реализовать только в интерпретируемом языке. А динамический вызов -- это есть почти везде
AFAIK, существует дофига вполне себе компиляторов всяких лиспов (по крайней мере не менее компиляторов, чем оные для Java причём в eval в лиспе есть, а кроме того, есть одинаковое представление для кода и данных.
Delphi позволяет создавать объекты заранее неизвестных классов, а также передавать классы в качестве параметров и проч. Это позволяет в некоторой степени получить возможности, напоминающие шаблоны в C++
Конструкция: TClassRef = class of TParentClass
Конструкция: TClassRef = class of TParentClass
В сочетании с виртуальными функциями это может дать хорошие результаты
NET не интерпретатор. Но там можно создавать свои собственные объекты прямо в программе с 0, и загружать их от куда нибудь и пользоваться потом ими, и делать с ними все, что угодно. Хотя я не знаю точно, что может eval в Perl'e, но мне кажется не больше.
AFAIK, существует дофига вполне себе компиляторов всяких лиспов (по крайней мере не менее компиляторов, чем оные для Java причём в eval в лиспе есть, а кроме того, есть одинаковое представление для кода и данных.Ну, это ничего не доказывает. Я же сам предложил способ, позволяющий реализовать eval в компилируемом языке: вставлять компилятор (или интерпретатор) этого языка в каждый исполняемый файл. Как вариант можно подключать этот компилятор (или интерпретатор) как DLL, или запускать его как внешний EXE... Суть от этого не меняется
Все более склоняюсь к этой идее - сгенерить перлом куски кода, которые инклудом вставить куда надо в дельфевый проект.Не издевайся над животным. Используй pluginы.
Да что же за плагины ты имеешь в виду?
И еще. Перловский скрипт можно компилировать в ехе. И при этом возможность евала сохраняется.
Так что не вижу ничего запретного в том, чтобы в компилируемом языке осуществить евал.
И еще. Перловский скрипт можно компилировать в ехе. И при этом возможность евала сохраняется.
Так что не вижу ничего запретного в том, чтобы в компилируемом языке осуществить евал.
Да что же за плагины ты имеешь в виду?Обычные pluginы. Мне казалось, что это устоявший термин. Попробуй например так: http://www.google.com/search?q=how%20to%20implement%20plugins%20in%20delphi
Оставить комментарий
Eugenia_2005
Вопрос - можно ли в Дельфи, то есть я имею в виду в object pascal, сделать что-нибудь аналогичное перловскому eval?То есть, более конкретно - как можно в рантайме создать объект нужного класса (имя этого класса до компиляции неизвестно присваивать его свойствам значения, если имена этих свойств до компиляции опять же не известны?
Конструкции типа "if( name='asdf') then obj.asdf:= value else ...." очень уж накладны.