DR>
  > (persistence, RTTI, object formatting (binary and text), standard
  > message logging mechanisms, standard exception throwing
  > mechanisms, ect... cannot be extended over a SOM system composed
  > of bits and pieces of code written in different languages (because
  > those languages do not support such mechanisms.)
DR>

  Tough luck.  That's not a problem with SOM.  It's a problem with the
  number of different languages that you've chosen to use.  So be fair.
  If you want those features, use languages that provide them.  If you
  use languages that don't provide them, then do without the features.

  SOM is just a foundation, providing a language-neutral implementation
  for such stuff.  There's nothing saying that every language in the
  world has to provide RTTI just because those that do are able to use
  SOM to implement it.

  In the particular case I was talking about, SOM solves a problem that
  is currently insoluble in C++, because C++ class implementations from
  two different compilers are incompatible; whereas by using SOM instead
  of the vendor-supplied runtimes, class libraries from two different
  compilers should be compatible.

  Providing a language-neutral class/object runtime is what SOM was
  designed for.  It wasn't designed to change the paradigms that those
  languages use, just make the implementation consistent so that two
  languages using the same paradigm can talk to each another.

DR>
  > I see SOM as a great way to implement the little productivity and
  > desktop goodies for OS/2 (as it is now), but it will be a long
  > time before serious system can be implemented under such a system.
DR>

  You use a tool to attempt to perform a task that it wasn't intended to
  perform, and then you complain about the tool.

DR>
  > I see something like Taligent, which offers much of the same
  > capability to piece together components but with the added
  > advantage of it being a single language (cohesive, coherent)
  > system, which DOES define many of the needed standards (though
  > maybe not enough of them.)
DR>

  Taligent's *major* problem is that it is strongly tied to C++.  Word
  from the horse's mouth has is that it will not be released with any
  other interface apart from the C++ one.  I've asked about language
  neutral bindings, and been told "no".

  This is not useful for the programmer who wants to use REXX, Visual
  BASIC, Smalltalk, PL-I, MODULA, JOT, or any other language to write
  their Taligent applications.

  This has come as a severe disappointment to me.  Taligent has gone
  from being "Object Utopia" to being just another cross-platform C++
  class library, albeit a larger one than most.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 2.01wb