In article <··················@fred.flw.att.com> ·····@fred.flw.att.com (Wayne Hyatt) writes:
In article <··········@netnews.upenn.edu> ·······@sb.com (Chris) writes:
As I asked in another post, what can you do with Dylan that you *cannot*
do in C++, ObjectPascal (which seems to be trying to make a comeback
in Delphi), or Objective-C or (smalltalk?)??
....
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.
If you're wondering how this would be useful, a contrived but possibly
illustrative example would be a "meta" database administration
platform which provided complete GUI support for displaying and
modifying object-oriented database entities with an application-
defined schema. I could then use this platform to develop an
application for administering a local area network. I would provide
the class definitions and associated methods based on my
[hypothetical] expertise and experience to make my application useful
to my customers. The end user of the product would supply a
description of a particular LAN configuration using various classes
defined by my application. The "meta" database platform would
instantiate the configuration entities for me. It could also allow
the end user to modify those entities, verifying that the entities
conform to the schema as defined by my application.
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.
By the way, the static-language OODB I'm most familiar with is
ObjectStore. I'm very impressed with what they've been able to do
along these lines to use C++ class definitions to define a schema.
But when I compare how well the result fits in with C++ on the one
hand to how well AllegroStore (the dynamic-language OODB I'm most
familiar with) fits with Common Lisp, I find that the comparison
underscores the difference between static and dynamic languages as far
as their suitability for developing reusable platforms.
Wayne Hyatt
(Speaking for myself only)
·····@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.
Apple's Object Pascal lets you do this, and MacApp makes extensive use
of it to create view resources from data descriptions.
The C++ version of MacApp needs programmer help to do this, but in the
Pascal version it's done entirely by the compiler. I'm not familiar
enough with the new ANSI C++ RTTI (Run Time Type Information) features
to know how much they help with this.
So there's nothing about static (object-oriented) languages that prevent
this -- it's just that the usual implementations don't support it.
-- Bruce