NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/mac/programm/19893

Text File | 1992-12-16 | 8.8 KB | 203 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!stanford.edu!leland.Stanford.EDU!Ramon.M.Felciano
From: [e-mail] (Ramon M. Felciano)
Subject: News on Bedrock
Message-ID: <[e-mail]>
X-Posted-From: [e-mail]
Sender: [e-mail] (Mr News)
Organization: Stanford University Medical Media and Information
 Technologies
Date: Wed, 16 Dec 92 06:34:04 GMT
Xdisclaimer: No attempt was made to authenticate the sender's name.
Lines: 189


Hi all --

I just came from a meeting of the Software Entrepreneurs Forum at Apple
where they had a rep from Symantec talking about Bedrock. Nothing
dramatic was revealed (surprise), but it was a sobering experience. I
thought I'd through out some of the salient points I remember.

I know you're all dying to hear about this, but I'd like to point out
that (1) this is still subject to change, and (2) I didn't take any
notes, so I may be wrong on some counts -- I'm doing my best :)

The first part of the talk was given by an Apple guy who, until
recently, was Apple's rep in the joint venture. The feeling I got from
his slides was that Apple was trying very hard to make it seem like
they were bringing a whole lot to the project, but underneath it all,
it was Symantec who came up with it, Symantec is doing most of the
work, and Symtantec will probably do most of the sales.


Overview
========
Bedrock is made up of 3 parts:

Class Library
-------------
A C++ class libary which is a mix between MacApp and TCL. MacApp will
continue to get bug fixes, but no new releases. TCL will continue to be
a supported product as Symantec doesn't necessarily see them as being
in competition (probably because of the size of the environment).
Bedrock has alot of TCL similarities (Views, Bureaucrats, and some
others). I think there are about 150+ classes so far. They didn't show
us any details (surprise), but some of the categories included graphics
primitives (lines, arcs), text, and others.

I was disappointed that there weren't any obvious facilities for
creating new interface elements (that is, is drag-and-drop as basic a
function under Bedrock as clicking?)

While Bedrock does share a large number of similarities between MacApp
and TCL, porting your code will not be a "no-brainer" (their words). It
does seem, however, that TCL has a longer life expectancy than MacApp
as far as continuing development goes...

Resource Manager
----------------
Basically a cross-platform Rez language. Describes visual interface and
(I believe) objects as well. Should let you subclass / dynamically
create new kinds of objects at runtime, although it wasn't quite clear
how this would work.

Utilities Manager
-----------------
They made a big deal about how Bedrock was geared towards developing
world-ready software. They've essentially implemented a bunch of
internationalization tools (like 7.1's date and numbers control panels)
to support different languages. These are actually libraries that exist
today and that will have class wrappers around them. Why they don't
simply release them today wasn't quite clear to me :)

They didn't talk about the whole Font and Script stuff either.

They did mention that they had their own approach to File and Memory
management. The former gives you a common way to refer to files across
platforms; the later gets you away from these stupid handles (still
pointer based).


Other notes
===========
Platforms
---------
Will initially run on Windows and Mac. UNIX is probably the next
target, but that's a ways off. Should be compilable under MPW and the
(pretty definite although not confirmed) C++ version of THINK C, as
well as Zortech and Microsoft's C environments on the Windows side.

Licensing
---------
They're not clear on how they will approach it. Most everyone agreed
that individual runtime licensing would doom the product. The rep
understood that, but seemed to indicate that the alternative was a 10K
or higher price tag. This met with general grumbles, but no major
protests.

Competition
-----------
They currently see their biggest competitor as being XVT. I've got
mixed feelings about this. My roommate has worked extensively with XVT
and says it is the best cross-platform tool currently available, but
the Mac versions that it spits out still look terrible. Since Bedrock's
classes seem to isolate from Quickdraw and the other toolbox goodies
that allow us to make our Mac apps so cool, I'm not to hopeful about
what Bedrock apps look like :(.

No mention about Quorum, either. I happen to think Quorum's product is
totally cool, especially since I've actually seen it work.

Microsoft
---------
There was a manager from Microsoft's development tools group there who
reminded us about the Windows for Mac Programmers conference in
January. He seemed quite supportive of Bedrock, as well as any of the
other cross-platform tools: their goal is simply to get as many Windows
apps up as possible.


Problems
========
Here's a couple of the problems I saw.

Apple Object Model
------------------
There was no clear support for this within Bedrock, even though Apple
seems to be pushing this as the way to think about and develop
applications. It forces you to implement your program using
well-defined object definitions (the AE suites). This, in turn, makes
you app modular, apple-event savvy, and dying to be script driven. It
is a cool, albeit somewhat foreign, approach to development that is in
danger of being swept under the rug if Bedrock doesn't embrace it.

System Software Support
-----------------------
It wasn't clear how Apple's system software would fit into this. There
will definitely be support on the Macintosh side for any new toolboxes
(e.g. Quickdraw GX, OCE), but if a Windows version isn't there at the
same time, what's the point of porting? Yug.

A whole new system to learn
---------------------------
It still seemed like you'd need to learn the Mac toolbox, some windows
stuff, plus the entire 150+ class library. Yich. Contrast this to
Quorum ans some other porting facilities that simply grab the Mac
toolbox and re-implement it on other platforms.


Soapbox
=======
It really seems that the current approach to OOP isn't delivering its
promises. Eiffel and Smalltalk do better, but they have different
programming environments. Neither of the speakers mentioned any
dramatic changes in the environments we'll be using to program in. The
Apple said that Bedrock sort of tried to fit into the chasm between
Hypercard and C, but I'm not convinced :) My vision of this project is
more along the lines of a blend between a conventional compiled
language and an interpreted language. It seems that many of the
promises of OOP fall apart when forced into a conventional C (or Pascal
or what have you) development environment.

A major point of Bedrock is that it is a Framework that basically
implements the functionality that is similar to all Mac programs
(windows, dialogs, buttons, menus, etc. as well as dragging, apple
events, etc.). Well, that was what TCL and MacApp were supposed to be.
The big problem there is that every app you create carries this
Framework around as luggage. It seems to me that there should be a
default application framework that is always active and is part of the
system software. Your application essentially registers itself to the
"application manager" (or some such) and only implements the stuff
specific to your app.

Further more, while I support the premise and theories behind OOP, they
really don't fit into a conventional, file-based programming
environment. For example, why do we need to have "includes" or "USES"
clauses in an OOP environment? There should be a big object database
behind the scenes -- we just call up whatever objects we want, and the
extra ones are stripped out at compile time. All files could go away.

Furthermore, we should be able to edit and incrementally compile any
particular part of the program, and test it out right away. This is
obviously feasible (check out MCL or some if its offspring).

Another place where many of the existing "frameworks" seem to fall
short is blending interface and data objects. It is often awkward to
implement the two separately and link them later on. Ideally, we should
edit the interface by manipulating it directly. Then edit the engine
using a data structure or class hierarchy browser (or some other
visualization device -- an area begging for some good CHI research).
Then link the two by drag-and-drop or drawing lines between the two.

Anyway. Enough rambling. Hope this helps some of you somehow. Feel free
to send me mail if you have any questions :)

Ramon

+----------------------------------------------------------------+
| Ramon M. Felciano                [e-mail]  |
| Associate Director, SUMMIT       [phone]                |
| Stanford University Medical Media and Information Technologies |
+----------------------------------------------------------------+