NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/smalltal/2795

Text File | 1993-01-22 | 3.4 KB | 76 lines

Newsgroups: comp.lang.smalltalk
Path: sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!ticipa!ticipa.pac.sc.ti.com!tomb
From: [e-mail] (Thomas Burns)
Subject: Re: SmallTalk Products Recommendation
In-Reply-To: [e-mail]'s message of Fri, 22 Jan 1993 10: 22:37 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Texas Instruments Manufacturing Technology Center
References: <[e-mail]>
    <[e-mail]>
Date: Fri, 22 Jan 1993 15:09:35 GMT
Lines: 62

In article <[e-mail]> [e-mail] (Panu Viljamaa) writes:

   > We are currently in search of PC (Windows) and Mac based
   > (Smalltalk)

       We worked with both ObjectWorks (ParcPlace) &
    Smalltalk-V (Digitalk). Unfortunately they seem
    to be the only major players. Their systems
    (= the libraries) are not as compatible with each
    other as you would like. More or less you have to
    choose one and stick to it.

I take issue here.  We are using V/286 and OTI's V/Embedded along with
St80 for a production machine control system.  We have two distinct
flavors of the system where in one the machine control is in V and the
UI in 80, and the other has both machine control and UI coded in an
St80 environment.  The V and 80 machine control images use the same
classes with minor subclassing to define specific behavior appropriate
for each system (NOT each VM).

To top it all off, we use our own remote object communications package
and object storage/retrieval system to actively communicate between
the V and 80 systems.  Obviously, for such communication to be valid
then there must be a high degree of commonality between the systems or
an object built in ST/V (for example) will have problems being
reconstructed in St80 due to any number of reasons including instance
variable reordering or different numbers of inst vars in each image.

There are two distinct points where ST/V and St80 are at odds:
- GUI (MVC vs. MPD)
- Exception handling (and V's native lack of it)

If your code is highly GUI dependent then you might be in trouble.
From what I understand you're even in trouble between different V
platforms.  It should be noted that with a great deal of care and
careful subclassing, V and 80 code can be made very similar even in
the GUI world - if you create panes in each platform that subclass
from the native panes.  These 'translator' panes would provide a
common interface, although it would probably pretty much preclude the
use of a 'View' in St80, not to mention panes more complex than the
standard list and text panes.

We are using ENVY from OTI which allows porting between code databases
(one for V and one for 80) and handles expressions to load 80-specific
or V-specific code as appropriate for the cases where divergence is
necessary.  We did have to implement some missing protocols on each of
the platforms to get true commonality.  Things like
Character>>asLowerCase in V and #asLowercase in 80, or in V it's a
MetaClass and 80 has a Metaclass.

As far as the pros and cons of each platform, I would generally agree.
The only additional comment I would make is that if you are a student
you can get St80 relatively cheaply.

tom

--
Tom Burns                 Domain:    [e-mail]
Texas Instruments        TI MSG:    THOS
P.O. Box 655012, M/S 463     Voice:       [phone]
Dallas, TX   75265