Thanks Jonathan for your msg about Som Of The Time, on 12
10-12-1994

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

You're missing the point. A system such as SOM means that
(potentially) I can't know the language in which a particular
widget is implemented in. It's whole point for being is that I can
plug in widgets provided for me by third parties. If I have to
force them to build the SOM widget in C++ in order to have it work
inside my application, then what good was it to begin with????

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

Yes, that it is its overridding advantage. My question is whether
giving up all of the massive benefits and magically integrated
code you can get from a fully C++ or fully Smalltalk system worth
it?

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

Thats true. And that was my point against it. Many of the very
advanced mechanism that can be universally implemented in a fully
C++ or Smalltalk environment  cannot be provided consistently
across a system implemented out of SOM widgets. So, can you really
build a robust system under those constraints without writing all
the code in your application from scratch, an idea inconsistent
with the aims of SOM.

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

Thats certainly not true. One of the next Taligent betas
(although the one that was just released) will be based upon SOM
(using CSet/2++'s 'direct to som' interface. So it is going to be
the root of ANY Taligent based system. Taligent is certainly
intended as an implementation platform for large, serious
applications.

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

The previous comment addresses this also. The reason (as I see
it) that Taligent (even though implemented over SOM) cannot allow
other languages, is that it depends upon the exact same large
scale architectural mechanism I have just discussed in order to
provide the kind of highly integrated system that it is. Basically
any language which cannot throw exceptions (or catch them) will
never be able to integrate into a system which fundamentally
depends upon that mechnasm (and any serious C++ system definitely
would depend upon such a mechanism given its massive advandages.)

JP> 
JP>   This is not useful for the programmer who wants to use REXX, Visual
JP>   BASIC, Smalltalk, PL-I, MODULA, JOT, or any other language to write
JP>   their Taligent applications.
JP> 
JP>   This has come as a severe disappointment to me.  Taligent has gone
JP>   from being "Object Utopia" to being just another
cross-platform C++
JP>   class library, albeit a larger one than most.
JP> 

I sympathize, but its just a reality that cannot be gotten
around. Being heavily into a large C++ class library system, I
have seen the light. Although it does not have to be C++
necessarily, any such system which has pretentions of creating the
kind of environment that Taligent does, cannot be built of a bunch
of little widgets that don't know a lot about each other in any
fundamental sense. I personally think C++ has many shortcomings,
but most of them were in its trying to remain C compatible.
Something like an Objective C might be a better choice, but C++
seems to have the momentum at this time.

___
 X KWQ/2 1.2b X I'm an OS/2 developer...I don't NEED a life!

--- Maximus/2 2.01wb