HDTenEightyP/NetNews huggingface dataset:
From: timm@void.ncsa.uiuc.edu (Tim McClarren)
Newsgroups: comp.lang.objective-c
Subject: Re: Objective-C vs. C++
Date: 28 Aug 92 17:30:52 GMT
Article-I.D.: void.timm.715023052
Distribution: usa
Organization: University of Illinois at Urbana

pfkeb@kaon.SLAC.Stanford.EDU (Paul Kunz) writes:


>   But when your objects are bigger, like windows, buttons, sliders, 
>and other controls of an applications, the easy to learn Objective-C
>language is more than adequate.   Also the very late binding, and
>lack of compile time checking allows techniques such as delegation
>to be easily implemented.

No, Objective C has compile time type checking, if that's the type
of checking you are referring to.

>   It is easy to conceive of an application that has a C++ computation
>kernal with an Objective-C GUI.  All you need is the ultimate
>language: Objective-C++.  What is Objective-C++?  Well if Objective-C
>is a layer on top of C, the Objective-C++ is a layer on top of C++.
>And it is available today from your GNU sources or any NeXT machine.

Uh, not quite.  I wouldn't term what the GNU compile supplied with
the NeXT does as Objective-C++.  The two don't mix as freely as you're
implying.

-- 
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
timm@ncsa.uiuc.edu|
(217)244-0015     |
Newsgroups: comp.lang.objective-c,gnu.misc.discuss
From: dws@cseg03.uark.edu (David W. Summers)
Subject: Re: PD Implementation?
Organization: University of Arkansas
Date: Fri, 28 Aug 1992 03:32:47 GMT

wiml@milton.u.washington.edu (William Lewis) writes:

>  I'm waiting for GNU-ObjC to appear so I can duplicate the NeXTstep
>programming environment for X. With, of course, a few changes
>in the hierarchy. (BTW, if anyone else is also thinking of this,
>I'd be interested in exchanging ideas with you via email... there
>are a few things in NS that I really think could be improved in 
>a ground-up rewrite.)
>
>-- 
>email: wiml@u.washington.edu             |  Home:  Seattle, Washington   |
>     (William Lewis)                     |  47 41' 15" N   122 42' 58" W | 
>NeXTmail: wiml@ingalls.cs.washington.edu `-------------------------------'
>        --*-- Member, Coalition to Preserve Semantic Vacuity --*--

Cool!  Now, can I ask a dumb question?  (I've only been working with C++
for 8 or 9 months and know next to nothing about Objective-C).

What are the main differences between C++ and Objective-C?  Could you write
the same sort of things in C++ (G++) ???  Or is it mostly a matter of
source code compatability with Next that causes you to want to write it
in Objective-C?

Thanks for answering some probably stupid questions.


   - David Summers
   (dws@engr.uark.edu)

-- 
                         "Never under-estimate the bandwidth of a station-wagon
David Summers             full of tapes, hurtling down the highway."
dws@engr.uark.edu         - Tanenbaum, "Computer Networks"
From: kane@cs.purdue.edu (Christopher Kane)
Newsgroups: comp.lang.objective-c
Subject: Re: instance variable declarations..
Date: 30 Aug 92 18:38:23 GMT
Organization: Purdue University Department of Computer Sciences


In article <MAS.92Aug30121306@csa.bu.edu>, mas@csa.bu.edu writes:
> Why is it that instance variables are declared in an object's
> @interface portion (interface file) while an object's method's are in
> the @implementation portion (implementation file)?

(dumb) Reason #1: Because if you don't put the instance variables in
  the @interface, and you put them in the @implementation portion,
  you will probably get errors from your compiler.
  (mine says: 'inconsistent instance variable specification', and
   claims that the instance variables used in the methods in the
   @implementation section are 'undeclared').

Reason #2: Brad Cox designed Objective-C to require the instance
  variables in the @interface; putting them in the @implemenation
  is just for convenience.

  From _Object_Oriented_Programming:_An_Evolutionary_Approach_, 
  Brad J. Cox and Andrew J. Novobilski, 2nd ed., page 89:
  (quoted without permission)

        I find it convenient to provide all superclass and instance
      variable information in both files, even though Objective-C
      only requires this information in the interface file.  If you
      adhere to the first philosophy, you may omit the superclass
      and instance variable information from your implementation
      file, and will therefore need to read source code across two
      files.  By duplicating the information about instance variables
      and superclass information, it is available in the same file
      with the methods.  When the information is present in both
      files, the compiler requires that it match exactly.        


> I had kind of pictured the interface file as akin to a prototypes
> file, while the implementation file contained the actual code.  Since
> instance variables are private data, it seems to me that they should
> be declared in the implementation file (along with the methods) rather
> than the interface file.

Subclasses of a class need to have the instance variable information
for the class as well, so the @interface section is the most convenient
place to put them.

I (partially) feel the way you do, though.  There are sometimes 
instance variables in a class which a subclass should not modify,
either because consistancy between several variables is necessary,
or the variable is a relatively complex data structure (eg, a linked
list) of which you don't want to document the internals, or is
simply private (in some way of thinking) to the class and subclasses
should not need to "know" about it (in the way that methods not listed
in the interface file are not "known", but are inherited as usual).
Where necessary, the class should provide methods, which the subclass
should use, to access these types of instance variables.

Indexed instance variables may be the solution here; I have never
attempted to use that facility.  It seems to be more trouble than
it is really worth.

Christopher Kane
kane@cs.purdue.edu
From: rpomeroy@aunext3.cam.amd.com (Ron Pomeroy x(Coop))
Newsgroups: comp.lang.objective-c
Subject: Re: Objective C library, Free Software Foundation
Date: 2 Sep 92 15:00:44 GMT
Reply-To: rpomeroy@aunext3.cam.amd.com
Distribution: usa
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <1992Sep1.204045.42152@ns1.cc.lehigh.edu> gdb0@ns1.cc.lehigh.edu  
(GLENN BLANK) writes:
>>In article <BtLso6.5H4@world.std.com>, gsk@world.std.com (Geoffrey S Knauth)  
writes:
>>>Quick Status
>>>------------
>>>There have been several dozen positive responses (zero negative) to
>>>the idea of creating a free software library containing Objective C.
>>>
>>>This is for you, the public.  If you want to be heard, climb aboard.
>>
>>Let me add another positive response.  A FSF library could stimulate
>>the popularity of Objective-C, and get more folks involved in adding
>>features and libraries that folks need and would be easier to support
>>in Objective-C than C++.  For example, garbage collection and persistence.
>>
>>Will the FSF version provide something analogous to Stepstone's
>>foundation class library or any of Next's library or will these
>>be add-ons?

For the last few months I've been using both Objective-C on the NeXT and  
SmallTalk\ObjectWorks on various platforms.  My conclusions ?  NeXT smokes  
everyone when it comes to the GUI classes, but is sorely lacking when it comes  
to data modeling classes (i.e. Set, Bag, SequenceableCollection, Collection,  
SortedCollection, OrderedCollection, Array, etc. etc. etc....the list is long)  
like we find in SmallTalk.  What I would love to see is equivalents to these on  
the Obj-C side.  FSF seems like the one to do the job :-)
--
Ronald Pomeroy
Advanced Micro Devices
CAM Applications Group
rpomeroy@aunext3.amd.com
From: rpomeroy@aunext3.cam.amd.com (Ron Pomeroy x(Coop))
Newsgroups: comp.lang.objective-c
Subject: Re: Objective-C vs. C++
Date: 25 Aug 92 18:24:16 GMT
Reply-To: rpomeroy@aunext3.cam.amd.com
Distribution: usa
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <timm.714755187@void> timm@void.ncsa.uiuc.edu (Tim McClarren)  
writes:
>>andy@uh.msc.edu (Andrew Hollenbeck) writes:
>>
>>>I've used C++ and would like to know what distinguishes Objective-C from  
C++. 
>>>The Objective-C FAQ (Q6/A6) only indicates features that C++ contains that
>>>Objective-C lacks.  What features of Objective-C make it "better"?
>>
>>>C++ is certainly more popular, but that doesn't necessarily mean that it is
>>>better.  You can walk into any bookstore and find a couple dozen C++ books,  
but I
>>>have yet to find a single Objective-C book in those stores.
>>
>>There aren't any decent Objective books...don't waste your money on
>>the Weiner and Pinson book.  It's terrible.
>>
>>Anyways, the one main characteristic that distinguishes Objective from
>>C++ is in the way that they do dispatch.  Objective's objects have a
>>field that indicates what class said object belongs to (called "isa").
>>Messages are sent by hashing on the selector.  Thus, you can find out
>>at run-time whether or not a particular object will respond to a given
>>message.  C++ doesn't know much about an object at all at run-time,
>>all it has is a ptr. to a v-table.  If you've ever seen/used SmallTalk,
>>Objective is similar to it.
>>
>>I like that object model better, but I really wish Objective allowed
>>you to declare things in-line instead of at the top of a block, like
>>C++ allows.  The other C++ features I can live without (MI, operator-
>>overloading, etc.)
>>
>>-- 
>>Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
>>timm@ncsa.uiuc.edu|
>>(217)244-0015     |

As a neophyte I would agree and also add that the Obj-C learning curve is 
not as steep as C++.  Obj-C adds only a handfull of extensions to 
the C language.  Also it's easier to read and a bit more elegant
in general.  
--
Ronald Pomeroy
Advanced Micro Devices
CAM Applications Group
rpomeroy@aunext3.amd.com
From: oherb@jhunix.hcf.jhu.edu (Zoher B Bambot)
Newsgroups: comp.lang.objective-c
Subject: Re: More Obj-C discussion
Date: 27 Aug 92 19:05:58 GMT
Organization: HAC - Johns Hopkins University, Baltimore


I am working on developing classes for simulation of finite element meshes
using the object-oriented language c++. I would be grateful if anyone could
send me any programs in c++ which would help me in my work. Also has anyone 
developed a class for the simulation of a FEM for any particular structure.
You can mail them to me at my e-mail address and then I will summarize in
the net. Also are there any ftp sites from where I could get any useful
information. Thanx in advance.
                         Zoher.
Organization: Penn State University
Date: Mon, 31 Aug 1992 13:14:58 EDT
From: <MKK2@psuvm.psu.edu>
Newsgroups: comp.lang.objective-c
Subject: Re: Objective C library, Free Software Foundation
Distribution: na


>If I use gcc and this library and runtime, will I be able to sell programs
>I develop with it?  If the GNU source code license holds with regard to
>the class library, then could there be problems for developers in this
>regard?

>just curious ...

YES, of course.  Your question indicates a common misunderstanding about GNU
licensing.  It doesn't stop you from selling your time or your programs.
What it does do is it requires you to make your source available to interested
purchasers at cost of duplication.


I think 8-) 8-)
From: gdb0@ns1.cc.lehigh.edu (GLENN BLANK)
Newsgroups: comp.lang.objective-c
Subject: Re: Objective C library, Free Software Foundation
Date: 1 Sep 92 20:40:45 GMT
Organization: Lehigh University

In article <BtLso6.5H4@world.std.com>, gsk@world.std.com (Geoffrey S Knauth) writes:
>Quick Status
>------------
>There have been several dozen positive responses (zero negative) to
>the idea of creating a free software library containing Objective C.
>
>This is for you, the public.  If you want to be heard, climb aboard.

Let me add another positive response.  A FSF library could stimulate
the popularity of Objective-C, and get more folks involved in adding
features and libraries that folks need and would be easier to support
in Objective-C than C++.  For example, garbage collection and persistence.

Will the FSF version provide something analogous to Stepstone's
foundation class library or any of Next's library or will these
be add-ons?
Xref: sparky comp.lang.objective-c:479 comp.lang.c++:12942
From: taylor@foraker.tivoli.com (Eric Taylor)
Newsgroups: comp.lang.objective-c,comp.lang.c++
Subject: Re: Objective-C vs. C++
Date: 27 Aug 92 00:55:46 GMT
Followup-To: comp.lang.objective-c
Organization: TIVOLI Systems, Inc.

Obj. C does not have multiple inheritance.
I find the a BIG loss.
Objective C syntax is even weirder in class
definition than C++.
I don't seen to remember any operator overloading
in Obj. C  I may be wrong.
Newsgroups: comp.lang.objective-c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Objective C library, Free Software Foundation
Organization: Computer Science, University of Melbourne, Australia
Distribution: na
Date: Mon, 31 Aug 1992 20:01:41 GMT

trirex!taff@uunet.uu.net (Tom Affinito) writes:

>In article <BtLso6.5H4@world.std.com> gsk@world.std.com (Geoffrey S  
>Knauth) writes:
>> Quick Status
>> ------------
>> There have been several dozen positive responses (zero negative) to
>> the idea of creating a free software library containing Objective C.
>> 
>> Simson Garfinkel, Dave Pollak, Richard Stallman and I may meet next
>> week in Boston to determine a preliminary course of action.  Simson
>> and Dave and Dennis Glatting all have code to start this project
>> rolling.
>> 
>> I've also heard Cygnus Support may be interested in this project, or
>> they may have an existing project of their own.
>> 
>> This is for you, the public.  If you want to be heard, climb aboard.
>> -- 
>> Geoffrey S. Knauth, Marble Associates, Inc.                Member  
>BCS-NeXT, LPF
>> gsk@marble.com, (617) 891-5555 work, (617) 547-5247 home   Standard  
>Disclaimers
>
>If I use gcc and this library and runtime, will I be able to sell programs  
>I develop with it?

Yes.

>If the GNU source code license holds with regard to  
>the class library, then could there be problems for developers in this  
>regard?

There is a seperate license for libraries, to avoid these problems.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: samurai@homer.cs.mcgill.ca (Darcy Brockbank)
Newsgroups: comp.lang.objective-c
Subject: Re: Objective-C vs. C++
Date: 31 Aug 92 13:10:44 GMT
Reply-To: samurai@uriel.cs.mgill.ca
Organization: SOCS, McGill University, Montreal, Canada

In article <20@seltd.UUCP> lerman@seltd.UUCP (Kenneth Lerman) writes:
> One objection to runtime dispatching of messages which is often made
> by the C++ advocates is that you may get "doesNotRecognize" errors
> during runtime if your code is not statically checked by the compiler.
> My answer to this is:
>   You mean you don't test your code?

If you want to be more strict, you can also define variables as:

SomeClass *anObject;

Instead of:

id anObject;

And this will allow the compiler to check at compile time whether
or not "anObject" will respond to given selectors. (Unless the 
selectors are variables as well.)

- db

--
-------
I always thought that NeXTStep was very good in its approach to color since
the tasteless are protected from their own stupidity. -- Jason Breckenridge
(I know Jason, Jason is a close personal friend of mine, and I am not Jason!)
Newsgroups: comp.lang.objective-c
From: samurai@homer.cs.mcgill.ca (Darcy Brockbank)
Subject: Re: Objective-C vs. C++
Reply-To: samurai@uriel.cs.mgill.ca
Organization: SOCS, McGill University, Montreal, Canada
Date: Fri, 28 Aug 1992 18:27:04 GMT

In article <rmartin.714926059@thor> rmartin@thor.Rational.COM (Bob Martin)  
writes:
> But, with a few notable exceptions, the industry is putting its muscle
> behind C++.  

Don't forget that C++ came from "The people that brought you UNIX,"
ATT. Objective C came to you from Stepstone.

I'd bet that ATT had a little more influence than Stepstone in
the marketplace, and as a result, C++ became "standard" (in quotes
because the standard C++ isn't quite ready).

> I know why I, and a few of my friends and associates made that choice;
> but I can't speak for the whole industry.  We wanted formality because
> we were tired of fighting the maintenance nightmares caused by the
> casual nature of C.  We wanted the compiler to lay down strong typing
> rules, const rules, rules about instantiating abstract classes, rules
> about downcasting and upcasting.  We wanted our programs to be

Isn't ANSI C pretty strong about this? I know gcc2.2.2 drives me
WILD with warnings :-). And Objective C (well, NeXT's anyway)
is ANSI.

- db
From: dglattin@trirex.com (Dennis Glatting)
Subject: Re:  PD Implementation?
Organization: Trirex Systems Inc.
Date: Thu, 27 Aug 1992 20:56:58 GMT

In article <alain.3266@charpe.UUCP> alain@charpe.UUCP (Alain Charpentier)  
writes:
> 
>      His anybody aware of some one work on the runtime for GNU.
>      And to they need help.

Yes.

A Objective C run time has been donated to the Free Software Foundation.   
It includes the dispatcher and Object class.  The run time is portable and  
equivalent in speed to the dispatcher found in NeXT's OS2.2 (overhead of  
3). 

There is some clean up work I need to do to the initialization code and  
some minor changes to the compiler.  At the moment I'm under a time  
crunch.  Soon, soon, ...

--
Dennis P. Glatting / Sr. Technical Manager / Trirex Systems Inc.
315 Post Road West / Westport, Connecticut 06880 / (203)221-4600
dennis_glatting@trirex.com (NeXTmail Ok)
Member League for Programming Freedom
From: alex@cs.umd.edu (Alex Blakemore)
Newsgroups: comp.lang.objective-c
Subject: Re: Objective-C vs. C++
Keywords: Ada C++ inheritance overloading exceptions
Date: 27 Aug 92 18:35:31 GMT
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

In article <l9pvs3INN23a@west.west.sun.com> comp.lang.objective-c writes:
> It seems that I'm the only person who I've heard say that the best features
> of C++ have nothing to do with object orientation.

You're not alone.

[ list of useful language features like operator overloading, template classes,
  exceptions deleted]

For the record, I'ld just like to point out that these features along with concurrency,
strong typing, and hidden type internal representation have been in Ada for almost
10 years.  Supported by _every_ validated compiler.

Ada83 did have some limitations in the tasking model and weak inheritance support.
Ada9X, which is approaching completion now, improves these features in many ways
based on that decade of experience using and implementing them.
It generalizes Ada83's weak notion of inheritance into a real useful form
with dynamic binding.

One nice twist is that inheritance is an attribute of the type and is distinct
from the way types and operations are grouped (the package) and whether
the internal representation is accessible to clients or subclasses
(private types and child packages).
This easily allows the usual one class per module with no access to internals,
but several other configurations are can be constructed.

C++'s templates still dont compare favorably to the Ada generics from 1983
which are being extended in a way that lets packages be used as generic formal parameters.
This feature is more like ML signatures than C++ templates.

Lots more info is available from ajpo.sei.cmu.edu.
The Ada9X rationale document compares the language features and changes and
compares several other appoaches including C++ and Smalltalk.

I find it interesting that many of the same people that judged Ada large and complex -
which I dispute - now get all misty eyed when they speak of C++ which borrowed
heavily from Ada while keeping many of C's flaws. 

followup by mail please.


-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted
From: gbol@rglnext.geol.vt.edu (Gregory Lampshire)
Newsgroups: comp.lang.objective-c
Subject: Re: PD Implementation?
Date: 28 Aug 92 13:56:40 GMT

>   I'm waiting for GNU-ObjC to appear so I can duplicate the NeXTstep
> programming environment for X. With, of course, a few changes
> in the hierarchy. (BTW, if anyone else is also thinking of this,
> I'd be interested in exchanging ideas with you via email... there
> are a few things in NS that I really think could be improved in 
> a ground-up rewrite.)
> 
> -- 

I have been thinking along the same lines....is anybody else interested?





--
Gregory Lampshire 
Virginia Tech 
Bradley Department of Electrical Engineering
gbol@rglnext.geol.vt.edu (NeXTmail welcome)
------------------------
My opinions are my very own and do not reflect the opinions of any  
employer
From: shirley@fdr.jsc.nasa.gov (Bill Shirley [CSC])
Newsgroups: comp.lang.objective-c
Subject: Re: instance variable declarations..
Date: 3 Sep 1992 14:16:17 GMT
Organization: Software Technology Branch - NASA/JSC
Originator: shirley@fdr


In article <1992Sep3.020352.1872@almserv.uucp>, bnixon@fnma.com (Bill Nixon) writes:
> Just my two cents:
> 
> It seems to me that declaring instance variables in an object's
> interface file somewhat breaks the idea of encapsulation and

/breaks/ is much to harsh a word.  I can't just include Class.h and
go about modifying it's IVs.

> abstraction that object-oriented languages should provide.
> 
> What I have seen done in other language specifications, most recently
> OS/2 SOM, is to provide three interface files (.h) for an object:

I think you meant 3 files - 2 interface files.

> 
> + public - which has all public instance variables and methods.
> Everything defined in this file is directly accessible, even instance
> variables.  This and the "compiled" code for the object is all an
> object user needs to have.
> 
> + private - which has all private instance variables and methods.
> All instance variables and methods declared in this file are limited
> in scope and cannot be directly accessed.  (Normally this is also
> the source file which contains all the code for the methods).

this is basically the source file, correct?  (.c/.m)

> 
> + class - which has all instance variables and methods which can
> be modified via inheritance.  An object subclasser would require
> this file along with the "compiled" code in order to write a subclass of
> the object.
> 
> I am more comfortable living in a private and public environment.
> Basically only put "need to know" data (methods and maybe a few
> instance variables) in the public interface file.  Since most instance
> variables should be private to provide true data abstraction, they would
> not be exposed and this may provide a simplier and "safer" view of the
> object.

I agree that most IVs should be treated as private by subclassers, but
I don't favor enforcing this via extra files, this could be more of a
bookkeeping hassle.  Use of the @public, @private, etc.. would be just
as affective and let you see it (and write it) all in one eyeshot.
(I also don't know for sure whether these are still supported, but I
 suspect they are.)

I don't think the code not knowing of the implementation should necessarily
imply that the programmer isn't knowledgeable of the implementation.

> 
> Bill
> -- 
> email: bnixon@fnma.com (NeXT Mail Okay)
> Bill Nixon, Senior Programmer Analyst, Advanced Technology
> FannieMae, 3900 Wisconsin Ave NW, Washington, DC 22016     (202) 752-5468

-- 
Bill Shirley		|  ``Computer Science is not about computers any 
shirley@fdr.jsc.nasa.gov|	more than astronomy is about telescopes.''

-- 
Bill Shirley		|  ``Computer Science is not about computers any 
shirley@fdr.jsc.nasa.gov|	more than astronomy is about telescopes.''
Newsgroups: comp.lang.objective-c