Grant Black wrote:
> imagine in a few years when you get a few thousand lines of perl tying

One would hope your 'scripts' are not reaching the thousand lines of
code area, if so then its a very complex piece of script, or theres
something wrong with the main application :)
> If your DLL's work then why not stick with them? - as MS have proven,
> bloatware is no barrier to success and 150K DLL's is not exactly a worry
> when your target machines probably have 10Mb+ of wallpaper alone.

The problem with the DLL's - is that for what they do, having to
maintain seperate delphi projects, editing the code, compiling etc. etc.
is a pain in the butt for changing the behavior, or adding new behavior
to the system.  Plus I don't expect the clients to have Delphi, or
another development platform that will make it easy for them to add new
plugins etc. etc.

> Also take a look at TCL/TK for scripting - we have experimented with it
> as you can load a script that constructs the UI on the fly & calls DLL's

I've often wanted to look into TCL for scripting, not neccesarily using
the TK extensions thou.  Unfortunately there doesn't seem to be much
information availble for integrated it with Delphi.  I know several
people writing major applications using TCL/TK as both the front-end,
and back-end.  The most prominent that come to mind are two IRC clients:
Zircon and IraCa.

> Looks like a powerful concept and there are some good example of the
> approach in the OpenSource world where people take things like a GNU C++

The problem with scripted systems, if that often they get used too much
for things they're not designed for, or not appropriate for.

    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]

Reply via email to