NeXTSTEP is not UNIX

[Scott Keith]

Mike Pinkerton wrote:
> I dunno about that one....I can drag and item from one printer's
> spool...
> I wasn't aware you could do that in unix (or nextstep).

It is NeXTSTEP. You can choose a printer or fax-modem anywhere on
the network (when you print). Fax modems and printers can be
defined public and private using graphical tools. They are both
treated the same, except that you can specify a fax cover sheet when
faxing.

NeXTSTEP provides some backward compatibility with Unix commands,
but the interface and management tools are more like the MacOS than
Unix. You never see the Unix. It is based on the same concept as
MacOS.

NeXTSTEP and the MacOS were designed by the same person, Steve
Jobs. The differences between the two are not significant. It
wouldn't bother me to see NeXTSTEP take on the Mac interface.
However, we have to be careful not to throw out the innovations or
label them names (such as UNIX -- giving the connotation that it is
just a command line interface).

Labeling NeXTSTEP "unix" is like saying the Macintosh is really an
IBM PC running DOS. It simply isn't true.

Best regards,

Scott Keith



You wrote:
> Scott Keith wrote on 4/7/97 9:52 AM
>
> >1. Poor print spooling.
>
> I dunno about that one....I can drag and item from one printer's
> spool (while it is printing) and drop it on another printer and it
> will switch automatically (it will even ask where I want to start
> printing on the new printer, at the start or where the first one
> left off). I wasn't aware you could do that in unix (or nextstep).
>
> -- Mike Pinkerton ***@cc.gatech.edu
> <http://www.cc.gatech.edu/~mpinkert
>
> Cyberdog: On the Internet, no one knows you're an OpenDoc part
>
---

____________________________________________________________________

OPENBASE INTERNATIONAL LTD. http://www.openbase.com
58 Greenfield Road e-mail: ***@openbase.com
Francestown, NH 03043 USA TEL: [phone]/FAX: [phone]

[Jasper Y. Wong]

>
> Mike Pinkerton wrote:
> > I dunno about that one....I can drag and item from one printer's
> > spool...
> > I wasn't aware you could do that in unix (or nextstep).
>
> It is NeXTSTEP. You can choose a printer or fax-modem anywhere on
> the network (when you print). Fax modems and printers can be
> defined public and private using graphical tools. They are both
> treated the same, except that you can specify a fax cover sheet when
> faxing.
>
> NeXTSTEP provides some backward compatibility with Unix commands,
> but the interface and management tools are more like the MacOS than
> Unix. You never see the Unix. It is based on the same concept as
> MacOS.
>
> NeXTSTEP and the MacOS were designed by the same person, Steve
> Jobs. The differences between the two are not significant. It
> wouldn't bother me to see NeXTSTEP take on the Mac interface.
> However, we have to be careful not to throw out the innovations or
> label them names (such as UNIX -- giving the connotation that it is
> just a command line interface).
>
> Labeling NeXTSTEP "unix" is like saying the Macintosh is really an
> IBM PC running DOS. It simply isn't true.
>
> Best regards,
>
> Scott Keith
>
>
Huh? I believe NeXTStep is the GUI environment on top of the Mach
operating system (a variety of UNIX). MacOS is a completely different
beast altogther.

Jasper

>
> You wrote:
> > Scott Keith wrote on 4/7/97 9:52 AM
> >
> > >1. Poor print spooling.
> >
> > I dunno about that one....I can drag and item from one printer's
> > spool (while it is printing) and drop it on another printer and it
> > will switch automatically (it will even ask where I want to start
> > printing on the new printer, at the start or where the first one
> > left off). I wasn't aware you could do that in unix (or nextstep).
> >
> > -- Mike Pinkerton ***@cc.gatech.edu
> > <http://www.cc.gatech.edu/~mpinkert
> >
> > Cyberdog: On the Internet, no one knows you're an OpenDoc part
> >
> ---
>
> ____________________________________________________________________
>
> OPENBASE INTERNATIONAL LTD. http://www.openbase.com
> 58 Greenfield Road e-mail: ***@openbase.com
> Francestown, NH 03043 USA TEL: [phone]/FAX: [phone]
>


--
--< NeXT >--| Table Tennis | \ / | Volleyball |--< BeBox >--
| Gergely / TSP X / RITC 802 \ / Tachikara SC-5W / Mizuno |
| ***@rpi.edu, ***@bccn.org \ / IRC: mizzle @ #unix, #next |
--< Homepage forever under .... \/ .... construction >NeXTMail>--

[Robert Kieffer]

>

[Paul R. Summermatter]

Hello all,

I'm confused about one key aspect of the announcement
below. As I understand it, Java currently supports extensibility
only through sublassing. Extension of classes through categories,
as we have them in Objective-C, is not available. Given the fact
that a tremendous amount of the OpenStep APIs were written using
categories, how is this not going to present a large problem? Let
me say that I feel quite strongly that it will be wonderful if all
of the OpenStep APIs are written in Java, but I'm still hung up on
this fundamental problem of Java lacking extensibility through
categories. How do you get around this?

Regards,
Paul

You wrote:
> >

[s***@easynet.fr]

(Sorry if this is off-topic)

Hi,

I double checked the date and it was not 01 april 97, so this is probably
marketing hype :-)

Note that Netscape already did that kind of things (IFC:
<http://developer.netscape.com/library/ifc/index.html>)

Cheers,

-- fred

You wrote:
> >

[Kazuo Tsubaki]

Hi forks,

> I'm confused about one key aspect of the announcement
> below. As I understand it, Java currently supports extensibility
> only through sublassing. Extension of classes through categories,
> as we have them in Objective-C, is not available. Given the fact
> that a tremendous amount of the OpenStep APIs were written using
> categories, how is this not going to present a large problem? Let
> me say that I feel quite strongly that it will be wonderful if all
> of the OpenStep APIs are written in Java, but I'm still hung up on
> this fundamental problem of Java lacking extensibility through
> categories. How do you get around this?

How about @selector and a behavior when sending message to nil object?

---
Kazuo Tsubaki
mailto:kazuo-***@st.rim.or.jp (MIME, NeXTMail acceptable)
http://www.st.rim.or.jp/~kazuo-t
679 Kasamacho, Sakae-ku, Yokohama 247 Japan
Tel:[phone] Fax:[phone]

[Kai Henningsen]

***@Eng.Sun.COM (Robert Kieffer) wrote on 07.04.97 in <***@litehouse.eng.sun.com>:

> >

[Albert Dul]

> > >

[Garance A Drosehn]

> > > >

[Cliff Tuel]

NeXT is merely slapping Java front-ends onto a slew of methods. They're
using the Objective-C/Java bridge that was written for WebObjects 3.x. My
opinion is that the bridge is a major kludge -- you have to worry about
"jobs" files (Steve must love those) which map selectors between the two
languages. It also adds overhead, as the mapping is done using the
Objective-C runtime system.

(insert Dennis Miller Disclaimer here)

--
Cliff Tuel -- NeXTSTEP/OPENSTEP Wrangler -- ***@pdh.com -- ***@ablecom.net
PDH Inc / 2635 North First Street Suite 224 / San Jose California / 95134-2032

[Ernest N. Prabhakar]

Sorry, I don't have the original Web page references, but this is all out
there.

1) OpenStep as in Objective-C will continue to exist as the base API

2) Java bindings via NeXT's bridge will allow people to access most of
OpenStep from Java. Yes, you don't get fun things like categories, but
for the hordes of programmers who love Java and fear learning new
languages (e.g. the 1 hour it takes to learn ObjC :-), this is important.
And hey, those of us who know ObjC have a competitive advantage.

3) Other languages can call ObjC classes
Objective-C++ is really a hybrid, but for marketing purposes it means
C++ programs and programmers can call ObjC from within C++.
Object Pascal is suppose dto be supported.

And, someone has mentioend Perl and TCL can call ObjC already.

Are there any other important languages tos upport?

The big question is why NeXT chose to use a bridge between Java and ObjC
rather than direct calling (like you can between Fortran and C).
I can think of several reasons:

a) It allos substitution of the appropriate objects (java.string vs. NSstring)

b) it allows renaming (to conform with Java APIs?)

c) it allows subclassing of the proxy classes (in both directions)
- would this be possible otherwise? I doubt it, but am not sure

d) It looks better
Can you imagine calling myJavaPoint.addX:Y:(foo,bar)
Those ':' would make a C programmer - or a Java compiler - barf.

e) it is more general
One can do a full API translation, which may become necessary, or just
make it easy to port the AWT. Note that you can add new methods to the
class, as well as hide old one, when doing hte Java proxy.

I don't think there are many functional disadvantages, as you can just use
the 'naive' mapping where appropriate. The biggest question is
performance, though I can't imagine it is much worse than calling interpreted
Java methods directly. It may get you when you move to full compiled server-
side code.

My biggest concern is whether the "JavaStep" bindings for OpenStep will
mesh well with the JFC initiative at Sun/Lighthouse. For end-users it would
be a mess, but I'm not sure how the political/business issues look from
Sun and Apple's perspective.

Here's hoping they do the Right Thing and make JFC == JavaStep.

-- Ernie P.

[Garance A Drosehn]

Ernest N. Prabhakar <***@alumni.caltech.edu> writes:
> 3) Other languages can call ObjC classes
> Objective-C++ is really a hybrid, but for marketing purposes it
> means C++ programs and programmers can call ObjC from within C++.
> Object Pascal is supposed to be supported.
>
> And, someone has mentioend Perl and TCL can call ObjC already.
>
> Are there any other important languages to support?

For those that are interested, there is also Eiffel available
for NeXTSTEP 3.x. I don't know if it's available for 4.x, but
if not then I'd think that Rhaposody makes it more likely to
happen.

---
Garance Alistair Drosehn = ***@eclipse.its.rpi.edu
Senior Systems Programmer (MIME & NeXTmail capable)
Rensselaer Polytechnic Institute; Troy NY USA

[Ray]

(1) I'm sure Objective C will not go away, but Apple is bowing to the
wishes of thousands of developers who protest learning a
"platform-specific" language that, in their opinion, will not look good
on their resumes.
The closest thing to a valid protest I've heard was from a Claris
engineer who says that they've wrapped WinTel and MacOS APIs in C++
frameworks that present the same platform independant API to the rest of
their code, but doesn't think they could successfully wrap the OpenStep
APIs in a C++ framework to present the same API. (*I* think it could be
done.)

(2) Someone asked if this list supports MIME. My email package supports
MIME only for enclosures, I can't view NextMail or NetscapeMail in a
WYSIWYG manner.

(3) My resume is available from my home page listed in my signature. If
you know anyone in the Bay Area that's looking to hire ex-Appleites with
some NextStep experience, please put them in contact with me, or vice
versa.



// Keith and Jane
---- // ---
---------- Check out: <http://www.devworld.apple.com/>
---------
---------- <http://www.evangelist.macaddict.com/>
-----------
--- --- <http://pw2.netcom.com/~kjray/index.html>

[Laurent Cerveau]

>(1) I'm sure Objective C will not go away, but Apple is bowing to the
>wishes of thousands of developers who protest learning a
>"platform-specific" language that, in their opinion, will not look good
>on their resumes.

I've never done Java programming and find myself a little bit
confused about these Java API's.
For me Java is more than a language, because you can write cross-platform
softwares with it, and this is associated with the virtual machine. What
does it mean to have Java API's then? Does that mean that developping in
Java,
programmers will loose benefit of the operating system, or that they will
be able to access system function via Java calls, and the cross-platform
development will be lost then? Of course you will always benefit of the
choice of a specific OS (or not benefit...), in the way the virtual machine
calls the system.
For me Java and C (Obj-C) don't have the same goals, and are both useful;
so I will learn the two of them depending on what I want to do.
So this API's story is more confusing than helpful for me. It is nice to
have a
standard for cross-platform and Web development, but I don't see the
interest of having an OS only to run Java virtual machine, even if it is
well implemented, or maybe having a complete JavaOS, which the virtual
machine is not.
If someone could help me about making these points more clear, it would be
nice. By the way, Obj-C is very fun, and learning it helps a lot about
what is really object programming. The book available on Apple and NeXT
sites (Object Oriented Programming and the Objective-C language ) is really
good.If I remember well, it was indicated as a reference in one of the Sun
JDK text!


Laurent

----------------------------------------------------------------------------
Laurent Cerveau


***@club-internet.fr
***@ircam.fr
----------------------------------------------------------------------------

[Dr. Ernest N. Prabhakar]

Laurent wrote:
> I've never done Java programming and find myself a little bit
> confused about these Java API's.
> For me Java is more than a language, because you can write
> cross-platform softwares with it, and this is associated with the
> virtual machine. What does it mean to have Java API's then?

Currently, OpenStep applications are written to the "OpenStep API", which is in Objective-C and is cross-platform. All the various UNIX APIs (e.g. BSD 4.3) are also avaialable, but people rarely write to them except for creating/porting unix utilities.


Java is a whole mess of things:
- a language
- a framework (AWT)
- a virtual machine (JavaVM)
- an OS which runs all the above (JavaOS)

What Apple is talking about is putting Java -the language- into OpenStep. Technically speaking, they are defining Java "bindings" for the OpenStep API. This is the same way old math libraries and things like POSIX (UNIX) and CORBA would defined 'bindings' for C, Pascal, Fortran, etc. That way programs could call the routines in their own natural format. This Java binding to OpenStep is often called "JavaStep".

This woud also involve integrating the Java runtime into the Objective-C runtime - INSTEAD of running it inside a virtual machine. Of course, Apple has also announced the JavaVM will be available, to securely run Applet code downloaded from web sites. But actual Java applications will be compiled and run natively just like Objective-C programs.

Now, once the -language- Java is integrated into Rhapsody, it should be fairly trivial to build the AWT on top of OpenStep. What's more, they'll probably take advantage of the mapping mechanism to make JavaStep resemble the AWT, to make it more familiar to Java programmers.

What is more interesting is that Sun (via Lighthouse Design, a former NeXT ISV) and Netscape are integrating Netscape's IFC (which was designed by ex-NeXTer Jayson Adams and resembles OpenStep) into the AWT. The result should be something very similar to JavaStep, i.e. the OpenStepping of Java vs. the Java-izing of OpenStep.

Hopefully they'll make them match up rather than confuse us all with two similar but distinct frameworks. The early IFC was handicapped by a lack of reflection, so they couldn't really handle target-action and delegation. This should improve in the new version.


The bottom line is that many people are afraid of learning Objective-C the language; they shouldn't be, but they are. Java makes it emotionally easier for people to program for Rhapsody, which is A Good Thing. Java does do a few things better than Objective-C, though there are some things it doesn't do at all. People can use what they want, Apple will support both, and everyone should live happily ever after.

-- Ernie P.

[Charles F. Waltrip]

Dr. Ernest N. Prabhakar wrote:

[...material deleted including a description of NeXT's plans
to integrate the Java VM into the ObjC runtime...]

> The bottom line is that many people are afraid of learning Objective-C the language; they shouldn't be, but they are. Java makes it emotionally easier for people to program for Rhapsody, which is A Good Thing. Java does do a few things better than Objective-C, though there are some things it doesn't do at all. People can use what they want, Apple will support both, and everyone should live happily ever after.
>
> -- Ernie P.

I believe Java is a wonderful language but feel that ObjC is an even
more wonderful language. What would be fantastic, in my view, would
be if NeXT's compiler for C/C++/ObjC would include Java and would
compile any C/C++/ObjC/Java language (or mixture of languages) into
Java bytecodes as an option rather than only into ObjC runtime.

Chuck

[A billion here, a billion there... pretty soon you're talking about REAL money.]

Ernie P. Wrote:
>Laurent wrote:
>> I've never done Java programming and find myself a little bit
>> confused about these Java API's.
>> For me Java is more than a language, because you can write
>> cross-platform softwares with it, and this is associated with the
>> virtual machine. What does it mean to have Java API's then?=20
>
>Currently, OpenStep applications are written to the "OpenStep API", =
>which is in Objective-C and is cross-platform. All the various =

<snip>

>The bottom line is that many people are afraid of learning =
>Objective-C the language; they shouldn't be, but they are. Java =
>makes it emotionally easier for people to program for Rhapsody, =
>which is A Good Thing. Java does do a few things better than =
>Objective-C, though there are some things it doesn't do at all. =
>People can use what they want, Apple will support both, and everyone =
>should live happily ever after.

It seems to me that the problem isn't Objective-C itself, but the fact
that there don't seem to be any programming environments for anything
but OpenStep. If someone is looking to create a cross-platform,
consumer-level product, why would they use OpenStep? It costs way too
much for the run-time environment. That, in my opinion, is the reason
more people don't use it. If people could actually write programs for
different environments using Obj-C, maybe they would. It's looked
at as being proprietary right now.

Does anyone know any details about the Objective C support that
Metrowerks will be including in CodeWarrior 12? Would you be able to
write MacOS programs in Objective C?

Apple really needs to lower the costs for the OpenStep run-time.

-SB

[Ronald C.F. Antony]

> Apple really needs to lower the costs for the OpenStep run-time.

I think key component of the high cost of the run-time is the DPS license.
If Apple could cut a deal with Adobe, whereby Apple grants Adobe free licenses
to the OpenStep runtime, if in exchange all Adobe apps for Win95, WinNT,
Rhapsody, and Solaris are built with it and ship with the OpenStep runtime,
in such a way that other applications can use it as well, then we'd have
a great deal.

Adobe would benefit, since the would have to maintain only one code base
for all platforms. Many people would be tempted to buy Adobe apps, anf if
only to get at the OpenStep runtime for cheap.

Apple would benefit, since everyone who owns even one Adobe app, has the
OpenStep runtime, and can buy other OpenStep apps and run them. This would
make OpenStep the most powerful corss platform development environment.
(Spare me the Java crap here, it's not even in the same league. When was the
last time you tried to write printing support in Java, or do real WYSIWYG...)

3rd party developers would benefit, since they could write powerful OO apps
and deploy them on almost any platform.

The only time the runtime expense would still be an issue, is if someone does
not either own the OPENSTEP environment or Rhapsody, at which point they would
have to buy the OpenStep runtime, which could be sold like the Win95 Plus! pack.

Of course, Apple could also spend a little money and fund the GNUStep people with
about $10-20k, and get GhostScript turned into a fullblown DisplayGhostScript.
After that, they could offer the AdobeDPS OpenStep runtime for a lot of money,
and the generic DGS OpenStep runtime for more or less free.

In either case, OpenStep as a development and deployment platform, as well as
Apple's viability as a computer company would skyrocket.

Ronald

[Donald A. Yacktman]

On Fri, 11 Apr 97, Ronald C.F. Antony wrote:
> I think key component of the high cost of the run-time is the DPS license.

How can a <= $20 license be the cause of the current exorbitant price for
NeXT's runtime?

I don't have the exact number, but I know that is it definitely << $50 per
DPS license, in the $20 ballpark. A DPS license add-on to allow printing to
a non-PS printer costs more (since it allows any machine with OPENSTEP to
turn *any* printer into a Postscript printer) but that is why it is an add
on.

Personally, I think the reason for NeXT's pricing is, well, NeXT.

---
Later,

-Don Yacktman
***@misckit.com
<a href="http://www.misckit.com/don.html">My home page</a>

[Mike Pinkerton]

"A billion here, a billion there... pretty soon you're talking wrote on
4/11/97 7:40 AM

>It seems to me that the problem isn't Objective-C itself, but the fact
>that there don't seem to be any programming environments for anything
>but OpenStep.

I think a huge part of it is not the lack of environments or that people
are "scared" to learn a new language. The problem is that this language
exists, for all practical purposes, only on ONE platform (nobody uses
objC on other platforms, even though it is part of gcc).

No software company is going to invest in a project using a language
which cannot be leveraged to any other platform. In a world of
cross-platform code bases and products, having to write in C++ for
windoze and ObjC for Rhapsody is a non-issue (everyone will write C++ for
windows).

>

[David Young]

> I think a huge part of it is not the lack of environments or that people
> are "scared" to learn a new language. The problem is that this language
> exists, for all practical purposes, only on ONE platform (nobody uses
> objC on other platforms, even though it is part of gcc).

Wrong. We do systems programming on Solaris, Digital UNIX, AIX, BSDI, and
HP-UX using Objective-C. We don't use OpenStep, we have our own set of
classes, but we definitely use ObjC. Other people do too.

> No software company is going to invest in a project using a language
> which cannot be leveraged to any other platform. In a world of
> cross-platform code bases and products, having to write in C++ for
> windoze and ObjC for Rhapsody is a non-issue (everyone will write C++ for
> windows).

Have you missed the point of OpenStep entirely? Develop on Mach, deploy on
NT, Mach, Rhapsody. Either way, developers aren't going to tell an
installed base of 20+ million users to get bent. There's too much money
available.

>

[Ricardo Parada]

> > I think a huge part of it is not the lack of environments
> > or that people are "scared" to learn a new language. The
> > problem is that this language exists, for all practical
> > purposes, only on ONE platform (nobody uses
> > objC on other platforms, even though it is part
> > of gcc).
>
> Wrong. We do systems programming on Solaris, Digital
> UNIX, AIX, BSDI, and HP-UX using Objective-C. We don't
> use OpenStep, we have our own set of classes, but we
> definitely use ObjC. Other people do too.

Objective-C will also be available soon from Metrowerks
for Rhapsody, Windows 95 and NT.

It's also available from Sun.

- ricardo

[A billion here, a billion there... pretty soon you're talking about REAL money.]

David Young wrote:
>> No software company is going to invest in a project using a language
>> which cannot be leveraged to any other platform. In a world of
>> cross-platform code bases and products, having to write in C++ for
>> windoze and ObjC for Rhapsody is a non-issue (everyone will write C++ for
>> windows).
>
>Have you missed the point of OpenStep entirely? Develop on Mach, deploy on
>NT, Mach, Rhapsody. Either way, developers aren't going to tell an
>installed base of 20+ million users to get bent. There's too much money
>available.
>

I don't believe he's missed the point. What about most software companies
who don't want to have to re-write all of their C++ or other code in
Obj-C.

This is just fine for Enterprise products, but what about consumer type
products? The OpenStep run-time costs way too much for that. The product
will not be able to compete unless OpenStep libraries can be made available
for cheap.

-SB

[Garance A Drosehn]

> > Have you missed the point of OpenStep entirely? Develop on
> > Mach, deploy on NT, Mach, Rhapsody. Either way, developers
> > aren't going to tell an installed base of 20+ million users
> > to get bent. There's too much money available.
>
> I don't believe he's missed the point. What about most software
> companies who don't want to have to re-write all of their C++ or
> other code in Obj-C.
>
> This is just fine for Enterprise products, but what about consumer
> type products? The OpenStep run-time costs way too much for
> that. The product will not be able to compete unless OpenStep
> libraries can be made available for cheap.

For one, I definitely agree that the success of Rhapsody will depend
a lot on the price it's sold at.

For two, Apple is talking about Rhapsody being "language agnostic".
If people who want to program in ObjectiveC can, and people who
want to program in C++ can, and people who want to program in Java
can, then I see little point in any one of those groups trying to
convince the other groups of the errors of their ways.

Now, it will be interesting to see how close they come to being
truly language-agnostic, but that's a question which will only
be answered by the release of Rhapsody. We should have a much
better idea of the answer to that topic by the WWDC, next month.
Let's leave this discussion until after that happens (and maybe
pick it up in rhapsody-talk, once we have something to talk about).

---
Garance Alistair Drosehn = ***@eclipse.its.rpi.edu
Senior Systems Programmer (MIME & NeXTmail capable)
Rensselaer Polytechnic Institute; Troy NY USA

[Ronald C.F. Antony]

>For two, Apple is talking about Rhapsody being "language agnostic".
>If people who want to program in ObjectiveC can, and people who
>want to program in C++ can, and people who want to program in Java
>can, then I see little point in any one of those groups trying to
>convince the other groups of the errors of their ways.

Well, technically, that's just not possible. Java, SmallTalk, ObjC are
all languages that use dynamic, run-time binding. You CAN make the
OpenStep APIs language agnostic among these (more or less).

C++ and most other so called "strongly typed" languages, use static
binding. They just cannot use all the OpenStep functionality.
While it is possible too create a C++ syntax compiler that produces
dynamically bound code, that's not C++ anymore. It wouldn't be portable
to other C++ implementations, since they don't support the feature.
It would be mock C++, syntactic sugar (quite bitter one at that),
but not C++

As a matter of fact, Java (the language) is nothing but an attempt to pack
Smalltalk and ObjC like functionality into the sick C++ like syntax.

Ronald

[David Young]

> I don't believe he's missed the point. What about most software companies
> who don't want to have to re-write all of their C++ or other code in
> Obj-C.

No one said they had to. C++ interoperates just fine with ObjC, if you use
NeXT's compiler.

> This is just fine for Enterprise products, but what about consumer type
> products? The OpenStep run-time costs way too much for that. The product
> will not be able to compete unless OpenStep libraries can be made available
> for cheap.

Yeah, I think the runtime should be cheap too. I have a feeling it will
be.

[Chris Hanson]

At 11:22 AM -0500 4/11/97, David Young wrote:
>No one said they had to. C++ interoperates just fine with ObjC, if you use
>NeXT's compiler.

The issue isn't interoperability, the issue is compatibility. Is it
possible in OpenStep now to use C++ *syntax* to access Objective-C objects?
In other words, do I *have* to use [someObject someMessage:anArg] to send a
message to an Objective-C object, or can I accomplish the same thing with
someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++?

I don't have a problem with using or learning Objective-C to develop for
Rhapsody, but many other people appear to want to actually use C++ to
program Rhapsody, not just to program the non-interface portions of their
apps. I can totally understand this; right now, I'm porting a product from
one platform and C++ class library to another and basically I'm writing
shim classes to sit on top of the second library and interface with the
ported code. I'd like to be able to do this for Rhapsody as well, if the
port is desired there, and being unable to reuse that top layer of code
(both model and view code) would make it much more difficult.

[Thomas Engel]

> The issue isn't interoperability, the issue is compatibility. Is it
> possible in OpenStep now to use C++ *syntax* to access Objective-C objects?
> In other words, do I *have* to use [someObject someMessage:anArg] to send a
> message to an Objective-C object, or can I accomplish the same thing with
> someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++?
>

Its a common problem with NextStep since people always miss a little
detail that makes so much of a difference.

OpenStep Frameworks really _are_ the operating system.
(at least they are a core part of the systems functionality
and the same objects come with every machine and therefor are
core OS features)

IMHO this is a very crucial point when we talk about Rhapsody. Its not
the BSD C APIs or the Mach C function bindings or direct DPS context
communication which we should consider as the OS API...its OO frameworks
which are written in a specific language (here ObjC) and therefore can be
accessed naturally using that language.

Now nobody seems to have a problem that early systems used stack based
trap style OS APIs to access OS functionitly. There it seems just natural
to everybody that in order to use C++ you need C++ frameworks to shield
you from low level communications with the OS. (since that MAc was Pascal
in the early days...you still have to pass Pascal strings when doing
C++... or you have some wrappers which take care of the conversion)

Now think of the C++/ObjC interoperability as the low level communication
but if you want to do C++ only you need a C++ framework that shields you
from pure OO communication (wreaps those "ugly" ObjC messages)

Using ObjC has the benefits that you can easily customize the operating
system since you can replace or remap certain OS behavior jsut natureally.
C++ lacks certain features that ObjC offers at the language level so you
need some meta-programming to solve these issues and you need a "smart"
C++ compiler which knows who to generate code blocks that can 2patch" your
system (which would mean repackage in an operating system conform runtime
fashion...which happens to be the ObjC runtime)

> I don't have a problem with using or learning Objective-C to develop for
> Rhapsody, but many other people appear to want to actually use C++ to
> program Rhapsody, not just to program the non-interface portions of their
> apps.

The "none-interface" argument always comes from the fact that there are
(yet) no C++ wrappers for the operating systems (OpenStep ObjC)
frameworks. Since C++ and ObjC integrate quite nicely...and the ObjC tools
enable rapid GUI development most people took the "interoparability"
route.
You are free to write a C++ wrapper to the AppKit...and MetroWorks will
propably offer a C++ framework which sits on top of the ObjC classes and
not the core C-function services of Rhapsody. Not sitting on top of the
operating system objects (which happen to be ObjC) would require to
dublicate multilanguage support, window handling, etc. pp.

This programming language confusion seems to be really big.

This is why Apple emphazized the "Java" mappings and "Java" programming.
Even Java has to interface to the operating systems...but since there is
a simple way to map ObjC to Java programming in Java is a very natural
thing under Rhapsody.

So Java gives you "Java-OS-wrappers" almost for free...
...while C++ does not. C++ just offers easy interoparability and it takes
a good C++ framework to shield you from "low-level OS communication"
(using ObjC code).


So what if Apple called their OS. "The first PDO-based OO OS". (replace
PDO with CORBA to get it sound "hype-right"...or call it ObjC-runtime to
get it technically more corerct).
Now lets say Apple currently only offers an ObjC binding to the
PDO-language-neutral system object model (yet another SOM system).
Interestingly ObjC interfaces very well with Rhaspodies object runtime
since all frameworks happen to be in ObjC and the OS'es runtime uses the
same features. Which means a 100% OS object model to programming language
mapping (similar to Java-OS/VM + Java).

Now if you have a "Direct-To-PDO" C++ compiler things would be just fine.
Wouldn't they ?

I personally don't understand the "language" confusion which seems to be
worrying Mac developers that much. There was Lisp, Smalltalk, Eiffel,
Oberon, Scheme, and many more.. available for NextStep and you could write
applications.

No matter which language (read "object model") Apple would have picked
for its next OS...usually its "natural" OS language which is the most
elegant for the system (like PAscal for the Mac) until the other language
tools and frameworks managed to wrap all OS services.

Rhapsody developers will be able to program in any language they want
once the tools have been ported, but ObjC and Java (and other dynamic OO
languages like Smalltalk) should be the most natural.

To summerize it...take a look at Rhapsodies "assambly" language
(ObjC)...if its doesn't meet your requirements...use a different language.


Aloha
Tomi

[David Young]

On Fri, 11 Apr 1997, Chris Hanson wrote:
> The issue isn't interoperability, the issue is compatibility. Is it
> possible in OpenStep now to use C++ *syntax* to access Objective-C objects?
> In other words, do I *have* to use [someObject someMessage:anArg] to send a
> message to an Objective-C object, or can I accomplish the same thing with
> someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++?

Partially. You can do objc_sengMsg(object, selector, arg, arg), but you
can't do someObject->someMessage(anArg). Now, I wouldn't stop NeXT from
writing proxy classes in C++ which allowed you to do this by masking the
actual message calls. You currently cannot subclass ObjC classes in C++.

With enough hacking NeXT could probably make some of these things happen.
The end result is likely to be uglier than just learning ObjC, but
whatever. It seems weird to me to want to preserve the syntax of C++ in a
View class which wouldn't interact with anything but OpenStep libraries
anyway, but whatever.

> I can totally understand this; right now, I'm porting a product from
> one platform and C++ class library to another and basically I'm writing
> shim classes to sit on top of the second library and interface with the
> ported code. I'd like to be able to do this for Rhapsody as well, if the
> port is desired there, and being unable to reuse that top layer of code
> (both model and view code) would make it much more difficult.

Eh? If you've already got a layer of abstraction between you and your View
code, then writing an interface layer in ObjC++ would be okay...

.............david.young...senior.developer...think.new.ideas.inc...
....work:.http://www.thinkinc.com...net:***@thinkinc.com...

[Chris Hanson]

At 3:25 PM -0500 4/11/97, Ronald C.F. Antony wrote:
>Well, technically, that's just not possible. Java, SmallTalk, ObjC are
>all languages that use dynamic, run-time binding. You CAN make the
>OpenStep APIs language agnostic among these (more or less).

Doesn't SOM allow you to do stuff like this in C++ (and C)?

[Ronald C.F. Antony]

>At 3:25 PM -0500 4/11/97, Ronald C.F. Antony wrote:
>>Well, technically, that's just not possible. Java, SmallTalk, ObjC are
>>all languages that use dynamic, run-time binding. You CAN make the
>>OpenStep APIs language agnostic among these (more or less).
>
>Doesn't SOM allow you to do stuff like this in C++ (and C)?

I bet they solve it on the "interoperability" level, not on the
"compatibility" level... Or maybe they can just do messaging, but
not instantiation, subclassing, etc. Or else it's no longer C++
or the ever expanding C++ standard proposal just added support for
dynamic binding, runtime message selection, etc.

Ronald

[Stephen Coy]

On Sat, 12 Apr 1997 12:52 AM, David Young <mailto:***@ace.net> wrote:
>Have you missed the point of OpenStep entirely? Develop on Mach, deploy on
>NT, Mach, Rhapsody. Either way, developers aren't going to tell an
>installed base of 20+ million users to get bent. There's too much money
>available.
>

David,

To many of us, the point is still distinctly fuzzy. If I develop an
OpenStep application, what else will my customers need to run it under NT?
A (set of) DLL(s)? Or a complete protected sub-system?

The ability to build Windows/Macintosh solutions is important to many of
us. It is not clear how OpenStep helps us do this, if at all.

In fact, it would be great if someone could enlighten me (us).

Regards,


Steve Coy Resolve Software Pty Ltd
4 Andove St
Belrose NSW 2085
Australia

****** This message was sent by CyberDog 2.0 ********

[Ronald C.F. Antony]

>To many of us, the point is still distinctly fuzzy. If I develop an
>OpenStep application, what else will my customers need to run it under NT?
>A (set of) DLL(s)? Or a complete protected sub-system?
>
>The ability to build Windows/Macintosh solutions is important to many of
>us. It is not clear how OpenStep helps us do this, if at all.
>
>In fact, it would be great if someone could enlighten me (us).

What is needed is the OpenStep User environment. That is however not
really a user-environment (hence the confusion), but a system environment
(DLLs, PS resources, encoding tables, etc.). It is just called OpenStep user
environment to distinguish it from the Developer environment that contains
that plus developer tools, etc.

At this point, there is only two things that prevent any sane developer from
doing only OpenStep development and deploying on all platform, and those are

a) the licensing fees due (which Apple should lower in their own interest,
if they want to become once more a leader, and the platform for which
companies target their applications first)

b) the somewhat higher resource requirements (RAM, HD space, etc.) Obviously,
there is a price you pay for having DPS run under Windows, etc. and that is
paid in higher resource consumption. So possibly the lowest end Windows
platforms might not be able to handle it. But given that these days pretty
much everyone is running a 486 or higher that is not really that much of an
issue.

The key thing is, if and when will Apple drastically drop the licensing fee
for the user environment.

Ronald

[Scott Keith]

> Steve Coy Writes:
> To many of us, the point is still distinctly fuzzy. If I develop an
> OpenStep application, what else will my customers need to run it
> under NT? A (set of) DLL(s)? Or a complete protected sub-system?
>

Just a set of DLLs.

> The ability to build Windows/Macintosh solutions is important to
> many of us. It is not clear how OpenStep helps us do this, if at
> all.
>

I suppose it is something you may need to see for yourself. I would say that OpenStep easily increases productivity by about 5 times. The reason is that the API is clean and provides high-level objects that are reusable and subclassible.

When Word Perfect decided to port their word processor to NeXTSTEP a few years ago it only took them a month. The reason is that they didn't have to rewrite essential high-level objects--they just had to replace them with what was provided in NeXTSTEP/OpenStep.

The idea behind OpenStep is that they give you much more to start with so you don't have to write your own color pickers, printer/fax panels, communications objects, etc. Everything you can imagine is already there. The advantage is really clear when the same code that works on your OpenStep/Mac compiles and works the same on Windows NT. Again, OpenStep takes care of all the objects for Windows NT and gives you a common interface.

The advantage to OpenStep is all the code that you DON'T have to write. Imagine not changing a single line of code and yet being able to compile your programs on Multiple operating systems. That is how OpenStep can help.

I hope this helps.

Scott Keith

____________________________________________________________________

OPENBASE INTERNATIONAL LTD. http://www.openbase.com
58 Greenfield Road e-mail: ***@openbase.com
Francestown, NH 03043 USA TEL: [phone]/FAX: [phone]

[Aleksey Sudakov]

<nofill>You wrote:
: > Steve Coy Writes:
: > To many of us, the point is still distinctly fuzzy. If I develop an
: > OpenStep application, what else will my customers need to run it
: > under NT? A (set of) DLL(s)? Or a complete protected sub-system?
: >
:
: Just a set of DLLs.

This is not correct, at least not 100% accurate.
</nofill>In certain cases (some daemons that use certain subset of FoundationKit
only) DLLs are all that you need (Scott, is it the case with OpenBase?),
but for GUI applications there should be full fledged OpenStep User
environment...


Just my 2 cents.


Aleksey