In article <··················@fred.flw.att.com> ·····@fred.flw.att.com (Wayne Hyatt) writes:
For a more concise example, it is trivial in dynamic languages such as
Dylan and Common Lisp (and probably Smalltalk) to provide library or
platform software to construct instances of application-defined
classes according to a user-supplied configuration. Dynamic languages
make it trivial because they provide constructs to instantiate a class
whose *name* is supplied at run-time.
Static languages only allow code to instantiate classes known at
compile-time. They do not preserve enough information in the run-time
environment to do otherwise.
[...]
To the best of my knowledge, the only way to do this for application
classes defined with a static language is with extensive (and, in my
opinion, awkward) use of macro preprocessing to generate source code.
This takes far more work than the trivial implementations that are
sufficient in dynamic languages.
The way to do this in a static language like C++ is to do what Lisp
does: Make runtime objects which represent classes, slots, and so on,
and have these objects point to the appropriate instantiation and
initialization functions, methods, and so on. The difference is that
C++ and other static languages don't do it by default and you have to
spend a lot of annoying time constructing and maintaining the runtime
model. Some C++ frameworks come with support for such runtime models
built in --- the best example is probably Microsoft's MFC. It's true
that such models typically use macros to declare information, but
then...so does Lisp. After all, what is defclass?
That said, it's pretty obvious that the Lisp way of doing things is
far simpler for everyone concerned.
-- Harley
--
------------------------------------------------------------------------------
Harley Davis net: ·····@ilog.fr
ILOG S.A. tel: +33 1 46 63 66 66
2 Avenue Galli�ni, BP 85 fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France url: http://www.ilog.com/
Ilog Talk information: ····@ilog.com