From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Obj-C front for BC++ (was Re: Pros and cons of C++)
Date: 22 Jan 93 07:57:04 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

kocks@leland.Stanford.EDU (Peter Kocks) writes:
: In article <KERS.93Jan14092820@cdollin.hpl.hp.com>, kers@hplb.hpl.hp.com (Chris Dollin) writes:
:     >Why would you ever want to run a program with a type error in it?
: 
: It is not that I wan to run a program with a type error, but rather I may want
: to interact with another applications objects without knowing their type. 
: Strong type checking makes this difficult.  Weak type checking (like in Obj-C)
: makes this easy.  That is why NeXT uses Obj-C in their interface builder.  You
: can dynamically add objects created by other vendors into the interface builder
: and the connect them, without knowing if all the types match correctly.  Also
: your application can be designed to message other applications, without knowing
: what type the messaged application's object is. 

No these things always have a type. It's just that in the most
general case the things is an $OB, to use Sather's notation.  Which means
an OB (root class), or any of its descendants, (the $).

: In the future messaging between objects in different applications will become
: more common.  In C++ this will create the need to define how that messaging
: system will work.  The messaging system will employ some form of runtime
: checking that will likely  be system depedent.   That is, MS will define its
: own messaging system and Apple will define another.  This has probably already
: happened.  If we all used Obj_C, this would be a lot easier (but not without
: some problems).

This is an even harder problem. The question is of *interapplication*
type conformance.  If you don't have the source of those programs,
there's no way you can do it, unless the objects they pass back
and forth are those defined in some standard library.  And then they
have to make sure the internal type-tags are consistent across applications.
I have no idea how to do that.

: Summary.  C++ is easier to for the developer to use now, but creates headaches
: in the future.  Obj_C does not provide type checking making the developers job
: harder now, but easier in the future.

I think OC is certainly superior to C++, but overall I'm a Sather bigot.
You want static typing?  Say this
   thing : TYPE;

The thing is type "TYPE".

you want dynamic typing? Say this
   thing : $TYPE;

The thing is type TYPE, or any of TYPE's subclasses. 
That's it.  It's very nice as you can specify static types when
you need the speed, or use dynamic types when you want the flexibility---
WITHOUT changing the class one single bit. (pun intended)  All classes
can be used dynamically or statically.

The new Sather spec allows 'typecasing', which enables one to check
whether objects are of specific types and then do specific things with them,
without violating global type consitency. This way you, the programmer,
can check the types yourself first before using the thing for anything,
and if it checks out, you can assign that object to a variable of
a definite specific class, with a guarantee that it's really that type.
(saves time!).

: --Peter Kocks
:   kocks@chemistry.stanford.edu

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
Newsgroups: comp.lang.c++