Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!chi-news.cic.net!nntp.coast.net!torn!nott!cunews!tina.mrco.carleton.ca!knight
From: knight@mrco.carleton.ca (Alan Knight)
Subject: Re: Why is VisualWorks SO complicated?
X-Nntp-Posting-Host: tina.mrco.carleton.ca
Message-ID: <knight.820685032@tina.mrco.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: The Object People
References: <4ccumk$ldv@news2.ios.com>
Date: Wed, 3 Jan 1996 16:03:52 GMT
Lines: 60

In <4ccumk$ldv@news2.ios.com> vlad@gramercy.ios.com (vlad) writes:
>But what I don't understand is why the VW has it's own windowing
>system? It is a complete nonsense. Why do we have VW classes that
...
>It should be simply accomplished by sending request (be it a function
>call or a message) to the windowing system (for example Windows 95)
> to display our scrollbar. Everything is already implemented in native
>windowing systems, why is that redundant functionality implemented 
>in VW once again? 

The primary reasons are historical. Smalltalk predates most windowing
systems. It's not so much that Smalltalk is duplicating their
functionality as the other way around :-)

There are also some advantages to doing the windowing yourself. It is
more portable than using native widgets, and often less restrictive
(@#!#$@ windows list boxes won't hold more than 64K characters...). On
the other hand, it's a lot of work for them to maintain that code,
it's more restrictive in other cases (@#$@#$! controllers) and it's
harder to take advantage of other people's work. For this reason,
ParcPlace has been working for a while on using native widgets. They
were working on it before the merger, but now they're working on
integrating with Digitalk's native widgets. 

>I am now hearing crowds of people yelling that it is because of a
>multiplatform portability.  >Another nonsense. The multiplatform
portability can be achieved by >special "layer" (OO or not) that
receive requests from the Smalltalk >application and translate those
requests to native requests sent to >the specific platform.

This is the approach that IBM takes. It does work well, but is also
not ideal. You often see people complaining that it doesn't have quite
the right look and feel for windows, and it must somehow reflect IBM's
OS/2 bias (which isn't true, it's a Motif-based layer). This is more
or less the way I expect PPD's native widget support to work. 

> It works well with database access, why not >with the usern
>interfaces?

It works adequately with database access. ODBC works, but a lot of
people avoid using it because they want to be able to take advantage
of database-specific features that aren't supported.

>Another question:
>  I have read somewhere that the merge of the ParkPlace and Digitalk
>will strengthen the Smalltalk even more.
>I wonder HOW?

While no-one really knows what the combined result will be, it is
clear that both ParcPlace and Digitalk had important elements that the
other one was missing. If they can really produce something that has
the best of both worlds, it will be quite an amazing product. If they
produce the worst of both worlds, we'll have a problem :-)

-- 
 Alan Knight                | The Object People
 knight@acm.org             | Smalltalk and OO Training and Consulting
 alan@objectpeople.on.ca    | 509-885 Meadowlands Dr.
 +1 613 225 8812            | Ottawa, Canada, K2C 3N2

