Discussion:
To the keyboards, guys: comp.sys.mac.programmer.help.
(too old to reply)
John C. Randolph
2000-01-29 07:07:15 UTC
Permalink
Gentlemen,

The Mac developer community would greatly benefit from a number of old
NeXT hackers participating in comp.sys.mac.programmer.help

The traffic of Cocoa newbies in that group is just beginning, and
they're getting bad advice like "sure, go ahead and write your cocoa
apps in Java", or "Just carbonize your app. It won't suck, really!"

In particular, strong, informed advocacy of Obj-C and Cocoa right NOW
would save some of these people a lot of grief down the road.

See you there,

-jcr
--
"The US Constitution may not be perfect, but it's better than what we
have now!"
Scott Anguish
2000-01-29 08:18:54 UTC
Permalink
Post by John C. Randolph
Gentlemen,
The Mac developer community would greatly benefit from a number of old
NeXT hackers participating in comp.sys.mac.programmer.help
The traffic of Cocoa newbies in that group is just beginning, and
they're getting bad advice like "sure, go ahead and write your cocoa
apps in Java", or "Just carbonize your app. It won't suck, really!"
In particular, strong, informed advocacy of Obj-C and Cocoa right NOW
would save some of these people a lot of grief down the road.
See you there,
Wouldn't it be better to point them to this mailing list?
Moving them one by one over here is much easier than moving others
over there... this list is already useful... but Usenet.. Does
anyone even read Usenet anymore?
Troy Dawson
2000-01-29 09:34:11 UTC
Permalink
Post by Scott Anguish
Post by John C. Randolph
Gentlemen,
See you there,
Wouldn't it be better to point them to this mailing list?
Moving them one by one over here is much easier than moving others
over there... this list is already useful... but Usenet.. Does
anyone even read Usenet anymore?
No, but when I have a question it is very convenient to do a dejanews
search (without Usenet, Win32 programming would be impossible ;),
and post the query if nothing helpful comes up.

(I know Omnigroup has e-mail archives of this list)

=td=
John C. Randolph
2000-01-29 09:48:36 UTC
Permalink
Post by Scott Anguish
Wouldn't it be better to point them to this mailing list?
I have.

-jcr
--
"The US Constitution may not be perfect, but it's better than what we
have now!"
Fabien Roy
2000-01-29 08:50:59 UTC
Permalink
Post by Scott Anguish
Wouldn't it be better to point them to this mailing list?
Moving them one by one over here is much easier than moving others
over there... this list is already useful... but Usenet.. Does
anyone even read Usenet anymore?
I second that one.
I am willing to help but on this list.
Maury Markowitz
2000-01-29 18:30:22 UTC
Permalink
Post by Fabien Roy
I second that one.
I am willing to help but on this list.
Yes, but that's the PROBLEM. The Cocoa programmers group is so
insular that problems like this happen all the time. "I'll help, but
only if it's not a bother"? For shame!

Maury
Guillaume Lessard
2000-01-29 18:32:00 UTC
Permalink
--On Vendredi 28 janvier 2000 23:15 -0800 "John C. Randolph"
Post by John C. Randolph
Gentlemen,
The Mac developer community would greatly benefit from a number of old
NeXT hackers participating in comp.sys.mac.programmer.help
The traffic of Cocoa newbies in that group is just beginning, and
they're getting bad advice like "sure, go ahead and write your cocoa
apps in Java", or "Just carbonize your app. It won't suck, really!"
Whatever. Please let people carbonize, because I want apps on OSX!

But more importantly, do you people realize the power of the class library
that comes with java?

A developer that starts coding from scratch with java will get results way
faster than by starting from scratch with O-C, *because* of the class
library. And please cease implying that java ain't polymorphic or cannot do
introspection. The only thing that is in O-C that's not in java is O-C
categories. However, what's in java and not in O-C is a huge class library
in constant evolution and growth. Wake up.

This is not a flame, btw. It is merely intended as an equalizer to all the
mostly misguided anti-java sentiment that is continually expressed on the
list.

--
Guillaume Lessard
***@caltech.edu
Graduate Student
Caltech Applied Physics/Electrical Engineering
Bill Bumgarner
2000-01-29 19:19:02 UTC
Permalink
Yeah-- except that the class libraries on Java tend to be extremely poorly
designed and often difficult if not impossible to customize or subclass.
Worse, everytime a new JDK comes out, it introduces a tremendous number of
compatibility issues.

A huge class library is of very liittle value if it is of a crappy and
inflexible design. Remember Taligent? It had several hundrend classes to
represent a button yet the end result was not as capable of NSButton and its
three or four subclasses.

Of all the projects I have been involved with, one of the most signifcant
unquantifiable costs to development has typically been crappy development
tools or bugs in the underlying foundation/libraries on top of which the
project has been built. Unquantifiable costs like this can often outright
kill a project.

If quantity of classes gave any useful metric as to the quality of an OO
system, C++ would have one ages ago.

This is not to say that the ObjC environment isn't lacking.... it is, there
are some gross inadequacies in the provided frameworks. However, given the
ease with which one can go out to Java or some other language to get the job
done, this isn't an issue. In my experience-- experience that has spanned
many years with many, many languages on many different scales of projects--
projects that use a toolset that actually works somewhat like it is documented
as working generally achieve a greater degree of success than those projects
that are build with bleeding edge or poorly defined toolsets.

One of the best examples of a tremendous class library that is relatively
complete and works very well is Python.... Tcl/TK comes to mind, as well. A
great example of a really crappy class library would be Perl's or the JDK.

ObjC falls somewhere in the middle.

However, for comlex GUI based applications, nothing beats the AppKit.
Swing+JDK is pathetic by comparison. However, for building multithreaded,
network savvy applications-- ObjC/AppKit extremely primitive and quite the
pain to use.... and Java or Python wins this one hands down.

At this point, one of the best paths to success would be to write all the GUI
stuff in ObjC/AppKit to yield a really fast/functional environment.... and use
JDK to do the networking stuff, access EJBs [if you can find a useful
implementation], etc... Then gateway between the two. It ain't hard.

If you are going to go this route and need to use HTTP, don't bother with the
URL/HTTP classes included in the JDK. They are awful-- very limited, very
complex [as is typical throughout the JDK.... why do i need 12 classes for
doing file like I/O, anyway?]. However, there are a number of alternatives.
Most are even worse than the included ones-- but one, HTTPClient, is a shining
example of a well implemented package. Works great.

Expect to have to go to third parties for a number of solutions that are
supposedly included with the JDK..... XML is another example. Compare Sun's
Project X with IBM's xml4j -- xml4j is much better designed, much faster, and
has a more intelligent/intuitive implementation.

b.bum
Post by Guillaume Lessard
--On Vendredi 28 janvier 2000 23:15 -0800 "John C. Randolph"
Post by John C. Randolph
Gentlemen,
The Mac developer community would greatly benefit from a number of old
NeXT hackers participating in comp.sys.mac.programmer.help
The traffic of Cocoa newbies in that group is just beginning, and
they're getting bad advice like "sure, go ahead and write your cocoa
apps in Java", or "Just carbonize your app. It won't suck, really!"
Whatever. Please let people carbonize, because I want apps on OSX!
But more importantly, do you people realize the power of the class library
that comes with java?
A developer that starts coding from scratch with java will get results way
faster than by starting from scratch with O-C, *because* of the class
library. And please cease implying that java ain't polymorphic or cannot do
introspection. The only thing that is in O-C that's not in java is O-C
categories. However, what's in java and not in O-C is a huge class library
in constant evolution and growth. Wake up.
This is not a flame, btw. It is merely intended as an equalizer to all the
mostly misguided anti-java sentiment that is continually expressed on the
list.
--
Guillaume Lessard
Graduate Student
Caltech Applied Physics/Electrical Engineering
Kenneth C. Dyke
2000-01-29 20:15:38 UTC
Permalink
Post by Guillaume Lessard
This is not a flame, btw. It is merely intended as an equalizer to all the
mostly misguided anti-java sentiment that is continually expressed on the
list.
</nofill>

So, it is trivial using Java to write a networked clipboard sharing app,
right? I mean, something so *simple* has just got to be trivial with the
Java class libraries... Note that it should deal with data other than
strings and should only explicitly copy data when actually necessary....


As best I can tell, doing something as trivial as this is *not* actually
possible to do efficiently with the Java frameworks (if at all), at least
as of 1.1.2. For starters, you can't actually tell if the clipboard
contents have changed without actually grabbing the contents (a problem
that seems typical of pastboard/clipboard handling on most systems), and
beyond that the clipboard support in 1.1.2 seems limited to handling
strings, and nothing else.


I'm sure there are all kinds of other examples I could come up with...
How's the support in Java for doing infinite levels of undo/redo? Again,
this is *trivial* with ObjC/Foundation/AppKit. I can see no built in
support for undo/redo in the 1.1.2 documentation. I will fully admit to
not having the docs for the 1.2 (Java 2) stuff, but I'd love to heard if
this sort of thing got added.

<nofill>
-Ken

---
Kenneth Dyke, ***@jumpgate.com (personal), ***@3dfx.com (work)
Staff Engineer, Cross Platform Development, 3dfx Interactive
C++: The power, elegance and simplicity of a hand grenade.

</nofill>
Philippe C.D. Robert
2000-01-29 18:05:09 UTC
Permalink
Hi!
Post by Guillaume Lessard
Whatever. Please let people carbonize, because I want apps on OSX!
Indeed, this is an important point!
Post by Guillaume Lessard
But more importantly, do you people realize the power of the class library
that comes with java?
Sure do we know about the class library, but 'the power of'?!...;-)
Post by Guillaume Lessard
A developer that starts coding from scratch with java will get results way
faster than by starting from scratch with O-C, *because* of the class
library. And please cease implying that java ain't polymorphic or cannot do
I wouldn't count on an API that sees major changes every major release... The
term 'deprecated API' isn't very trustful.... And the fact that there we have
1.1.x *and* 1.2 at the same time doesn't speak for Java, either....
Post by Guillaume Lessard
introspection. The only thing that is in O-C that's not in java is O-C
categories. However, what's in java and not in O-C is a huge class library
in constant evolution and growth. Wake up.
I don't want to start a flamewar either....

...but there is more than just categories that are missing in Java, i.e.
the ability of typeless programming that may affect overall app design,
well designed, stable APIs, speed, and so on....;-)

BTW IMHO it's not about what is really better, it's about what is *usable*! For
applets, Java is OK, but for real apps, 100% pure Java has yet to prove its
strength (on the desktop). All those large 100% pure Java projects I know of
have been canceled... Perhaps sometimes in the future, when you really can
compile Java or when there is more progress in JIT/HotSpot technology, but
*now*?!.... And when you now mention the ability to use Cocoa from Java, then I
don't see your point...

...and yes, there are of course pros for Java as well, i.e. garbage collection.
So to remain a bit more on topic, I would like to know if Apple (is somebody
listening to that?!....) plans to finally implement GC in cc and use it for
Cocoa? I know that this can be done (actually I think NeXT has done this years
ago in their labs, if I am not wrong?), since there is at least the
libFoundation that supports GC together with the gcc. And now that Apple has
finally assured us that ObjC will remain supported, this would make sense,
wouldn't it? (Well, I speak from a technical point of view, not marketing...).

sweet dreams, Phil
--
Philippe C.D. Robert
Developer - StudioSendai.com
Chris Hanson
2000-01-30 00:20:19 UTC
Permalink
Post by Guillaume Lessard
Whatever. Please let people carbonize, because I want apps on OSX!
Agreed 100%. Do NOT attack other approaches to getting applications
on Mac OS X. Certain members of the NeXT/Cocoa developer community
are UNBELIEVABLY hostile to anything that isn't Objective-C and
Cocoa. Their behavior towards non-believers is actually what's most
likely to kill this nice language/framework combination, by keeping
anyone who isn't a True Believer out of the club and thus preventing
further increases in demand for work on the Objective-C language and
the Cocoa frameworks on Apple's part.
Ronald C.F. Antony
2000-01-30 01:58:06 UTC
Permalink
Post by Chris Hanson
Post by Guillaume Lessard
Whatever. Please let people carbonize, because I want apps on OSX!
Agreed 100%. Do NOT attack other approaches to getting applications
on Mac OS X. Certain members of the NeXT/Cocoa developer community
are UNBELIEVABLY hostile to anything that isn't Objective-C and
Cocoa.
Some people are just unbelievable allergic to semi-truths, false claims
and the blind faith that "because it's from Apple, it must be the best"
even if it stinks. Most of the so called true believers actually use a
rather wide range of tools, from Python, Lisp, ObjC, WebScript, even
Java and C/C++ if required. It's just that some people don't seem
to be able to stomach it to be faced with the fact that they are still
using outdated and outmoded technology that is the result of Apple
in the past having rested on its laurels for too long and suffering
from a bad case of NIH. Now things are thankfully better.

The problem that remains, is that some of the Apple developers and
users are more like the Apple of the past than even Apple ever was.

The point is: it's perfectly fine to attack other approaches, if they
are technologically inferior. Don't attack the people however who
use them. If those people however can't distinguish between critique
of a particular way of doing things and being personally attacked,
then that's their problem and immaturity. However, as is the case
for all criticism: it should have good reasons, and the reasons
should be spelled out, such that an open mind can follow why the
criticism came to be.

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Chad Leigh, ObjectWerks, Inc.
2000-01-29 19:20:11 UTC
Permalink
--On Sat, Jan 29, 2000 11:09 AM -0800 Guillaume Lessard
Post by Guillaume Lessard
Post by John C. Randolph
Post by John C. Randolph
The traffic of Cocoa newbies in that group is just beginning, and
they're getting bad advice like "sure, go ahead and write your cocoa
apps in Java", or "Just carbonize your app. It won't suck, really!"
Whatever. Please let people carbonize, because I want apps on OSX!
But more importantly, do you people realize the power of the class
library that comes with java?
A developer that starts coding from scratch with java will get results
way faster than by starting from scratch with O-C, *because* of the
class library. And please cease implying that java ain't polymorphic or
cannot do introspection. The only thing that is in O-C that's not in
java is O-C categories. However, what's in java and not in O-C is a huge
class library in constant evolution and growth. Wake up.
This is not a flame, btw. It is merely intended as an equalizer to all
the mostly misguided anti-java sentiment that is continually expressed
on the list.
umm

I think some people would say that is the power of ObjC on MacOS X/OSXS:
the NS class library. This is a class library that has been under
development and evolution for 15 years and is proven to work!

Chad


Chad Leigh, VP Engineering
ObjectWerks, Inc.
Enterprise Solutions Provider and Consulting
***@objectwerks.com
Chris Hanson
2000-01-30 00:15:59 UTC
Permalink
Post by John C. Randolph
The traffic of Cocoa newbies in that group is just beginning, and
they're getting bad advice like "sure, go ahead and write your cocoa
apps in Java", or "Just carbonize your app. It won't suck, really!"
Yeah, the kind of advice people displaying this kind of attitude are
likely to give is SURE to drive Macintosh developers into Cocoa's
waiting arms.

Read the comments I made about marketing on Mac OS X Talk today. If
you want to really push Cocoa, be *sure* not to attack or even
mention the Toolbox. Otherwise you'll just be pushing people away.
Lawson English
2000-01-30 01:38:56 UTC
Permalink
Post by Chris Hanson
Post by Guillaume Lessard
Whatever. Please let people carbonize, because I want apps on OSX!
Agreed 100%. Do NOT attack other approaches to getting applications
on Mac OS X. Certain members of the NeXT/Cocoa developer community
are UNBELIEVABLY hostile to anything that isn't Objective-C and
Cocoa. Their behavior towards non-believers is actually what's most
likely to kill this nice language/framework combination, by keeping
anyone who isn't a True Believer out of the club and thus preventing
further increases in demand for work on the Objective-C language and
the Cocoa frameworks on Apple's part.
I'd point out QuickDraw GX as a cautionary tale, but I doubt that they'd
get the point...

-------------------------------------------------------------------------
Lawson English. Squeak, snore, etc.
Check out <http://www.squeak.org>
-------------------------------------------------------------------------
Scott Anguish
2000-01-29 17:41:59 UTC
Permalink
Post by Maury Markowitz
Post by Fabien Roy
I second that one.
I am willing to help but on this list.
Yes, but that's the PROBLEM. The Cocoa programmers group is so
insular that problems like this happen all the time. "I'll help, but
only if it's not a bother"? For shame!
That isn't a fair assessment of the situation.

First, anyone who is willing to answer the questions is
already going to 'the bother'.

However, I wouldn't expect at all to endure the bullsh*t
that Usenet entails (spam, cloaking email addresses, address
scraping), and wade into a group where there will be even more
argument about "what and how" advocacy crap. We've already seen
THREE of these in this group here, and we rely on this for technical
information.

Someone asks about programming in Cocoa, I'd suggest
pointing them to a place where it can be discussed in a technical
manner, without advocacy

..and that isn't likely to be comp.sys.mac.programmer.help
(based on the information that JCR passed along in that one email).

I walk into a room of people with a different 'religion', I
expect nothing but headaches. However, if I'm interested in learning
about someone else's 'religion', I'd visit a group where the
communication wouldn't be such an uphill battle.
J Guru
2000-01-31 15:28:54 UTC
Permalink
Post by Guillaume Lessard
A developer that starts coding from scratch with java will get results way
faster than by starting from scratch with O-C, *because* of the class
library. And please cease implying that java ain't polymorphic or cannot do
introspection. The only thing that is in O-C that's not in java is O-C
categories. However, what's in java and not in O-C is a huge class library
in constant evolution and growth. Wake up.<
I couldn't agree more. I've been programming in Java for ten years and its
worked pretty well for us. Why is everybody so insistent about living in the
past?

-J.G.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Mark Sandrock
2000-01-31 15:41:30 UTC
Permalink
Post by J Guru
...
I couldn't agree more. I've been programming in Java for ten years and its
worked pretty well for us. Why is everybody so insistent about living in the
past?
As opposed to living in a fantasy world? :)
J. Shan Bell
2000-01-31 16:32:45 UTC
Permalink
In an effort to keep this thread from deteriorating into useless
banter, I'm going to suggest that our combined experience can be used
for a common cause. I propose that we hack together a guide that can
help a developer determine which programming environment, Java or
Objective-C, is right for their project. It's obviously a non-trivial
determination, and I expect that it would be useful information for any
of us.

At the risk of getting bar-b-qued, here's what I suggest. List a few
major components of a software system that are fairly orthogonal. For
each component, rate it a J, O or E. If you judge that Java is the best
environment to implement that component, assign a J to it. O for
Objective-C or E if you think both environments are pretty equal.

I'll even volunteer to accept and compile this survey. Below is my
stab at the table and I'm even going to include my votes. For the sake
of full disclosure I have 8 years of Objective-C experience and 2 years
of Java experience.

Graphical UI O
Web Based UI J (if WO is used, then O here)
Character Based UI E
Multi-lingual UI E
Database Access J (if EOF is used, then O here)
Distributed Computing J
Batch Processing E
Networking J
Hardware Acceleration O
Portable J

Shan
David Young
2000-01-31 18:10:09 UTC
Permalink
Post by J Guru
I couldn't agree more. I've been programming in Java for ten years
and its worked pretty well for us.
Really now? Hum, what version did you start with back in 1990!

It would be REAL NICE if you would stick to FACTS.

DO YOU GET MY POINT!

10 years ago Java wasn't even a name and what first came out STUNK royally,
completely unusable. The first versions for the first year would grind
Windows 95 to a halt and bomb out after a few minutes. You should know better
than to spam this list with your silly commercials.

Thanks A Bunch! David Young; VVI-DCS
***@vvi.com
Ronald C.F. Antony
2000-02-01 00:08:11 UTC
Permalink
Post by J Guru
Post by Guillaume Lessard
A developer that starts coding from scratch with java will get results way
faster than by starting from scratch with O-C, *because* of the class
library. And please cease implying that java ain't polymorphic or cannot do
introspection. The only thing that is in O-C that's not in java is O-C
categories. However, what's in java and not in O-C is a huge class library
in constant evolution and growth. Wake up.<
I couldn't agree more. I've been programming in Java for ten years and its
worked pretty well for us. Why is everybody so insistent about living in the
past?
Java is *not* fully polymorphic, cause that would require "weak" typing
and it would break Java's notion of security. So don't insist Java
were fully polymorphic, it just ain't true. Of course, in the context
of web applets, that's a good thing, but in the context of a general
purpose OOPL it's bad.
It has no true class methods, thus inheritance breaks there.
It doesn't have a posing facility
It doesn't have a near-natural language syntax that allows for
self documenting code.
It has no categories,...
... and there is another point that I know that I keep forgetting, and
even though I use it all the time in ObjC, dang... whatever, it's all
in the archives.
So stop being so insistent that Java is just honkey dorey, and that
ObjC is in the past. ObjC/SmallTalk were so friggin ahead of their
time that languages like Java still play catch-up.

Just because all you have is a hammer doesn't mean every problem is a nail
that needs hitting on. People have solved very complex problems in
assembly language and in plain C. So just because you *can* get by with
Java and have been able to do so in the past, doesn't mean there are
not more elegant approaches to the same problem.
Other people have been using VisualBasic for ten years, so what?

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Eric Peyton
2000-01-31 16:35:27 UTC
Permalink
OK, Stop it. Everybuddy. This is a development list. The merits of Java
vs. ObjC and ObjC vs. Java have been discussed to death on this list. (As
have the merits of Python, Tcl/TK, C++, Assembly, Fortran, et. al.)
Check the archives if you want to find the pertinent information. You
wanna argue or cat scratch over them go to macosx-talk, irc or your
favorite bar. Not here please, it gets real old, whatever your opinions
may be.

Eric
Post by Mark Sandrock
Post by J Guru
...
I couldn't agree more. I've been programming in Java for ten years and its
worked pretty well for us. Why is everybody so insistent about living in the
past?
As opposed to living in a fantasy world? :)
Eric Peyton
***@epicware.com

Software and Source for Mac OS X
Mark Sandrock
2000-01-31 17:21:11 UTC
Permalink
Post by Eric Peyton
OK, Stop it. Everybuddy. This is a development list. The merits of Java
vs. ObjC and ObjC vs. Java have been discussed to death on this list. (As
have the merits of Python, Tcl/TK, C++, Assembly, Fortran, et. al.)
Check the archives if you want to find the pertinent information. You
wanna argue or cat scratch over them go to macosx-talk, irc or your
favorite bar. Not here please, it gets real old, whatever your opinions
may be.
Post by Mark Sandrock
Post by J Guru
...
I couldn't agree more. I've been programming in Java for ten years and its
worked pretty well for us. Why is everybody so insistent about living in the
past?
As opposed to living in a fantasy world? :)
I apologize if my comment read as a Java slam. It was the part about
having programmed in Java for ten years that I was referring to as
fantasy. I have no bone to pick with Java itself. Sorry about the
failed attempt at a little levity!
J Guru
2000-01-31 18:45:04 UTC
Permalink
Post by David Young
Really now? Hum, what version did you start with back in 1990!
Well, I started with C++ in 1989 and then went to Java (both superior
technologies to Objective C by the way). By the way, MFC kicks AppKit's ass.
Post by David Young
DO YOU GET MY POINT!
Do you really have to shout?

Cheers,

JG
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Stephen Peters
2000-01-31 19:27:03 UTC
Permalink
Post by J Guru
Post by David Young
Really now? Hum, what version did you start with back in 1990!
Well, I started with C++ in 1989 and then went to Java
Ah, yes. Reminds us all of the good ol' days when we were programming
Java in 1979 ('cause we started with C...which became C++...etc.)
Post by J Guru
(both superior technologies to Objective C by the way). By the way,
MFC kicks AppKit's ass.
Everybody sing! "Trollin'...Trollin'...Trollin' on a river..."
--
Stephen L. Peters ***@ai.mit.edu
PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6
"Poodle: The other white meat." -- Sherman, Sherman's Lagoon
Glenn Carnagey
2000-01-31 19:53:25 UTC
Permalink
Post by J Guru
Post by David Young
Really now? Hum, what version did you start with back in 1990!
Well, I started with C++ in 1989 and then went to Java (both
superior technologies to Objective C by the way). By the way, MFC
kicks AppKit's ass.
Mmmmm... smell that troll meat cooking! You forgot Pascal, and Z80
assembly -- even better, right? Oo-rah! You just the raddest trip
since LSD, ain't ya'.

Me, I miss patch cords on untunable synthesizers. And carting an
Osborne I around. Man, those were the days.

pax ex machina,
***@carnagey.com
Philippe C.D. Robert
2000-01-31 18:59:19 UTC
Permalink
Post by J Guru
Post by David Young
Really now? Hum, what version did you start with back in 1990!
Well, I started with C++ in 1989 and then went to Java (both superior
technologies to Objective C by the way). By the way, MFC kicks AppKit's ass.
poor guy....

sweet dreams, Phil
--
Philippe C.D. Robert
Developer - StudioSendai.com
Ronald C.F. Antony
2000-02-01 00:19:50 UTC
Permalink
Post by J Guru
Well, I started with C++ in 1989 and then went to Java (both superior
technologies to Objective C by the way). By the way, MFC kicks AppKit's ass.
That statement just disqualifies you permanently...
C++ and superior to ObjC, that's absolutely laughable. You obviously
have no clue what you're talking about.
With Java it's debatable at least, depending on what your priorities
are (web applets/portability vs. programming flexibility/expressiveness)
C++ at best qualifies as a C-code organizer, it's about ten miles away
from being a dynamic OOPL. Heck, it's not even object-oriented, because
the people who invented that term and SmallTalk have a set of properties
a language must have to qualify for that term, and C++ fails the test
miserably.

I have no problem if people disagree with me, but I do have a problem
if people make statements that are way off the mark and devoid of facts.

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Ronald C.F. Antony
2000-02-01 00:20:33 UTC
Permalink
Woops, that last one was supposed to be a private reponse. Sorry for
getting this onto the list...

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
justin armstrong
2000-01-31 18:49:07 UTC
Permalink
Post by David Young
Post by J Guru
I couldn't agree more. I've been programming in Java for ten years
and its worked pretty well for us.
Really now? Hum, what version did you start with back in 1990!
It would be REAL NICE if you would stick to FACTS.
DO YOU GET MY POINT!
10 years ago Java wasn't even a name and what first came out STUNK
royally,
Post by David Young
completely unusable. The first versions for the first year would
grind
Post by David Young
Windows 95 to a halt and bomb out after a few minutes. You should
know better
Post by David Young
than to spam this list with your silly commercials.
Thanks A Bunch! David Young; VVI-DCS
relax, people!
this looks very much like a troll!
Michael Brian Bentley
2000-01-31 19:20:16 UTC
Permalink
duh.
Bill Bumgarner
2000-01-31 19:03:41 UTC
Permalink
This is called a troll, folks... I.e. he is trolling for a reaction from folks.

Don't bite. Ignore him until he actually makes an intelligent point.

I.e;

What about C++ / Java is superior to Objective-C? Same goes for AppKit vs. MFC?

Making a flat out statement to that effect is virtually meanlingless. As
well, it demonstrates extreme ignorance... to flat out say that "Java is
superior to Objective-C in every way" is to basically admit that one has not
given the time to a deep analysis of the languages.

If you have something useful to say-- something that may raise serious
questions and better the community by making us all think and exchange
information-- then, by all means, please contribute. Otherwise, go away.

b.bum


From: "J Guru" <***@hotmail.com>
Date: 2000-01-31 10:56:20 -0800
To: Multiple recipients of list <macosx-***@omnigroup.com>
Subject: Re: JAVA - 10 years? yeah right.
Originator: macosx-***@omnigroup.com
X-Comment: To unsubscribe, follow directions at
http://www.omnigroup.com/MailArchive/
Post by David Young
Really now? Hum, what version did you start with back in 1990!
Well, I started with C++ in 1989 and then went to Java (both superior
technologies to Objective C by the way). By the way, MFC kicks AppKit's ass.
Post by David Young
DO YOU GET MY POINT!
Do you really have to shout?

Cheers,

JG
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
J Guru
2000-01-31 20:57:56 UTC
Permalink
Post by J. Shan Bell
I'll even volunteer to accept and compile this survey.
Thanks for putting this all together Shan. Good Stuff! Here's my ballot.

Graphical UI J
Web Based UI J
Character Based UI J
Multi-lingual UI J
Database Access J
Distributed Computing J
Batch Processing J
Networking J
Hardware Acceleration J
Portable J

Let me know when you get the results!

JG
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Fabien Roy
2000-02-01 03:04:57 UTC
Permalink
If you are going to deliver applications in Java you must make them Open
Source, this because there are some Java ByteCode decompiler out there and they
are excellent!!!

Cheers.

Fabien.
Paul Libbrecht
2000-02-01 03:10:27 UTC
Permalink
But there are obfuscators for that...
Post by Fabien Roy
If you are going to deliver applications in Java you must make them Open
Source, this because there are some Java ByteCode decompiler out there and
they
are excellent!!!
Cheers.
Fabien.
Patrick Coskren
2000-02-01 15:38:26 UTC
Permalink
Post by Ronald C.F. Antony
Java is *not* fully polymorphic, cause that would require "weak" typing
and it would break Java's notion of security. So don't insist Java
were fully polymorphic, it just ain't true.
I'm not disagreeing with this, but it's a funny thing: I've spent a little
time recently learning about Java Beans. And the thing that kept striking
me was how much the whole shebang felt like a way to shoehorn
Objective-C/Interface Builder runtime functionality onto Java.

You can take an object, query it at runtime for its methods, invoke an
arbitrary method programmatically even if it doesn't exist (you'll get an
exception) and generally, if you want to, sling things around as generic
Object instances regardless of whether they knew about each other at
compile-time. Is it as graceful as Objective-C? Nowhere near. But, if you
needed to, you could probably wrap stuff up in such a way as to provide
Objective-C-like functionality.

It's an interesting thing, because as far as I can see, Beans have achieved
nowhere near the adoption in the Java community that IB has in NeXT/Apple.
The fact that Sun is even trying could be read as validation of the approach
Objective-C has been taking for years.

-Patrick

------------
Patrick Coskren Staff Engineer BBN Technologies
Anders Pytte
2000-02-01 16:51:26 UTC
Permalink
Post by Patrick Coskren
It's an interesting thing, because as far as I can see, Beans have achieved
nowhere near the adoption in the Java community that IB has in NeXT/Apple.
The fact that Sun is even trying could be read as validation of the approach
Objective-C has been taking for years.
There does seem to be an attempt to merge the features of OO's two
threads in Java. I am not surprised that the result is a bit of a
mess. But I wouldn't think ObjC in particular was "validated" as a
result, since it is just a minor shoot off the SmallTalk branch.
Also, JavaBeans were instituted specifically for software component
engineering, rather than as a tip-of-hat to dynamic (SmallTalk) type
languages. Componenet engineering is rather new as a rage -
threatening to push aside "object oriented" as a phrase - and
JavaBeans afaik is the first commercial architecture (not really a
language) designed specifically for components. Well, there are the
Microsoft thingies, and the various distributed network architectures
and object models, not quite the same thing though, and - excuse me -
OpenDoc. ObjC is capable for component engineering but never widely
used or marketed specifically for the purpose. As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was. Check out the JavaBeans mailing lists and
news groups and you will find much more intense activity, I think,
than the ObjC equivalents. And that's just the beans

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Anders Pytte
2000-02-01 19:06:13 UTC
Permalink
A follow up:

Many people just think "plug-in" when they think JavaBean. But the
"component engineering" hoopla is that end users (or at least
technicians, but not software engineers) should be able to create
systems by assembling their choice of components. I want to add for
those unfamiliar with "component engineering" that its practice (and
to a lesser extent theory) is new and most would agree, I think, that
it is too soon to say whether it will really be practical to create
software systems of arbitrary complexity out of parts that were
designed with no knowledge of each other (until in(tro)spection
occurs at runtime).

To apprehend any more knee jerks, let me reassure you that I agree
ObjC would be a better candidate language for component engineering
than Java.

Anders.
Post by Anders Pytte
Post by Patrick Coskren
It's an interesting thing, because as far as I can see, Beans have achieved
nowhere near the adoption in the Java community that IB has in NeXT/Apple.
The fact that Sun is even trying could be read as validation of the approach
Objective-C has been taking for years.
There does seem to be an attempt to merge the features of OO's two
threads in Java. I am not surprised that the result is a bit of a
mess. But I wouldn't think ObjC in particular was "validated" as a
result, since it is just a minor shoot off the SmallTalk branch.
Also, JavaBeans were instituted specifically for software component
engineering, rather than as a tip-of-hat to dynamic (SmallTalk) type
languages. Componenet engineering is rather new as a rage -
threatening to push aside "object oriented" as a phrase - and
JavaBeans afaik is the first commercial architecture (not really a
language) designed specifically for components. Well, there are the
Microsoft thingies, and the various distributed network
architectures and object models, not quite the same thing though,
and - excuse me - OpenDoc. ObjC is capable for component engineering
but never widely used or marketed specifically for the purpose. As
far as adoption goes, remember that the "Java community" is way
bigger than the "ObjC community" ever was. Check out the JavaBeans
mailing lists and news groups and you will find much more intense
activity, I think, than the ObjC equivalents. And that's just the
beans
Anders.
----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Ronald C.F. Antony
2000-02-01 22:34:03 UTC
Permalink
Post by Anders Pytte
There does seem to be an attempt to merge the features of OO's two
threads in Java. I am not surprised that the result is a bit of a
mess. But I wouldn't think ObjC in particular was "validated" as a
result, since it is just a minor shoot off the SmallTalk branch.
ObjC's only justification is that it retains compatibility with
legacy C, C++ code and can be used even for systems programming.
Otherwise, there would have been no need to invent ObjC, and people
could have stuck with SmallTalk. Pretty much all shortcomings
ObjC has are the direct price being paid for C compatibility.
However ObjC doesn't sacrifice any of the dynamic aspects that
are important. Java does, and still isn't compatible with anything
but itself. So you pay a price, but you don't know what for.
A simple byte-code based SmallTalk engine could do what
Java does, and a lot more and a lot better. Heck, give people
an alternat syntax, if they are so afraid of brackets and so
attached to meaningless parameter lists like they are to be found
in C function calls.... And that's really what the critique of
Java boils down to; too little, too late, and no good reasons
for the compromises taken, given that there existed a language
that does all and more than what Java does (and I'm talking
about SmallTalk here, not ObjC). Had Java been invented in
the mid-seventies, it would have been revolutionary. As a
products of the nineties it's a boring warm-up of old concepts,
and they even managed to burn the food while reheating it...
Post by Anders Pytte
Componenet engineering is rather new as a rage -
threatening to push aside "object oriented" as a phrase - and
JavaBeans afaik is the first commercial architecture (not really a
language) designed specifically for components.
Well, VisualBasic and it's plug-ins (or whatever they are called),
and Corba also go after "components", albeit Corba at an even
coarser level.
Post by Anders Pytte
ObjC is capable for component engineering but never widely
used or marketed specifically for the purpose.
ObjC was never used widely or marketed for anything, that's the main
problem with the language, and something Apple will be able to change,
if they want to, as soon as OSX actually ships.
Post by Anders Pytte
As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was. Check out the JavaBeans mailing lists and
news groups and you will find much more intense activity, I think,
than the ObjC equivalents. And that's just the beans
Sure, but size and quality are two different things. To say something
is bigger is like saying something is red rather than blue. Past a certain
point, it's mostly a meaningless attribute.

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Michael Pelz Sherman
2000-02-01 17:45:01 UTC
Permalink
I dunno... I've always thought that palettized InterfaceBuilder "components" (available in
NEXTSTEP 1.0 over a decade ago) represented a "commercial architecture designed specifically for
components". Is there really a useful distinction to be made between components and objects,
especially when the classes in question are often so highly-functional (e.g. NSColorPicker)?

I'd also take issue with your comment that ObjC is not widely used for "component engineering".
Many very large enterprise systems from such companies as MCI, AT&T, Disney, the US Postal
Service, and Fannie Mae have used it for many years for exactly that purpose and continue to do
so.

Finally, despite the regrettable fact that the Java buzz is much bigger than ObjC's, that doesn't
necessarily mean it's "better" technology.

- Michael
Post by Anders Pytte
Post by Patrick Coskren
It's an interesting thing, because as far as I can see, Beans have achieved
nowhere near the adoption in the Java community that IB has in NeXT/Apple.
The fact that Sun is even trying could be read as validation of the approach
Objective-C has been taking for years.
There does seem to be an attempt to merge the features of OO's two
threads in Java. I am not surprised that the result is a bit of a
mess. But I wouldn't think ObjC in particular was "validated" as a
result, since it is just a minor shoot off the SmallTalk branch.
Also, JavaBeans were instituted specifically for software component
engineering, rather than as a tip-of-hat to dynamic (SmallTalk) type
languages. Componenet engineering is rather new as a rage -
threatening to push aside "object oriented" as a phrase - and
JavaBeans afaik is the first commercial architecture (not really a
language) designed specifically for components. Well, there are the
Microsoft thingies, and the various distributed network architectures
and object models, not quite the same thing though, and - excuse me -
OpenDoc. ObjC is capable for component engineering but never widely
used or marketed specifically for the purpose. As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was. Check out the JavaBeans mailing lists and
news groups and you will find much more intense activity, I think,
than the ObjC equivalents. And that's just the beans
Anders.
----------------------------------------------------------------
Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
----------------------------------------------------------------
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Anders Pytte
2000-02-01 18:24:44 UTC
Permalink
Post by Michael Pelz Sherman
I dunno... I've always thought that palettized InterfaceBuilder
"components" (available in
NEXTSTEP 1.0 over a decade ago) represented a "commercial
architecture designed specifically for
components". Is there really a useful distinction to be made between components and objects,
especially when the classes in question are often so
highly-functional (e.g. NSColorPicker)?
There is absolutely a useful and important distinction between
objects and components, as even a casual review of recent texts on
component engineering will reveal. The InterfaceBuilder "components"
with which i am well familiar are not components in the same sense
that JavaBeans are components. One might describe them as
component-like representations of objects by InterfaceBuilder.

The end user of a product created by PB/IB/ObjC/Foundation/AppKit
cannot easily swap roughly interchangeable components in and out of
the product (e.g. text processing engines, rendering services, etc.)
unless the code designer specifically engineers that capability into
the product.

So much for your irony.
Post by Michael Pelz Sherman
I'd also take issue with your comment that ObjC is not widely used
for "component engineering".
Many very large enterprise systems from such companies as MCI, AT&T, Disney, the US Postal
Service, and Fannie Mae have used it for many years for exactly that
purpose and continue to do
so.
I will not try to contest the proposition that use by a few large
organizations represents "widespread use", although I think that is
arguable. More questionable in my mind is whether this use really
constitutes "component engineering" in the current sense of the term,
as i attempted to describe above.
Post by Michael Pelz Sherman
Finally, despite the regrettable fact that the Java buzz is much
bigger than ObjC's, that doesn't
necessarily mean it's "better" technology.
I suppose there is no harm in repeating this for the ten millionth
time in this list, although I never said anything to the contrary.


Regards,

Anders.
Post by Michael Pelz Sherman
- Michael
Post by Anders Pytte
Post by Patrick Coskren
It's an interesting thing, because as far as I can see, Beans
have achieved
Post by Anders Pytte
Post by Patrick Coskren
nowhere near the adoption in the Java community that IB has in NeXT/Apple.
The fact that Sun is even trying could be read as validation of
the approach
Post by Anders Pytte
Post by Patrick Coskren
Objective-C has been taking for years.
There does seem to be an attempt to merge the features of OO's two
threads in Java. I am not surprised that the result is a bit of a
mess. But I wouldn't think ObjC in particular was "validated" as a
result, since it is just a minor shoot off the SmallTalk branch.
Also, JavaBeans were instituted specifically for software component
engineering, rather than as a tip-of-hat to dynamic (SmallTalk) type
languages. Componenet engineering is rather new as a rage -
threatening to push aside "object oriented" as a phrase - and
JavaBeans afaik is the first commercial architecture (not really a
language) designed specifically for components. Well, there are the
Microsoft thingies, and the various distributed network architectures
and object models, not quite the same thing though, and - excuse me -
OpenDoc. ObjC is capable for component engineering but never widely
used or marketed specifically for the purpose. As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was. Check out the JavaBeans mailing lists and
news groups and you will find much more intense activity, I think,
than the ObjC equivalents. And that's just the beans
Anders.
----------------------------------------------------------------
Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
----------------------------------------------------------------
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Maury Markowitz
2000-02-01 18:39:19 UTC
Permalink
Post by Michael Pelz Sherman
I dunno... I've always thought that palettized InterfaceBuilder
"components"
Post by Michael Pelz Sherman
(available in NEXTSTEP 1.0 over a decade ago) represented a "commercial
architecture designed specifically for components".
I tend to agree. My only real complaints with the implemented
system was...

1) palettes should be complete no-brainers. They aren't.
2) this is a developer level system, there's no consumer level system

On the last note I don't see anything as grandious as OpenDoc or
such, but seeing as RTF is inherently an "embeddable" document
format, it would be nice it the enviornment could make better use of
this fact. I can imagine a proxyView which does just what the name
implies, and the RTF parser can then use NS objects (NSTableView
etc.) to fill in the rich content and populate it. Then of course
I'd love a way to plug in my own objects into the RTF reader to do
stand-ins and additional views.

This would essentially make the document view capabilities of
AppKit a lot richer, and bring those component objects one step
closer to the user. That, I think, would be a "good thing".

Any serious technical issues I'm overlooking?

Maury
Michael Pelz Sherman
2000-02-01 19:15:22 UTC
Permalink
--- Anders Pytte <***@milkweed.com> wrote:
...
Post by Anders Pytte
There is absolutely a useful and important distinction between
objects and components, as even a casual review of recent texts on
component engineering will reveal. The InterfaceBuilder "components"
with which i am well familiar are not components in the same sense
that JavaBeans are components. One might describe them as
component-like representations of objects by InterfaceBuilder.
Well, I've read some of those texts, and I still don't think the distinction is all that useful or
obvious. Perhaps you could enlighten us? (Seriously, if you've got the time, I'm sure I'm not the
only one who'd be interested!)
Post by Anders Pytte
The end user of a product created by PB/IB/ObjC/Foundation/AppKit
cannot easily swap roughly interchangeable components in and out of
the product (e.g. text processing engines, rendering services, etc.)
unless the code designer specifically engineers that capability into
the product.
So much for your irony.
I really wasn't trying to be ironic, but if I understand you to mean that a "component", by
definition, must be "hot swappable" by the _end user_, do all Java Beans really meet this
definition? Doesn't the engineer ALWAYS have to specifically design the app to allow this
capability? Also, it isn't hard at all to do this sort of thing in an AppKit app; just use
poseAsClass: to swap classes at runtime.

That being said, it seems that one could argue that a better metaphor for "components" from the
AppKit world would be the Bundle.

Anyway, I think the point of the original post was that the ideas pioneered in the AppKit can be
seen as a (VERY early!) precursor to Java Beans. Those of us who've been doing these things for
years often get somewhat amazed that it has taken the industry this long to finally get around to
trying something similar.

- mps




__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Anders Pytte
2000-02-01 19:50:42 UTC
Permalink
Post by Michael Pelz Sherman
I really wasn't trying to be ironic, but if I understand you to mean that a "component", by
definition, must be "hot swappable" by the _end user_, do all Java Beans really meet this
definition? Doesn't the engineer ALWAYS have to specifically design the app to allow this
capability? Also, it isn't hard at all to do this sort of thing in an AppKit app; just use
poseAsClass: to swap classes at runtime.
Yes it is possible with JavaBeans; that's part of the point, that the
person configuring the components does not need anything proprietary.
No it isn't hard to do with ObjC if the engineer provides the
facility. I was only saying that this capability of PB/IB/ObjC/...
was not extensively exploited, and certainly was not ObjC's
conceptual germ as it was JavaBeans.

The intention of component engineering is to create a general market
for software components. Perhaps it is more of a marketing concept
than engineering: to allow market forces to break up the monolithic
software products and to thereby increase innovation, quality and
consumer choice. How this will finally take place is up in the air.
One breathtaking attraction is that it could open up a new frontier
for small developers. That may be why there is intense interest in
JavaBeans.

Obviously there are cases where interfaces between components should
be defined. Perhaps if the user has a "component inspector" they
could provide their own map between interfaces. Some components may
benefit from special knowledge of other "friendly" components which
allow them to go around a published interface. Etc., etc. I don't
think the principles on which all this interaction should take place
have crystallized yet. JavaBeans is just a wild stab. There are
certainly plenty of instances where proprietary interfaces have been
published to allow plug-ins, but I don't think they provide a guide
for the future.

I gotta sign-off for the day. Best regards.

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
J Guru
2000-02-01 19:28:11 UTC
Permalink
As far as adoption goes, remember that the "Java community" is way
bigger than the "ObjC community" ever was.
My point precisely.

JG

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
J Guru
2000-02-01 19:34:42 UTC
Permalink
...Java is just honkey dorey, and ... ObjC is in the past.
Ronald, glad to have you on the Java team.

JG
Subject: Re: To the keyboards, guys: comp.sys.mac.programmer.help.
Date: Mon, 31 Jan 2000 19:08:11 -0500
Post by J Guru
Post by Guillaume Lessard
A developer that starts coding from scratch with java will get results
way
Post by J Guru
Post by Guillaume Lessard
faster than by starting from scratch with O-C, *because* of the class
library. And please cease implying that java ain't polymorphic or
cannot do
Post by J Guru
Post by Guillaume Lessard
introspection. The only thing that is in O-C that's not in java is O-C
categories. However, what's in java and not in O-C is a huge class
library
Post by J Guru
Post by Guillaume Lessard
in constant evolution and growth. Wake up.<
I couldn't agree more. I've been programming in Java for ten years and
its
Post by J Guru
worked pretty well for us. Why is everybody so insistent about living in
the
Post by J Guru
past?
Java is *not* fully polymorphic, cause that would require "weak" typing
and it would break Java's notion of security. So don't insist Java
were fully polymorphic, it just ain't true. Of course, in the context
of web applets, that's a good thing, but in the context of a general
purpose OOPL it's bad.
It has no true class methods, thus inheritance breaks there.
It doesn't have a posing facility
It doesn't have a near-natural language syntax that allows for
self documenting code.
It has no categories,...
... and there is another point that I know that I keep forgetting, and
even though I use it all the time in ObjC, dang... whatever, it's all
in the archives.
So stop being so insistent that Java is just honkey dorey, and that
ObjC is in the past. ObjC/SmallTalk were so friggin ahead of their
time that languages like Java still play catch-up.
Just because all you have is a hammer doesn't mean every problem is a nail
that needs hitting on. People have solved very complex problems in
assembly language and in plain C. So just because you *can* get by with
Java and have been able to do so in the past, doesn't mean there are
not more elegant approaches to the same problem.
Other people have been using VisualBasic for ten years, so what?
Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one
persists
in trying to adapt the world to himself. Therefore all progress depends on
the
welcome
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Lawson English
2000-02-01 21:02:33 UTC
Permalink
Post by Michael Pelz Sherman
Post by Michael Pelz Sherman
I dunno... I've always thought that palettized InterfaceBuilder
"components"
Post by Michael Pelz Sherman
(available in NEXTSTEP 1.0 over a decade ago) represented a "commercial
architecture designed specifically for components".
I tend to agree. My only real complaints with the implemented
system was...
1) palettes should be complete no-brainers. They aren't.
2) this is a developer level system, there's no consumer level system
On the last note I don't see anything as grandious as OpenDoc or
such, but seeing as RTF is inherently an "embeddable" document
format, it would be nice it the enviornment could make better use of
this fact. I can imagine a proxyView which does just what the name
implies, and the RTF parser can then use NS objects (NSTableView
etc.) to fill in the rich content and populate it. Then of course
I'd love a way to plug in my own objects into the RTF reader to do
stand-ins and additional views.
OpenDoc "grandiose?" I thought that OD was trivial to implement using
Cocoa...
Post by Michael Pelz Sherman
This would essentially make the document view capabilities of
AppKit a lot richer, and bring those component objects one step
closer to the user. That, I think, would be a "good thing".
Any serious technical issues I'm overlooking?
Just that several prominent people in the Mac community asked Steve Jobs to
implement a Cyberdog-like facility in X using some variant of Interface
Builder, and he slapped them down quite hard, according to first-hand
accounts.



-------------------------------------------------------------------------
Lawson English. Squeak, snore, etc.
Check out <http://www.squeak.org>
-------------------------------------------------------------------------
Fabien Roy
2000-02-01 21:15:12 UTC
Permalink
None of what I have seen so far uses obfuscators even Apple does not use obfuscators.
I was told that obfuscators cannot hide everything and decompilers are getting
smarter.

Fabien
Post by Paul Libbrecht
But there are obfuscators for that...
Post by Fabien Roy
If you are going to deliver applications in Java you must make them Open
Source, this because there are some Java ByteCode decompiler out there and
they
are excellent!!!
Cheers.
Fabien.
Michael Pelz Sherman
2000-02-01 23:20:10 UTC
Permalink
Post by Anders Pytte
Many people just think "plug-in" when they think JavaBean. But the
"component engineering" hoopla is that end users (or at least
technicians, but not software engineers) should be able to create
systems by assembling their choice of components. I want to add for
those unfamiliar with "component engineering" that its practice (and
to a lesser extent theory) is new and most would agree, I think, that
it is too soon to say whether it will really be practical to create
software systems of arbitrary complexity out of parts that were
designed with no knowledge of each other (until in(tro)spection
occurs at runtime).
While I haven't studied Java Beans enough to make an intelligent side-by-side comparison, I think
it's probably a safe bet that had NEXTSTEP achieved a market anywhere near the size of Windows, a
marketplace for reuseable NEXTSTEP objects (like those found in the MiscKit) would have
flourished. With the advent of OS X, I wouldn't be surprised to see something like this develop.
There are already a few companies selling WebObjects Adaptors for various data sources; that might
be a good example.

Question: when a Java developer builds an app, does she not need to take certain steps to support
the use of Java Beans for specific purposes? In other words, just because an app is written in
Java doesn't mean you can interchange any of its classes with another, right? In a sense, it
seems, Java Beans are Java's answer to the "id", though I understand the marketing intent is more
than that.

- mps







__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Anders Pytte
2000-02-02 19:28:26 UTC
Permalink
Post by Michael Pelz Sherman
Question: when a Java developer builds an app, does she not need to
take certain steps to support
the use of Java Beans for specific purposes? In other words, just
because an app is written in
Java doesn't mean you can interchange any of its classes with
another, right? In a sense, it
seems, Java Beans are Java's answer to the "id", though I understand
the marketing intent is more
than that.
Present in your contributions to this thread is a wistful proposal
that Java, having realized its mistakes, is now on a path of
redemption towards the SmallTalk language model. I don't buy that.
Java was deliberately and thoughtfully modeled after the Simula
branch of OO language (which includes C++ and other statically linked
languages). It tries to take the best from a variety of languages of
that blood. Some folks do not even acknowledge that branch as "true"
OO language. Certainly many think the creators of Java made a mistake
in this choice, but I am not going to attempt to revive to that
exhausted debate.

JavaBeans is not an attempt to gain the dynamism of SmallTalk (i.e.
ObjC). It originates not from a strain of OO at all but from the
movement toward component engineering which - and you may find this
objectionable but it is true - is orthogonal to OO. Indeed, there is
absolutely no assumption that components will be built using OO
technologies. True, in the case of JavaBeans, you must use a more or
less OO language. But component engineering as a field of research, a
philosophy and even practice makes no such assumption. Look at IDL,
for example (Interface Design Language). Components do not generally
inherit anything, nor are they designed for sub-classing. Few of the
OO concepts readily translate to component engineering (specifically,
the concept of modularity predates OO).

Java is a statically linked OO language that uses a "runtime machine"
to gain some appearances of dynamism. This dynamism is not really a
design philosophy, but a solution to some of the requirements of
executing in a distributed environment. But the engineer - not the
user - decides which modules are acceptable for linking at runtime.
Generally this boils down to accepting or rejecting modules at
runtime based on their authenticity and version (that is my
impression, at least). It is a sort of code fragment management.

JavaBeans, rather than introducing the dynamism of SmallTalk and ObjC
into Java, allows Java to be used to create components, which may be
configured by users, possibly with the help of "component
inspectors". So no, JavaBeans are not in any way 'Java's answer to
the "id"'. Beans are not intended as semi-functional super-classes
onto which application specific behavior is grafted. They are not
interfaces to objects whose true type we never need to know but that
we keep in lists and manipulate via their shared characteristics.
Etc, etc. Beans are not engineering modules, that are deployment
modules. The more you examine this distinction, the more importance
it gains.

Regards,

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
J. Shan Bell
2000-02-02 21:49:44 UTC
Permalink
Post by Anders Pytte
JavaBeans is not an attempt to gain the dynamism of SmallTalk
(i.e. ObjC). It originates not from a strain of OO at all but
from the movement toward component engineering which - and you
may find this objectionable but it is true - is orthogonal to
OO. Indeed, there is absolutely no assumption that components
will be built using OO technologies. True, in the case of
JavaBeans, you must use a more or less OO language. But component
engineering as a field of research, a philosophy and even practice
makes no such assumption. Look at IDL, for example (Interface
Design Language). Components do not generally inherit anything,
nor are they designed for sub-classing. Few of the OO concepts
readily translate to component engineering (specifically, the
concept of modularity predates OO).
I really liked this take of component engineering. I was never really
comfortable with the tight coupling between objects and components and
this makes much more sense to me.

I would add that I don't agree with the opinion of the original author
that Beans are a way to make up for dynamic inadequacies in Java. But
by having a strongly typed language, you loose the ability to implement
"component-like" designs. This seems like a serious downfall. The
pattern I have in mind is the target/action one that InterfaceBuilder
uses with Objective-C objects (true, not real components).

Shan
Erik M. Buck
2000-02-02 00:36:19 UTC
Permalink
Post by Michael Pelz Sherman
Finally, despite the regrettable fact that the Java buzz is much bigger
than ObjC's, that doesn't
Post by Michael Pelz Sherman
necessarily mean it's "better" technology.
However, when it comes to Beans, Java is better. Objective-C could be just
as good. It is just that the Beans interfaces are intelligent, powerful,
and standard. Objective-C needs some standards and idioms similar to those
used for Beans. The corresponding features of Openstep and Objective-C are
IB Palettes and bundles. The IB palettes are less powerful, more haphazard,
and have never been adequately documented. Have you ever tried to make an
IBEditor subclass or play with IBConnections ? I have. It can be done, but
it is hard and undocumented.
Chad Cunningham
2000-02-02 03:20:29 UTC
Permalink
On a related note to this, anyone looked at http://gerbil.org/tom/ ? Looks
interesting... The ability to dynamically extend and modify classes at
runtime is an interesting idea.
--
Chad Cunningham
***@math.ohio-state.edu

Only 231 days until RSA Patent expiration!
Post by Ronald C.F. Antony
Post by Anders Pytte
There does seem to be an attempt to merge the features of OO's two
threads in Java. I am not surprised that the result is a bit of a
mess. But I wouldn't think ObjC in particular was "validated" as a
result, since it is just a minor shoot off the SmallTalk branch.
ObjC's only justification is that it retains compatibility with
legacy C, C++ code and can be used even for systems programming.
Otherwise, there would have been no need to invent ObjC, and people
could have stuck with SmallTalk. Pretty much all shortcomings
ObjC has are the direct price being paid for C compatibility.
However ObjC doesn't sacrifice any of the dynamic aspects that
are important. Java does, and still isn't compatible with anything
but itself. So you pay a price, but you don't know what for.
A simple byte-code based SmallTalk engine could do what
Java does, and a lot more and a lot better. Heck, give people
an alternat syntax, if they are so afraid of brackets and so
attached to meaningless parameter lists like they are to be found
in C function calls.... And that's really what the critique of
Java boils down to; too little, too late, and no good reasons
for the compromises taken, given that there existed a language
that does all and more than what Java does (and I'm talking
about SmallTalk here, not ObjC). Had Java been invented in
the mid-seventies, it would have been revolutionary. As a
products of the nineties it's a boring warm-up of old concepts,
and they even managed to burn the food while reheating it...
Post by Anders Pytte
Componenet engineering is rather new as a rage -
threatening to push aside "object oriented" as a phrase - and
JavaBeans afaik is the first commercial architecture (not really a
language) designed specifically for components.
Well, VisualBasic and it's plug-ins (or whatever they are called),
and Corba also go after "components", albeit Corba at an even
coarser level.
Post by Anders Pytte
ObjC is capable for component engineering but never widely
used or marketed specifically for the purpose.
ObjC was never used widely or marketed for anything, that's the main
problem with the language, and something Apple will be able to change,
if they want to, as soon as OSX actually ships.
Post by Anders Pytte
As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was. Check out the JavaBeans mailing lists and
news groups and you will find much more intense activity, I think,
than the ObjC equivalents. And that's just the beans
Sure, but size and quality are two different things. To say something
is bigger is like saying something is red rather than blue. Past a certain
point, it's mostly a meaningless attribute.
Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
Bill Garrison
2000-02-02 15:42:32 UTC
Permalink
Date: 2000-02-01 12:15:32 -0500
Subject: Re: Beans (was: To the keyboards... )
[snip]
used or marketed specifically for the purpose. As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was.
I guess the "Java community" could really beat up the "ObjC"
community in a celebrity death match...

Bill

--
William Garrison, CIT/ATS
Cornell University
Bill Coleman AA4LR
2000-02-02 15:50:44 UTC
Permalink
Post by Ronald C.F. Antony
However ObjC doesn't sacrifice any of the dynamic aspects that
are important. Java does, and still isn't compatible with anything
but itself. So you pay a price, but you don't know what for.
I attended a talk at WWDC 97 entitled "Uncommon Object Model." At that
session, they impressed on people that the run-time model for Objective C
and Java were practically identical. So, it was rather easy to adapt the
Cocoa interfaces to Java. By comparison, it would have been difficult or
impossible with C++.

They only mentioned two features of Objective C that were not present in
Java: Posing and Swizzling. (Not being an Objective C programmer, I'm not
really sure what they are) They indicated these features were rarely used
in Cocoa. So a Java programmer can use Cocoa without facing too many
limitations in what he can do.

Is this depiction correct? Putting implementation issues aside, what
Objective C features are missing in Java? Are Posing and Swizzling it?
Post by Ronald C.F. Antony
A simple byte-code based SmallTalk engine could do what
Java does, and a lot more and a lot better.
Interesting to note that Smalltalk and Java achieved their objectives
using very similar run-time techologies. I suppose if Smalltalk had been
invented in this more modern era of high-performance machines, it might
have seen greater popularity.
Post by Ronald C.F. Antony
Heck, give people
an alternat syntax, if they are so afraid of brackets and so
attached to meaningless parameter lists like they are to be found
in C function calls....
(Here comes one of those "what if" questions:)

What if one had an Objective C compiler that produced Java bytecodes?
Naturally, it would be limited to the functions present in the Java
run-time model. Certainly such a hypothetical product would overcome any
syntactic objections.

I don't buy the argument that Objective C is superior to Java merely
because of its syntax. Syntax usually comes down to personal preference.
Language features, on the other hand, limit what you can do or not do
with a given language.



Bill Coleman, AA4LR, PP-ASEL Mail: ***@radio.org
Quote: "Boot, you transistorized tormentor! Boot!"
-- Archibald Asparagus, VeggieTales
Craig E Rasmussen
2000-02-02 17:38:21 UTC
Permalink
Post by Bill Coleman AA4LR
They only mentioned two features of Objective C that were not present in
Java: Posing and Swizzling. (Not being an Objective C programmer, I'm not
really sure what they are) They indicated these features were rarely used
in Cocoa. So a Java programmer can use Cocoa without facing too many
limitations in what he can do.
Is this depiction correct? Putting implementation issues aside, what
Objective C features are missing in Java? Are Posing and Swizzling it?
Missing: How about pointers and some other items from C.
Added: Strong typing.

I have found that because of these differences, once I got my
Java programs to compile, they were mostly correct. I tended to
make a lot more errors in Obj-C. However, I found that I ended up
hating the casting (to interfaces) that the strong typing often required.

I'm not a language chauvinist. I really liked Obj-C and the AppKit,
there are a lot of things I like about Java, but recently I try
to do as much as possible in Python.

Craig
Ronald C.F. Antony
2000-02-03 00:23:52 UTC
Permalink
Post by Bill Coleman AA4LR
Post by Ronald C.F. Antony
However ObjC doesn't sacrifice any of the dynamic aspects that
are important. Java does, and still isn't compatible with anything
but itself. So you pay a price, but you don't know what for.
I attended a talk at WWDC 97 entitled "Uncommon Object Model." At that
session, they impressed on people that the run-time model for Objective C
and Java were practically identical. So, it was rather easy to adapt the
Cocoa interfaces to Java. By comparison, it would have been difficult or
impossible with C++.
Practically identical is a relative term. When compared to C++, yes.
When compared amongst (wannabe) dynamic OOPLs, then not.
Post by Bill Coleman AA4LR
They only mentioned two features of Objective C that were not present in
Java: Posing and Swizzling. (Not being an Objective C programmer, I'm not
really sure what they are) They indicated these features were rarely used
in Cocoa. So a Java programmer can use Cocoa without facing too many
limitations in what he can do.
There is more missing, but these are two of the big things.
But the fact that they are rarely used doens't mean that when they
are used they are not absolutely essential ingredients to achieve
an elegant solution. Yes, 80-90% of run off the mill code can be
written in Java as well as in ObjC. The rest is what matters, because
given that what I can write in Java I can also write in ObjC rather
easily, but not always the other way round, and because I have a
mind that's not too keen on constantly switching between languages
with subtle semantic differences, I like to choose the language
that lets me solve all the problems, not just the 80-90% Java
lets me do.
Posing allows one class to assume the functions of another.
This would e.g. a feature that's very handy when implementing
component software.
Swizzling refers to an object altering it's class at runtime,
i.e. the fact that the runtime is fully polymorphic (and doesn't
give a damn about what class it's messaging and what it inherits
from, as long as it gets the message (pun intended)).
One place where this is very essential is the much cited EOFault
object, that replaces itself with the real object on demand and
then assumes the proper class identity.
There are of course only a few lines of code where this feature
is used, yet of course the entire EOF framework depends on it
and that in turn is used in most WO apps and a great many
intranet applications.
So even the Java programming WO developers reap the benefits from
ObjC by using EOF.
Maybe I'm more prone to dynamic programming due to my background in
AI/Lisp/etc. but like people who programmed in Java would refuse to
go back to C++ once they realize what the added functionality
of Java does for them, so people who learned ObjC to the fullest
feel similarly about going back to Java. (And the few who are
fortunate enough to be able to get by with SmallTalk probably
would not like to step down to ObjC...)

But there is more than just these two things. Categories and syntax
are amongst them as is the dynamic typing.
Post by Bill Coleman AA4LR
Post by Ronald C.F. Antony
A simple byte-code based SmallTalk engine could do what
Java does, and a lot more and a lot better.
Interesting to note that Smalltalk and Java achieved their objectives
using very similar run-time techologies.
I know, and that what makes it so frustrating that the Java developer
stopped short when designing the language and left out important features.
Of course, to be fair, they wanted to program some set-top boxes and
didn't design Java as a general purpose language.
Java, like the web/http are essentially abused technologies, and are
pushed by hype and lemming-like masses who don't know any better.
The things the web is doing these days screams out loud for a new,
stateful protocol, and the things Java is used for these days screams
for languages like SmallTalk, CLOS, Python (so I hear) and ObjC.
Post by Bill Coleman AA4LR
I suppose if Smalltalk had been
invented in this more modern era of high-performance machines, it might
have seen greater popularity.
Sun just could have saved themselves the effort of developing a new
language and have adopted SmallTalk right away. An innovative implementation
and a set of decent class libraries could have gone further, than wasting
the resources on the language development and then not having enough to
develop good libraries.
Post by Bill Coleman AA4LR
Post by Ronald C.F. Antony
Heck, give people
an alternat syntax, if they are so afraid of brackets and so
attached to meaningless parameter lists like they are to be found
in C function calls....
(Here comes one of those "what if" questions:)
What if one had an Objective C compiler that produced Java bytecodes?
Naturally, it would be limited to the functions present in the Java
run-time model. Certainly such a hypothetical product would overcome any
syntactic objections.
It would make Java code more maintainable and more readable, and as
such would be a welcome addition. However, to remain precise,
there Java bytecodes are not restricted to Java, and really SUN is
just obfuscating the facts by calling them Java bytecodes.
The JVM is simply a virtual machine, that can run any number of types
of languages. e.g. there is a full Scheme (Lisp dialect) that compiles
into JVM, etc.
At that point we're down to method naming conventions. If we simply add
an ObjC-like syntax to Java but must use the Java libraries that
use methods of the form

someMethod(param1, param2, param3, param4), then we get an pseudo-ObjC

method call that looks like

[myObject someMethod:param1:param2:param3:param4]

and have the same unreadable code as if we had just written Java code.
ObjC syntax is not about brackets, it's about naming.
Here is a line of code I wrote some eight years ago:

return [self search:aNodeObject startingAtNode:aNode ofKind:[aNode class]];

I still understand it simply by looking at it, in plain English:
"Self, search a node object starting at node "aNode" of kind of "aNode"'s
class, and return it!" That would be a natural language equivalent.
See how similar that is? Try this in C or Java:

return self.searchStartingAtNodeOfKind(aNodeObject,aNode,aNode.class());

Ugh! :-(
Post by Bill Coleman AA4LR
I don't buy the argument that Objective C is superior to Java merely
because of its syntax. Syntax usually comes down to personal preference.
Language features, on the other hand, limit what you can do or not do
with a given language.
The language is not superior to Java "merely" because of its syntax, but
also because of its syntax. The language determines how we think, and
the closer we think to natural language, the better we do think (at
least most people do). What you can do with an MS-DOS like interface
with cursor keys and app-specific graphics is also "the same" as what
you can do with an integrated GUI environment, and if you're used to
MS-DOS, then you may resist the move to Windows or the Mac.
(Maybe most on this list here are either total kids or have memories
that fade quickly, but I remember the drasic fights that some people
put up about how all this GUI stuff is just a toy, and how they can
do everything with the old-style interface, etc.)
Same thing, just because you're *used* to a particular syntax may present
you with a barrier of acceptance and entrance to a new syntax, but
that doesn't mean that there are not *objective* (pun once more intended)
criteria by means of which the quality of a syntax can be evaluated.
I mean, to take an extreme example, how many here would like to program
in APL (I guess again an example that dates me...)?
The very same people who designed the now universally accepted GUI paradigm
invented SmallTalk and its syntax, and they didn't do it for the fun of
creating yet another syntax, but to create a language that was easy
to understand even by kids, that was to a large degree self-documenting,
and that was maintainable in the context of multi-year, multi-person
projects.
So we're not talking here about Pascal vs. C, or Algol vs. PL/1
differences in syntax, we're talking about a very clear departure
designed around the way the human mind works.
Most other languages are designed to be easily machine parsable, hence
all the parameters come in one big lump, SmallTalk is designed to
let disciplined programmers write easily human readable code.
(Of course, if you really want, you can unreadble junk even in SmallTalk,
but you actually have to take an effort, while it comes naturally in
C et al.)

Anyway, enough of this here...

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Christian Brunschen
2000-02-02 16:06:52 UTC
Permalink
Post by Bill Garrison
Date: 2000-02-01 12:15:32 -0500
Subject: Re: Beans (was: To the keyboards... )
[snip]
used or marketed specifically for the purpose. As far as adoption
goes, remember that the "Java community" is way bigger than the
"ObjC community" ever was.
I guess the "Java community" could really beat up the "ObjC"
community in a celebrity death match...
It is also quite ironic to quote 'size of developer community' numbers in
the context of development for the Macintosh - if that was all that
mattered, the developers in question would likely have gone to Windows
development to begin with...
Post by Bill Garrison
Bill
// Christian Brunschen
Frederic Stark
2000-02-02 16:28:20 UTC
Permalink
hi,
Post by Ronald C.F. Antony
However ObjC doesn't sacrifice any of the dynamic aspects that
are important
Not agreed. We should not get our mind so closed. We often feel that
users of Java/C++ are narrow minded because they have not been
enlightened by use of ObjC. Same thing here: it is not because we
learnt to work without some features that we don't need them.
Ronald C.F. Antony
2000-02-03 02:26:12 UTC
Permalink
Post by Frederic Stark
Post by Ronald C.F. Antony
However ObjC doesn't sacrifice any of the dynamic aspects that
are important
Not agreed. We should not get our mind so closed. We often feel that
users of Java/C++ are narrow minded because they have not been
enlightened by use of ObjC. Same thing here: it is not because we
learnt to work without some features that we don't need them.
I didn't say ObjC didn't sacrifice anything,...
Malcolm Cleaton
2000-02-02 16:30:40 UTC
Permalink
Post by Bill Coleman AA4LR
I don't buy the argument that Objective C is superior to Java merely
because of its syntax. Syntax usually comes down to personal preference.
Yes, _usually_syntax is just syntax and it doesn't matter.

If you try out Objective C's method-calling syntax where each argument of the
method is named, though, I predict you'll hate going back to languages which
stick them all on the end in a forgettable order. It might seem just another
trivial syntax issue, but it really does make code significantly more readable
and less error-prone. It saves time and effort. And it's just nice. So there.
:)

Cheers,

--
Malcolm Cleaton ***@plsys.co.uk
Tel: +44 1494 432422 P & L Systems
Fax: +44 1494 432478 http://www.plsys.co.uk
Leif Smith
2000-02-02 19:15:47 UTC
Permalink
I'm a learner, not a skilled C, Java, or Obj-C programmer. I'm enthusiastic about
object oriented languages.

I find that Obj-C is wonderfully self-documenting. I can look at the programs
and my first feeling is "this makes sense; I can learn this!". I don't get this
feeling when I look at C, C++, or Java.

Since we hope a lot of new programmers will learn to work in Mac OS X, maybe it
is worthwhile to point them to a language that will seem immediately inviting.
Obj-C talks like it wants to help you. The other languages talk like they are
making a contest out of it, as in "just try to figure me out; I defy you!".

This is not likely to make much sense to someone who is already a good programmer.
But try to remember what it was like starting out, when the things that are
now second sense to you each had to be mastered by an effort.

Smalltalk is like Obj-C in this way, but still on the OS X periphery. Neverthless,
see: http://squeak.cs.uiuc.edu (Squeak home page - remarkably interesting)

Leif Smith
Pattern Research
Denver, Colorado
http://www.pattern.com (not about computers or software patterns)
--

Begin forwarded message:

Date: Wed, 2 Feb 2000 10:07:14 -0800 (PST)
From: Malcolm Cleaton <***@plsys.co.uk>
To: Multiple recipients of list <macosx-***@omnigroup.com>
Subject: Re: [OT] Re: Beans (was: To the keyboards... )
Post by Bill Coleman AA4LR
I don't buy the argument that Objective C is superior to Java merely
because of its syntax. Syntax usually comes down to personal preference.
Yes, _usually_syntax is just syntax and it doesn't matter.

If you try out Objective C's method-calling syntax where each argument of the
method is named, though, I predict you'll hate going back to languages which
stick them all on the end in a forgettable order. It might seem just another
trivial syntax issue, but it really does make code significantly more readable
and less error-prone. It saves time and effort. And it's just nice. So there.
:)
Frederic Stark
2000-02-02 16:36:24 UTC
Permalink
[crunch]
Post by Bill Coleman AA4LR
Is this depiction correct? Putting implementation issues aside, what
Objective C features are missing in Java? Are Posing and Swizzling it?
Swizzling ? I don't know what this is supposed to be.

IMHO, there are mainly three features missing in java, from an ObjC
point of view: categories, categories and, obviously, categories.

[crunch]
Post by Bill Coleman AA4LR
What if one had an Objective C compiler that produced Java bytecodes?
Aaaaaaahhhh. *sigh*. This would be soooo nice...

Cheers,

--fred
Alexander Lamb
2000-02-03 07:34:55 UTC
Permalink
Post by Frederic Stark
[crunch]
Post by Bill Coleman AA4LR
What if one had an Objective C compiler that produced Java bytecodes?
Aaaaaaahhhh. *sigh*. This would be soooo nice...
I seem to remember that the lack of categories in Java is not a language
issue but a JavaVM issue. Indeed, you are not allowed to add methods to a
class once it is loaded. The only way to add categories would be to have
them all loaded at the same time when the class is loaded, preventing
therefore categories in bundles...

This, I think, was the state with Java 1.1

Alexander
Gary Teter
2000-02-02 18:29:09 UTC
Permalink
Post by Frederic Stark
[crunch]
Post by Bill Coleman AA4LR
What if one had an Objective C compiler that produced Java bytecodes?
Aaaaaaahhhh. *sigh*. This would be soooo nice...
Gee, and I was just thinking how cool it would be to have a Java compiler
that created binary executables for the ObjC runtime.....

--
Gary Teter, Big Dog
Bulldog Beach Interactive http://www.bulldogbeach.com
Sleep is for the weak.
Marcel Weiher
2000-02-02 19:40:48 UTC
Permalink
Philippe C.D. Robert
2000-02-02 21:49:31 UTC
Permalink
GC can be had for Objective-C if you want it, retain/release works
reasonable well, autorelease-pools actually have better deallocation
characteristics for many interactive tasks and quite a few
applications (certainly quite a few of mine) wouldn't work well in a
fully garbage-collected environment. For myself, the situation as is
I doubt this. A well implemented, generational and incremental GC should be at
least as good as RC in these days. In practice RC has proven to be not so well
(compared to tracing collectors) as one could imagine.

In fact GC for ObjC/Cocoa would be *very desirable*!

sweet dreams, Phil
--
Philippe C.D. Robert
Developer - StudioSendai.com
Greg Titus
2000-02-02 19:41:21 UTC
Permalink
Post by Frederic Stark
Post by Bill Coleman AA4LR
Is this depiction correct? Putting implementation issues aside,
what
Post by Frederic Stark
Post by Bill Coleman AA4LR
Objective C features are missing in Java? Are Posing and
Swizzling it?
Post by Frederic Stark
Swizzling ? I don't know what this is supposed to be.
Changing an existing object into another class by mucking with the
isa pointer. This is how EOFaults work, for instance. I would also
add forwarding and real "honest" class methods to the list of
features that Objective-C has that are missing in Java.

Unfortunately, it isn't easy to demonstrate how great these features
really are, because most of the time you don't need them. I'd guess
less than half of even experienced Obj-C coders have actually
implemented something that truly depends on forwarding or swizzling.
Posing is a little more common, but usually can be rebutted by "if
the library you were using was done right, you wouldn't need this".
Real class methods can be simulated using singletons.

When you do need those features though, it's because your design
just wouldn't be possible the same way otherwise. Without swizzling,
the way EOF works would be impossible. Without forwarding,
Distributed Objects couldn't work as transparently as it does.
Without them, you end up with hacks (usually code generation, like
many C++ and Java database-object mapping products, or like CORBA IDL
compilers). Sure it's still possible to write a bunch of code to get
most of the same features (these are all Turing complete languages,
after all), but at the cost of vastly increased complexity and
engineering time.
Post by Frederic Stark
IMHO, there are mainly three features missing in java, from an ObjC
point of view: categories, categories and, obviously, categories.
Which is why I continue to wonder why Java hasn't added categories
yet. This is the feature that nearly every Obj-C programmer uses all
the time, the benefits are obvious and easy to understand, you could
even get most of the benefits (just not overriding existing methods)
in a totally safe manner that would fit in with Java's type-safety
and security features.

Java already has all the neccesary dynamic dispatch logic in the
virtual machine, it would just take a couple minor revisions to the
class file format and class loader code. (It does depend on how you
implemented the method tables inside the JVM - if you used static
vtables like in C++ you'd have to reimplement, but you'd have to be a
moron to do that because you already have to do dynamic dispatch for
Java interface calls, and why have two big chunks of code to do
essentially the same thing?) There'd be some significant effort in
the compilers... but all this would be vastly easier and much more
useful IMHO, than, for example, adding parameterized types to Java.
Post by Frederic Stark
I'm not a language chauvinist. I really liked Obj-C and the AppKit,
there are a lot of things I like about Java, but recently I try
to do as much as possible in Python.
I'm sort-of a language chauvinist: I think it is quite clear that
different languages are better suited for different tasks. C is a
wonderful language for systems programming. Objective-C and Smalltalk
are wonderful languages for application programming (especially
enterprise apps). Perl is wonderful for string processing. Java is a
wonderful language for shipping safe chunks of code to run remotely
on other systems - applets, Jini, eventually maybe mobile agent
software. C++ is an abomination. The main worry I have about Java,
actually, is that over time more and more of the C++ cruft will get
added on.

--Greg
Craig E Rasmussen
2000-02-02 22:50:21 UTC
Permalink
Post by Greg Titus
Which is why I continue to wonder why Java hasn't added categories
yet. This is the feature that nearly every Obj-C programmer uses all
the time, the benefits are obvious and easy to understand, you could
even get most of the benefits (just not overriding existing methods)
in a totally safe manner that would fit in with Java's type-safety
and security features.
I don't think I've really groked the usefulness of categories. As
defined the NeXTSTEP general reference #2:

category: In the Objective C language, a set of method definitions that
is segregated from the rest of the class definitions. Categories can
be used to split a class definition into parts, or to add methods
to an existing class.

I'm assuming you find it useful because you can add methods to an
existing class. Why not just subclass? Oh, I suppose you want
users of that class to get the new behavior without recompiling
the entire framework. Am I thinking along the right lines?

Craig Rasmussen
Ronald C.F. Antony
2000-02-03 02:41:11 UTC
Permalink
Post by Craig E Rasmussen
I'm assuming you find it useful because you can add methods to an
existing class. Why not just subclass? Oh, I suppose you want
users of that class to get the new behavior without recompiling
the entire framework. Am I thinking along the right lines?
Think of plug-ins. You can have a plug-in define categories on
classes in the existing, precompiled application.
I'd bet that e.g. some of the Mail.app add-ons like colorizer, etc.
have used categories to achieve their purpose, but I don't know
for sure.
It would even allow for a manufacturer to ship plug-ins that actually
patch an application, and the user could dump a bundle into a
particular folder, and wouldn't have to re-install an entire app,
just because there is one method in some class that does something
bad.

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Bill Bumgarner
2000-02-02 21:33:26 UTC
Permalink
Swizzling: Ability to edit the runtime and replace any given method's
implementation on any class at any time. Dangerous stuff. Very, very useful
for debugging purposes and for fixing other people's code...

Posing: Ability to subclass any given class, then pose the subclass back as
the original class. This allows one to effectively override behaviour in any
given class in such a manner that everyone takes advantage of it. Very
useful. Not nearly as dangerous as swizzling, but you still have to be
careful.

Categories: Ability to add functionality to any given class-- including
replacing existing methods [posing allows you to override and still access the
original behaviour.

Neither posing nor categories allows for the addition of instance variables
directly-- they can be added via extended ivars.

There is a patch to egcs that generates JVM instructions..... don't know what
the state is, but it somewhat works. Someone would have to right an
implementation of the ObjC runtime in Java-- trivial to do, ObjC is remarkably
simple...

The lack of categories in Java is inexcusable. Totally and completely
inexcusable. There is *no* technical reason why it shouldn't be there and it
adds a *tremendous* amount of power to the language-- and can provably reduce
costs on project development through allowing for simpler overall
implementations. Security is *not* an issue-- just like the security managers
can prevent you from subclassing or accessing particular functionality, there
is no reason why they couldn't also prevent category like functionality.

(don't for a moment think I'm an ObjC bigot... I currently write code in many
languages and have written code in many others. They all have their strengths
and weaknesses. I use Java on a fairly regular basis-- beyond certain issues
with the current implementation, the most annoying aspect of the language are
the religious idiots that keep trying to convince me that anything but Java is
a waste of time. The same could be said for some of the folks in the ObjC
world-- but they are easier to ignore in that they generally only pop up--
myself occasionally included-- in response to one of the Java idiots)

b.bum

From: Frederic Stark <***@easynet.fr>
Date: 2000-02-02 10:20:03 -0800
To: Multiple recipients of list <macosx-***@omnigroup.com>
Subject: Re: [OT] Re: Beans (was: To the keyboards... )
X-Mailer: by Apple MailViewer (2.106)
Originator: macosx-***@omnigroup.com
X-Comment: To unsubscribe, follow directions at
http://www.omnigroup.com/MailArchive/

[crunch]
Post by Bill Coleman AA4LR
Is this depiction correct? Putting implementation issues aside, what
Objective C features are missing in Java? Are Posing and Swizzling it?
Swizzling ? I don't know what this is supposed to be.

IMHO, there are mainly three features missing in java, from an ObjC
point of view: categories, categories and, obviously, categories.

[crunch]
Post by Bill Coleman AA4LR
What if one had an Objective C compiler that produced Java bytecodes?
Aaaaaaahhhh. *sigh*. This would be soooo nice...

Cheers,

--fred
Michael Pelz Sherman
2000-02-02 22:03:54 UTC
Permalink
--- Anders Pytte <***@milkweed.com> wrote:
...
Post by Anders Pytte
Present in your contributions to this thread is a wistful proposal
that Java, having realized its mistakes, is now on a path of
redemption towards the SmallTalk language model. I don't buy that.
...

If I inadvertenly implied this, I apologize! I don't claim to have any idea where Java is headed.
You do have to give Sun credit for having added Reflection in 1.1, though. :-)

- mps
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Maury Markowitz
2000-02-02 22:34:48 UTC
Permalink
Post by Greg Titus
Which is why I continue to wonder why Java hasn't added categories
yet.
It's a feature interaction between categories and method
overloading. I can't name the example, but apparently there are
times where a category can result in the runtime being unable to
dispatch properly. I could find out the example if anyone's
interested.

There's also the security side of things. Let's say I categorize
your String's equal() to erase your drive.
Post by Greg Titus
vtables like in C++ you'd have to reimplement, but you'd have to be a
moron to do that because you already have to do dynamic dispatch for
Java interface calls
Hmmm, I think the gcj folks wouldn't like you calling them morons! :-)

Maury
Marcel Weiher
2000-02-02 23:36:23 UTC
Permalink
Post by Anders Pytte
Present in your contributions to this thread is a wistful proposal
that Java, having realized its mistakes, is now on a path of
redemption towards the SmallTalk language model. I don't buy that.
[Java <-> Simula connection snipped]
Post by Anders Pytte
It tries to take the best from a variety of languages of
that blood. Some folks do not even acknowledge that branch as "true"
OO language. Certainly many think the creators of Java made a mistake
in this choice, but I am not going to attempt to revive to that
exhausted debate.
JavaBeans is not an attempt to gain the dynamism of SmallTalk (i.e.
ObjC). It originates not from a strain of OO at all but from the
movement toward component engineering which - and you may find this
objectionable but it is true - is orthogonal to OO.
I have seen this claim made many times, including having read
Clement Szyperski's book on the subject. Even just a little bit of
analysis shows, however, that all the claims made for component tech.
are *identical* to requirements for well-written OO software.

"If you call a tail a leg, how many legs does a dog have? Four:
calling it a leg doesn't make it one" -- Mark Twain
Post by Anders Pytte
Indeed, there is absolutely no assumption that components will be
built using OO
Post by Anders Pytte
technologies.
Just as an object (see RM-ODP) does not reveal how it is
implemented, only that methods can be called.

[..]
Post by Anders Pytte
But component engineering as a field of research, a
philosophy and even practice makes no such assumption. Look at IDL,
for example (Interface Design Language). Components do not generally
inherit anything, nor are they designed for sub-classing.
OO research and practice has long aknowledged that black-box
frameworks (which use composition instead of inheritance) often make
for easier reuse than white-box frameworks. Frameworks tend to
evolve from white-box to black-box.
Post by Anders Pytte
Few of the OO concepts readily translate to component engineering ...
Hmm, actually most do. What's more, in the revers, *all* of the
tenets of component engineering I've seen so far map 100% to OO
concepts. So component engineering is a style of OO.
Post by Anders Pytte
(specifically, the concept of modularity predates OO).
Yes it does! OO is an advancement that goes beyond older modularity
mechanisms!
Post by Anders Pytte
Java is a statically linked OO language that uses a "runtime machine"
to gain some appearances of dynamism. This dynamism is not really a
design philosophy, but a solution to some of the requirements of
executing in a distributed environment.
What do you think dynamism is in dynamic OO languages? Exactly
that! A solution to some of the requirements of executing in a
distributed environment!
Post by Anders Pytte
JavaBeans, rather than introducing the dynamism of SmallTalk and ObjC
into Java, allows Java to be used to create components,
You are hiding an obvious contradiction by switching between intent
and implementation.

The intention is to provide facilities for creating components.

The highly dynamic mechanisms used closely mirror those used by
Smalltalk and Objective-C. This is not surprising, because highly
dynamic mechanisms are necessary for creating components. This is
what Smalltalks creators realized long ago, the fact that
Simula-style OO was not up to handling a world of "components" (which
they called objects).

You have to remember that the Smalltalk idea of objects was that of
independent computers talking to each other, a kind of monster
distributed system. Inheritance came later.
Post by Anders Pytte
which may be configured by users, possibly with the help of
"component
Post by Anders Pytte
inspectors".
I am probably missing something here, but just a couple of lines
earlier you stated that "the engineer, not the user" is responsible
for deciding.
Post by Anders Pytte
So no, JavaBeans are not in any way 'Java's answer to
the "id"'. Beans are not intended as semi-functional super-classes
onto which application specific behavior is grafted.
The notion of "id" and code reuse by inheritance are absolutely
orthogonal. You are creating a straw-man (just like Szyperski did).
Inheritance is *not* the fundamental idea behind OO. As a reuse
mechanism, it is much abused, a state of affairs lamented by probably
the most prominent of OO's creators, Alan Kay.

It is actually quite the other way around: "id" is an enabler for
creating compositional designs (which is why it gets reinvented by
every component technology: SOM, COM, CORBA, Beans, etc.).

In short, what you seem to define and deride as "OO" is nothing but
reuse by inheritance, which is nothing more than a particular style
of reuse possible with OO (and interestingly highly (ab-)used in
Simula-style languages). What you (and Szyperski) define as
"component" is nothing but a different style of OO, namely reuse by
composition (which is much more prelavent in Smalltalk style
languages).

Regards,

Marcel
Anders Pytte
2000-02-03 16:27:42 UTC
Permalink
***@metaobject.com wrote:

[major snip]

Wish I had the leisure to respond on a point by point basis. Of
course, you may take this as a concession.
Post by Marcel Weiher
In short, what you seem to define and deride as "OO" is nothing but
reuse by inheritance, which is nothing more than a particular style
of reuse possible with OO (and interestingly highly (ab-)used in
Simula-style languages). What you (and Szyperski) define as
"component" is nothing but a different style of OO, namely reuse by
composition (which is much more prelavent in Smalltalk style
languages).
I certainly did not ever in my entire lifetime deride anything "OO".
My main point was to distinguish between the uses of modularity in
engineering vs. deployment. You did appear to misread what remarks I
made to that effect. In any case, I find nothing wrong with anything
you say other than what appears to be a propensity to overlook the
obvious in what I was saying. I hope Mark Twain will indulge me: an
arm and a leg may have the same number of joints, but this does not
make them unworthy of distinction.

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Anders Pytte
2000-02-03 16:40:31 UTC
Permalink
Post by Anders Pytte
Post by Marcel Weiher
In short, what you seem to define and deride as "OO" is nothing but
reuse by inheritance, which is nothing more than a particular style
of reuse possible with OO (and interestingly highly (ab-)used in
Simula-style languages). What you (and Szyperski) define as
"component" is nothing but a different style of OO, namely reuse by
composition (which is much more prelavent in Smalltalk style
languages).
I certainly did not ever in my entire lifetime deride anything "OO".
My main point was to distinguish between the uses of modularity in
engineering vs. deployment. You did appear to misread what remarks I
made to that effect. In any case, I find nothing wrong with anything
you say other than what appears to be a propensity to overlook the
obvious in what I was saying. I hope Mark Twain will indulge me: an
arm and a leg may have the same number of joints, but this does not
make them unworthy of distinction.
Another note: for additional views on the difference between OO and
component engineering, to augment Szyperski, anyone interested could
consult papers by Bertrand Meyers and associates on the subject.

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Marcel Weiher
2000-02-02 23:52:35 UTC
Permalink
Post by Anders Pytte
I was only saying that this capability of PB/IB/ObjC/...
was not extensively exploited, and certainly was not ObjC's
conceptual germ as it was JavaBeans.
The intention of component engineering is to create a general market
for software components.
That was 100% the intention behind Objective-C. You might want to
try reading up on Brad Cox's work.

Marcel
Greg Titus
2000-02-03 00:12:39 UTC
Permalink
Post by Maury Markowitz
It's a feature interaction between categories and method
overloading. I can't name the example, but apparently there are
times where a category can result in the runtime being unable to
dispatch properly. I could find out the example if anyone's
interested.
Well, the only thing I can think of is if you compiled some code
that called MyClass->foo(Bar *), then later I added a category that
added MyClass->foo(Blech *). When the runtime sees the original
compiled code, does it know that I meant to call the instance of the
overloaded method for the Bar class, or is it confused because the
compiler only saw one method, while the runtime sees two?

The answer: No, the runtime wouldn't be confused. The reference in
the generated class file for the compiled code stores the types of
the arguments along with the method name. This happens whether the
compiler thinks that the method is overloaded or not. Parse some
.class files and you'll see.

So the problem must be more complicated than that... I'd be very
interested in seeing the example, yes.
Post by Maury Markowitz
There's also the security side of things. Let's say I categorize
your String's equal() to erase your drive.
Like I said, you could get most of the functionality, except for
overriding existing methods.
Post by Maury Markowitz
Post by Greg Titus
vtables like in C++ you'd have to reimplement, but you'd have to
be a
Post by Maury Markowitz
Post by Greg Titus
moron to do that because you already have to do dynamic dispatch
for
Post by Maury Markowitz
Post by Greg Titus
Java interface calls
Hmmm, I think the gcj folks wouldn't like you calling them
morons! :-)

I calls 'em like I sees 'em. :-)

(Note that I haven't looked at gcj at all, so I'm just taking your
word that I'd consider them morons. Heh.) :-)

We had a big discussion about method dispatch the Obj-C method cache
hash table way versus the C++ method vtable way just about a year
ago. You can get my point of view from:

http://www.omnigroup.com/OldLook/MailArchive/MacOSX-talk/1999/1730.html
http://www.omnigroup.com/OldLook/MailArchive/MacOSX-talk/1999/1735.html
http://www.omnigroup.com/OldLook/MailArchive/MacOSX-talk/1999/1742.html

--Greg
Marcel Weiher
2000-02-03 00:33:08 UTC
Permalink
Post by Philippe C.D. Robert
GC can be had for Objective-C if you want it, retain/release works
reasonable well, autorelease-pools actually have better
deallocation
Post by Philippe C.D. Robert
characteristics for many interactive tasks and quite a few
applications (certainly quite a few of mine) wouldn't work well
in a
Post by Philippe C.D. Robert
fully garbage-collected environment. For myself, the situation
as is
Post by Philippe C.D. Robert
I doubt this. A well implemented, generational and incremental GC
should be at
Post by Philippe C.D. Robert
least as good as RC in these days.
In the general case, this is the case. However, the general case
does not always apply. One important aspect is that RC is not
automatically performed during assignments/calls etc. as is the case
with most other RC schemes, but rather happens at the discretion of
the developer.

In the extreme case, this allows you to completely eliminate RC/GC
overheads if your program structure allows this. Zero overhead is
always better than some overhead.
Post by Philippe C.D. Robert
In practice RC has proven to be not so well
(compared to tracing collectors) as one could imagine.
Yes, I am quite aware of the studies done. Most of them do not take
into account the behavior of such schemes in virtual memory
environments, where gratuitously scanning large portions of otherwise
unused memory is often not a good idea.

Also, many of the very best algorithms require copying, which does
not mesh well with a native-compiled environment because GC needs to
be precise in this case (the train algorithm seems to be different,
wish I had an implementaton to look at). They also often require
fixed pre-allocated regions (for example for the write-barrier
implementation) and a closed world assumption, therefore being
somewhat incompatible with the Mach way of fragmented VM allocation
as well as passing memory between tasks in messages (or mapping it in
other ways).

Another problem for these algorithms is finalization, because
objects aren't explicitly deallocated but rather simply get
overwritten by new objects if they weren't copied in the young-space
reclamation. This is of course inacceptable if these objects hold on
to external resources, so fairly complex mechanisms have to be in
place to deal with finalization.

A more philosophical problem I have with copying GC is that it's
global and non-optional once in place, whereas for me OO is about
objects being responsible for themselves, in essence having local
control. An object just disappearing wtihout politely being asked to
go away just grates me the wrong way :-)
Post by Philippe C.D. Robert
In fact GC for ObjC/Cocoa would be *very desirable*!
What would be great is a -releaseTakingCyclesIntoAccount method.
That would give you the convenience of GC, if and when you actually
need it, while retaining all the benefits of the current scheme.

Marcel
Marcel Weiher
2000-02-03 00:35:38 UTC
Permalink
Post by Michael Pelz Sherman
....
Post by Anders Pytte
Present in your contributions to this thread is a wistful proposal
that Java, having realized its mistakes, is now on a path of
redemption towards the SmallTalk language model. I don't buy that.
....
If I inadvertenly implied this, I apologize! I don't claim to have
any idea where
Post by Michael Pelz Sherman
Java is headed.
You do have to give Sun credit for having added Reflection in 1.1,
though. :-)

And there are some docs about a limited version of forward:: in 1.3.

Marcel
Erik M. Buck
2000-02-03 00:54:34 UTC
Permalink
Post by Maury Markowitz
There's also the security side of things. Let's say I categorize
your String's equal() to erase your drive.
What are you talking about ?

First, Applets do not allow any operations that work outside the VM.
Writing to hard disks is not allowed.

Second, if I am running an application (not applet) without security I
presumably trust the author. What stops any author from making any function
of any application erase your drive ?

Third, categories could go through exactly the same security checks that all
loaded classes go through.

Fourth, the use of the final keyword (as with String's equal() ) probably
would prevent overloading via categories anyway do to the semantics of final
and the common VM implementation.
Greg Titus
2000-02-03 01:32:03 UTC
Permalink
Post by Craig E Rasmussen
I don't think I've really groked the usefulness of categories.
[...]
Post by Craig E Rasmussen
I'm assuming you find it useful because you can add methods to an
existing class. Why not just subclass? Oh, I suppose you want
users of that class to get the new behavior without recompiling
the entire framework. Am I thinking along the right lines?
The question to ask yourself is: what do I do if I want to get the
additional behavior and I don't have the source code to the original
class?

I wish I could find the last time I posted about this... :-)

Imagine that I want to add methods to an existing class: In
particular, I want to add a "isPalindrome" method to the String
class. There are always going to be things like this where you want
to add some functionality to an existing class that is specific to
your particular application. In a language without categories I have
three choices: (1) subclass the String class, (2) make just a
IsThisStringAPalindrome() function (maybe a C++ friend function, or a
class method on some random Java class), or (3) paste the code
inline wherever I need it.

It's pretty obvious that (2) and (3) are bad object-oriented design.
If a stand-alone function or cut-n-pasted code doesn't sound that
bad to you, I'm sure someone else can do the obligatory
object-oriented evangelism much better than I. :-)

So you go ahead with writing your subclass "PalindromeString". No
problem. Any strings I create myself in my application, I'll make my
subclass.

But wait - what if I want to see if the string someone enters in a
text field is a palindrome? If I call it's stringValue method, it'll
return to me a normal String and not a PalindromeString. So, being
the correct OO practitioner that I am, I write a subclass of
TextField called PalindromeTextField that adds a
"palindromeStringValue" method. (Pretty simple, it just calls the
superclass stringValue method, then initializes a new
PalindromeString from the result).

I move on through the rest of my application, implementing a
subclass for every single class that I use in any of my included
libraries in order to make methods that return PalindromeStrings
where the existing methods return normal Strings. With such a
widespread common class like String, I'll end up with a ton of these
trivial subclasses. Or I end up with a giant confusing mess where
some of my API takes String instances and other methods use
PalindromeString instances, greatly complicating everything.

So what's the result of all this? I've gone to a lot of boring work
to produce a dozen or more trivial subclasses, complicating my whole
application, and nearly every time I deal with strings I create twice
as many objects (a normal String and a PalindromeString). This is a
very common pattern in large C++ projects. It gets exponentially
worse when you are using more than one third-party library which
each, very commonly, has its own different String class that is used
internally because they wanted to add that one extra method that they
used... this is one of the common reasons why large C++ projects end
up with hundreds and hundreds of small classes. (I don't have
experience of enough large Java projects to make a similar blanket
statement there - but it would surprise me if the trend wasn't
similar.)

Often, the programmer will realize how much work it would be to do
all this subclassing, and just puts the code in wherever (s)he needs
it (bam, there's more difficult maintainability, and reuse is out the
window). Or the programmer will demand source code to any libraries
which (s)he uses in order to add the extra method directly and
recompile (good luck migrating when the next version comes out, and
you now have a ton more code you have to deal with).

In Objective-C, you just add your method to the existing class with
a category. All the other code that has already been written (yours
or not) is automatically producing objects of the correct class, and
you can use the new method anywhere you want without worrying about
doing any conversions. There is also a major advantage in being able
to split up the functionality in a single class in multiple
frameworks for architectural reasons, even if you do have access to
all of the source code involved. For example, the methods for basic
manipulation of an NSString are in Foundation; the methods for
drawing a string are in AppKit. Finally, with large classes, it can
often be useful to split the class into multiple source code files,
each with related methods (sometimes it'd be a good idea to make
these constructs into a group of multiple related classes instead of
one large class, but sometimes it isn't.) This is also facilitated by
categories.

-Greg
Ronald C.F. Antony
2000-02-03 08:59:55 UTC
Permalink
One use of categories I know Greg knows about, but which I think is
essential from the point of programming discipline, is to put all
primitie methods of a class in one category.
With primitive methods I mean the ones that a class relies on, such
as the ones a subclass in a class-cluster has to implement in order
to inherit all the functionality defined in the abstract parent
class.
Amongst those are the designated initializer, accessor functions, etc.
This allows me to check for code dependencies at one, and only one,
source file, because I know all other methods in other categories are
implemented in terms of these primitives and will automatically do
"the right thing TM" if the methods in that particular category are
clean.
This cuts down a lot of bug-hunting when making additions to classes,
and besides, the mere fact that the source file in question is smaller
increases productivity...

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Scott Anguish
2000-02-03 05:44:13 UTC
Permalink
Post by Ronald C.F. Antony
Post by Craig E Rasmussen
I'm assuming you find it useful because you can add methods to an
existing class. Why not just subclass? Oh, I suppose you want
users of that class to get the new behavior without recompiling
the entire framework. Am I thinking along the right lines?
Think of plug-ins. You can have a plug-in define categories on
classes in the existing, precompiled application.
I'd bet that e.g. some of the Mail.app add-ons like colorizer, etc.
have used categories to achieve their purpose, but I don't know
for sure.
I can't speak for Colorizer specifically.. but I can for the
SWSignature bundle (whose name is rather misleading at this
point)... it relies heavily on categories to get the access it does.

categories don't replace the need for a proper API though.
Marcel Weiher
2000-02-03 07:58:46 UTC
Permalink
Post by Ronald C.F. Antony
The very same people who designed the now universally accepted GUI
paradigm
Post by Ronald C.F. Antony
invented SmallTalk and its syntax, and they didn't do it for the fun of
creating yet another syntax, but to create a language that was easy
to understand even by kids, that was to a large degree
self-documenting,
Post by Ronald C.F. Antony
and that was maintainable in the context of multi-year, multi-person
projects.
Another important thing to note is that they actually experimented
with the syntax, changing it around several times until they found a
version that worked well.

See Smalltalk-80: Bits of History, Words of Advice by Glenn Krasner.
A marvelous insight into pragmatic language research.

Marcel
Marcel Weiher
2000-02-03 08:11:39 UTC
Permalink
Squeak is unfortunately slavishly emulating the original
SmallTalk, with
all it's limitations. The result is, it's like a toy. Despite all
of what
SmallTalk did for GUIs, I don't want to go back to the 80s.
Although Squeak does contain the old MVC user interface, this is
retained purely as legacy support. The new user interface called
Morphic was inspired by the SELF user interface of the same name. It
is quite different in that the UI is very concrete, event driven,
etc. There are also other nifty things like a version of the Alice
3D user scripting environment (+ the ability to manipulate 2D
application windows texture-mapped onto 3D shapes, ...).
Someone needs to take the Squeak engine, dump most of the GUI classes,
and retrofit the entire system to use the AppKit, EOF, WO, etc.
*Then* we'd have something to celebrate...
The MacOS-X-Server port of Squeak has an Objective-C bridge, so
Squeak can transparently instantiate and send messages to native
Objective-C objects. I am also working an an Objective-C generator
that takes Squeak classes and dumps them to Objective-C + an
Objective-C version of the interpreter itself.

The reverse, Objective-C calling into Squeak is more difficult,
primarily because of issues with the copying garbage collector (your
objects may be moved at any time when inside Squeak). Tim Rowledge,
a contributor to the Squeak list implemented a Squeak VM with a
non-copying garbage collector (a version of the train algorithm I
mentioned earlier), but that work doesn't seem to be available, yet.
The way squeak is now, it's useless for any commercial development.
Someone needs to do the OSX equivalent of VisualAge SmallTalk,
something
that lets one create native SmallTalk apps that can use and extend the
Cocoa framworks and classes, or something that mirrors them to the T.
Was that the sound of you volunteering to help? :-)

Marcel
Marcel Weiher
2000-02-03 09:24:02 UTC
Permalink
Hi Ronald,

I am hoping that one of these messages gets through (I typically get
a mailer error when sending e-mail directly to you).

MPWFoundation is Metaobject's foundation framework. It can be
downloaded as part of the Objective-XML package from
http://www.metaobject.com/downloads/.

In addition to various smaller additions/fixes it provides the
following services:

- trampolines for higher order messaging
- higher order messages are messages that take messages as
arguments
- they make for nicer syntax + more general solution almost
anywhere you
traditionally use selectors.
example: [[someObject async] longRunningMethod:param1
and:param2];
vs. [NSThread
detachNewThreadSelector:@selector(longRunningMethod:and:)
toTarget:someObject withObject:param1] (and where does param2 go?)

- generalized iteration based on higher order messaging
- upStrings = [[myStrings collect] asUppercase];
- combined = [[myPrefixes collect]
stringByAppendingString:[mySuffixes each]]
(for appending a list of suffixes to a list of prefixes)
- [[someObjects do] somethingUseful:argument];
vs. [someObjects
makeObjectsPerformSelector:@selector(somethingUseful:)
withObject:argument]

- MPWStreams
- write-only, composable object-processing streams
- byte-processing streams as specialized subclasses

- object-caches
- avoid object allocation overheads for temporary objects
- send objects accross APIs just as efficiently as primitve
types (well, almost)

- float and short integer array classes
- with full support for performing operations on all elements

- experimental run-time expression creation/evaluation using HO-messaging
...

[GNU Foundations]
I haven't used either of those yet, since I have my NeXTs and now
a G4, but long term I'm interested in getting at least on GNUStep
platform running, possibly ontop of a Darwin kernel to lower the
sysadmin overhead. But what are the relative merits these days?
I haven't used them since the GNU-cleanup, so I all I can say is
that libFoundation was OK for production use (we spent a total of 1-2
days fixing things) almost 3 years ago. I don't think it has
deteriorated in the meantime. A better person to ask would Helge
Hess of MDLink (Helge, are you there?).

Marcel
Frederic Stark
2000-02-03 09:26:20 UTC
Permalink
Post by Maury Markowitz
Post by Greg Titus
Which is why I continue to wonder why Java hasn't added categories
yet.
It's a feature interaction between categories and method
overloading. I can't name the example, but apparently there are
times where a category can result in the runtime being unable to
dispatch properly.
I doubt that.
Post by Maury Markowitz
I could find out the example if anyone's
interested.
It would be interesting.

Cheers,

--fred
Frederic Stark
2000-02-03 11:11:50 UTC
Permalink
Post by Greg Titus
Post by Craig E Rasmussen
I don't think I've really groked the usefulness of categories.
[...]
Post by Greg Titus
Post by Craig E Rasmussen
I'm assuming you find it useful because you can add methods to an
existing class. Why not just subclass? Oh, I suppose you want
users of that class to get the new behavior without recompiling
the entire framework. Am I thinking along the right lines?
The question to ask yourself is: what do I do if I want to get the
additional behavior and I don't have the source code to the original
class?
And there is the added value that your own addition to base kits are
first-class citizen. The isPalindrome is a method of NSString that
is no different of others.

This means that one can (and often do) specialize a framework to
suit its needs, hence getting a kind of framework subclassing
functionality (which is of a tremendous interest)

Someone writing a Statistical application may have a need to for
Statistical distributions. He could easily add

@interface NSArray(StatAdditions)
- (id)randomObject;
- (id)randomObjectUsingDistribution:(Distribution *)aDistribution;
@end

with a few judicious additions, the user can leverage FoundationKit
into a StatisticalFoundation kit and write its application with it.

Cheers,

--fred
Frederic Stark
2000-02-03 13:13:53 UTC
Permalink
You're forgetting the biggie: blocks providing facilities for
higher-order programming. Higher order messaging (as provided by
MPWFoundation) provides very similar benefits, better in some ways,
worse in others.
Obviously. (Banging my head on the wall a couple of times).
Multi-methods go fairly strongly against the object-centric model
that Smalltalk and Objective-C are based on. I prefer repeated
single dispatch (ping-pong style), used heavily for example in
MPWFoundation's Stream abstraction.
I often miss multi-methods in ObjC. Ping-pong is nowhere as clear,
and is (IMHO) a pain to maintain. Fortunately, categories helps here.
I may be missing what you're saying, but methods for creating
singletons
I was refering to dylan singletons. This is specialising a method on
an single instance instead of a class. Coupled with multi-methods,
it brings dynamic templates (in the C++ sense).

Cheers,

--fred
Frederic Stark
2000-02-03 13:13:05 UTC
Permalink
Sorry for the length of this. And for the spelling too, probably.
- Multi-methods
Methods that do dispatch on more than one argument (ie: with
multiple receiver)

When you have a method that take an object as its arguments and take
decision based on the class of this argument, you end up doing
'ping-pong' code (ie: the implementation of the method calls another
method with the argument as receiver). This lead to sometimes ugly
code, and adding another case can lead to large amount of code
duplication.

Let's take an example. When you encode objects, you need both an
encoder and an object to encode. What way are you going to implement
it ?

Is the main interface going to be:

@interface NSObject(Encode)
- (void)encodeIntoEncoder:(Encoder *)anEncoder;
@end

or:

@interface Encoder
- (void)encodeObject:(id)anObject;
@end

(Encoding/decoding is not a good example because of the large
dissimetry between the two hierarchies. Suppose that there are very
few kind of objects to encode, but that a lot of different encoders
are planned, to correct the dissimetry)

Say you have a function to output data:

EMIT( NSString * );
(ie: the whole purpose of those encoders are to EMIT() chunks of
data. Clearly, there would be a third class at work here, but it is
omited for clarity)

Knowing that you'll have different work to do for different classes
of objects, and different encoders, you have two path:

// CASE 1

// ENCODERS HAVE THE BRAIN
@interface Encoder(Brain)
- (void)encodeString:(NSString *)aString;
- (void)encodeNumber:(NSNumber *)aNumber;
@end

// OBJECTS DO THE DISPATCH
@implementation NSObject(Encode)
- (void)encodeIntoEncoder:(Encoder *)anEncoder
{ assert(NO);
}
@end

@implementation NSString(Encode)
- (void)encodeIntoEncoder:(Encoder *)anEncoder
{ [anEncoder encodeString:self];
}
@end

@implementation NSNumber(Encode)
- (void)encodeIntoEncoder:(Encoder *)anEncoder
{ [anEncoder encodeNumber:self];
}
@end

// DEFAULTS
@implementation Encoder(Brain)
- (void)encodeString:(NSString *)aString
{ assert( NO );
}
- (void)encodeNumber:(NSNumber *)aNumber
{ assert( NO );
}
@end

// BRAIN FOR TEXT ENCODER
@implementation TextEncoder(Brain)
- (void)encodeString:(NSString *)aString
{ EMIT( [NSString stringWithFormat:@"STR:%@", aString] );
}
- (void)encodeNumber:(NSNumber *)aNumber
{ EMIT( [NSString stringWithFormat:@"NUM:%@", aNumber] );
}
@end

Or:

// CASE 2

// OBJECTS HAVE THE BRAIN
@interface NSObject(Brain)
- (void)encodeToTextEncoder:(TextEncoder *)anEncoder;
@end

// ENCODERS DO THE DISPATCH
@implementation Encoder(Encode) : Encoder
- (void)encodeObject:(id)anObject
{ [anObject encodeToTextEncoder:self];
}
@end

@implementation TextEncoder(Encode) : Encoder
- (void)encodeObject:(id)anObject
{ [anObject encodeToTextEncoder:self];
}
@end

// DEFAULTS
@implementation NSObject(Brain)
- (void)encodeToTextEncoder:(TextEncoder *)anEncoder
{ assert( NO );
}
@end

// BRAIN FOR TEXT ENCODER
@implementation NSObject(Brain)
- (void)encodeToTextEncoder:(TextEncoder *)anEncoder
{ assert(NO);
}
@end

@implementation NSString(Brain)
- (void)encodeToTextEncoder:(TextEncoder *)anEncoder
{ EMIT( [NSString stringWithFormat:@"STR:%@", self] );
}
@end

@implementation NSNumber(Brain)
- (void)encodeToTextEncoder:(TextEncoder *)anEncoder
{ EMIT( [NSString stringWithFormat:@"NUM:%@", self] );
}
@end

(This example is useless and ridiculous, but I hope you get the
point. We all wrote code like that sometimes)


Multiple dispatch solution is in the lines of (in pseudo-code):

Encode( NSObject *, Encoder * ) { assert( NO ); }

Encode( NSString *s, TextEncoder *e ) { EMIT( [NSString
stringWithFormat:@"STR:%@", s] ); }
Encode( NSNumber *n, TextEncoder *e ) { EMIT( [NSString
stringWithFormat:@"NUM:%@", n] ); }

Adding a new encoder is something like:

Encode( NSString *s, VerboseEncoder *e ) { EMIT( [NSString
stringWithFormat:@"The string is:%@", s] ); }
Encode( NSNumber *n, VerboseEncoder *e ) { EMIT( [NSString
stringWithFormat:@"The number is:%@", n] ); }

Try adding the VerboseEncoder encoder to any of the two lengthy
solution described earlier.
- Singletons
Method that dispatch based on the identity of the arguments.

Say you have a specific object that you want to encode differently.
You can do:

Encode( singleton gMyObject, TextEncoder *e ) { EMIT( @"Special" ); }

This means the gMyObject will be treated differently when encoded as
text. You don't have to make gMyObject member of a special class to
get this effect. It is usefull when you have classes whith
distinguished instances (say different kind of NULL values, or the
different NANs). Of course, this is only usable in a language that is
not too flaky with object equality.



I didn't intend to mean that ObjC need such functionalities, only
that those are important dynamic properties too (a few things easy to
express with multiple dispatch or singletons are next to impossible
to do without)

Cheers,

--fred
Michael Pelz Sherman
2000-02-03 18:05:29 UTC
Permalink
Post by J. Shan Bell
Post by Anders Pytte
JavaBeans is not an attempt to gain the dynamism of SmallTalk
(i.e. ObjC). It originates not from a strain of OO at all but
from the movement toward component engineering which - and you
may find this objectionable but it is true - is orthogonal to
OO. Indeed, there is absolutely no assumption that components
will be built using OO technologies. True, in the case of
JavaBeans, you must use a more or less OO language. But component
engineering as a field of research, a philosophy and even practice
makes no such assumption. Look at IDL, for example (Interface
Design Language). Components do not generally inherit anything,
nor are they designed for sub-classing. Few of the OO concepts
readily translate to component engineering (specifically, the
concept of modularity predates OO).
I really liked this take of component engineering. I was never really
comfortable with the tight coupling between objects and components and
this makes much more sense to me.
I'm afraid I'm with Marcel on this one. The distinction between objects and components is
completely bogus. Objects, when properly designed, do everything "components" do and much more.
I'm increasingly convinced that the whole component engineering "movement" was dreamed up by
marketing people at Microsoft in order to sell people on COM. I've even seen COM advocates
actually try and argue that the lack of inheritance in the component model is a *good* thing. What
utter nonesense!
Post by J. Shan Bell
I would add that I don't agree with the opinion of the original author
that Beans are a way to make up for dynamic inadequacies in Java.
If you're referring to me, that's certainly not what I meant. I would say Beans are an *attempt*
to make up for dynamic inadequacies in Java, but they do not succeed in doing so.
Post by J. Shan Bell
But
by having a strongly typed language, you loose the ability to implement
"component-like" designs. This seems like a serious downfall. The
pattern I have in mind is the target/action one that InterfaceBuilder
uses with Objective-C objects (true, not real components).
Right on! Target/action is one of the nice things we will lose when Apple tries to shoehorn the
AppKit into a pure Java implementation.

- mps






__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Anders Pytte
2000-02-03 20:48:18 UTC
Permalink
[snip]
Post by Michael Pelz Sherman
Post by J. Shan Bell
I really liked this take of component engineering. I was never really
comfortable with the tight coupling between objects and components and
this makes much more sense to me.
I'm afraid I'm with Marcel on this one. The distinction between
objects and components is
completely bogus. Objects, when properly designed, do everything
"components" do and much more.
I'm increasingly convinced that the whole component engineering
"movement" was dreamed up by
marketing people at Microsoft in order to sell people on COM. I've even seen COM advocates
actually try and argue that the lack of inheritance in the component
model is a *good* thing. What
utter nonesense!
Sigh...

A component in the sense of JavaBeans, and in the sense of the
recently advanced principles that I am aware of, is a code module
that can be deployed as part of a larger system, by the end user of
that system. Objects have traditionally been an engineering
construct; their use to create components is secondary. This
difference is so significant that many of the techniques associated
with OO have little or no relevance to component engineering.

Inheritance is not necessarily taken as a *bad* thing but as not
really applicable. But yes, breaking up large systems into components
does reduce the application of inheritance, and may reduce some of
the problems associated with inheritance that you seem to prefer to
ignore, problems that exist even in dynamic runtimes. There are two
"fragile base class" problems, one of which does not go away with a
dynamic runtime.

But reduced complexity and interdependency is only one of many
justifications for component engineering. If it were the only one,
there might be at least an argument that the distinction between OO
and component engineering was bogus. Shan Bell's take on this was a
good one. Whatever similarities you might claim between the two, a
tight coupling is not *derivative* of their definitions and could
only be considered an artificial limitation. Your conviction that
component engineering is something dreamed up by marketing people
Microsoft is just plain silly. I trust you did not mean me to take it
seriously.

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Ronald C.F. Antony
2000-02-04 01:59:44 UTC
Permalink
Post by Anders Pytte
Post by Michael Pelz Sherman
I'm afraid I'm with Marcel on this one. The distinction between
objects and components is completely bogus. Objects, when properly
designed, do everything "components" do and much more.
I agree with this. Why? See below...
Post by Anders Pytte
Post by Michael Pelz Sherman
I'm increasingly convinced that the whole component engineering
"movement" was dreamed up by marketing people at Microsoft in order to sell
people on COM. I've even seen COM advocates
actually try and argue that the lack of inheritance in the component
model is a *good* thing. What utter nonesense!
That may be not so far from the truth, but the problems started way before
COM. I read *years ago* some article that heralded component technology
as a better thing than OOP, and the components they were talking about
were these VisualBasic modules (VBX ?), that would essentially a
*PROGRAMMER* allow to create programs more quickly by dragging VBX
components from a pallette and connecting them somehow. (Gee, does
this component technology sounds somewhat like IB objects, or what?)
Post by Anders Pytte
Sigh...
A component in the sense of JavaBeans, and in the sense of the
recently advanced principles that I am aware of, is a code module
that can be deployed as part of a larger system, by the end user of
that system. Objects have traditionally been an engineering
construct; their use to create components is secondary.
That may be your way of seeing, it, and as such is valid.
But the way the term component technology is used in the marketplace,
it covers exactly the sort of low-level modules that IB palettes,
VBXs, etc, deal with, i.e. totally at the engineering level.

As far as component engineering as an end-user technology is
concerned, I have yet to see *any* component technology (other than
old-style plug-ins) that goes after the say e.g. typical iMac user.
Which means, component technology in your sense of the word is a
non-event, an academic concept, at best, not a workable solution.
And something that's not a workable solution I cannot accept as
being "better" than something that does exist and that does work.

Now as far as component engineering in the marketing sense of the
word is concerned... The entire point of OOP is that *the same*
principles can work from the bottom up in ever higher levels of abstraction.
This is very much akin how LISP machines worked: Lisp was essentially
the machine language, and would be able to do the lowest level
things, yet LISP's built in abstraction mechanisms let be possible to
use the same language to build some of the most complex software
systems known to man with relative ease, some of which were clearly
pieced together by non experts as far as computers go.
Any paradigm that's capable of layering ever higher levels of abstraction
within a framework that allows for enough dynamicism is "designed"
for component engineering.
Just because you can and do write low level code with an OOPL doesn't
mean that the same mechanisms weren't designed and intended to be used
for high-level "components".
The point here is consistency, and orthogonality, i.e. the rules of
the game should remain the same regardless if it's high-level or
low-level abstraction, if it's local or distributed execution, etc.

To make the point: years ago I wrote IB pallettes that essentially
(ab)used IB as an expert system construction system. You could pull
entire rule blocks off a pallette and wire them up, and as long as
you consider a spreadsheet an enduser application and not a
programming tool, this was certainly an enduser tool.

The point is, it can be done, it has been done and it will be done, and
even more importantly: OOP was designed to make it happen. But each system
starts with small building blocks. To just look at these and say there
is a difference between OOP and component engineering is, from my point
of view, like saying OOP is "just a lot of trees" and "no forest".
Just because component engineering doesn't scale down well doesn't mean
OOP doesn't scale up well.

Regards,

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Michael Pelz Sherman
2000-02-03 21:30:54 UTC
Permalink
--- Anders Pytte <***@milkweed.com> wrote:

...[snip]...
...breaking up large systems into components
does reduce the application of inheritance, and may reduce some of
the problems associated with inheritance that you seem to prefer to
ignore...
I'm very well aware of these problems. Most of the time, they are due to the abuse of inheritance
Marcel mentioned. One has to be really careful to avoid creating dependencies between classes that
should not have them. But this is just good OO design and not an inherent "flaw" of OO.

I'm also very much in favor of "breaking up large systems into components". OO environments do not
prevent this at all. Good OO designers have always worked this way. Frameworks, Bundles, and now
Beans or "components" are just different ways of doing this, and they all fall under the
conceptual umbrella of OO. Components are not a departure from OO any more than Frameworks and
Bundles were.
Your conviction that
component engineering is something dreamed up by marketing people
Microsoft is just plain silly. I trust you did not mean me to take it
seriously.
No, of course not. It just seems awfully suspicious that the concept really started to take off as
an industry buzzword right around the same time that Micro$oft started pushing COM. Another
example of the tail wagging the dog, perhaps.

The thing that really gets me riled up is articles like the one I mentioned, where component
engineering is promoted as being not only different from but "better than" OO, and as a solution
to the problems of creating a good OO design. This kind of thinking leads to a de-emphasis of the
advantages of dynamic environments like ObjC/AppKit in favor of less dynamic ones, and an eventual
degradation of the tools we (engineers) are forced to work with.

- mps
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Anders Pytte
2000-02-03 22:10:02 UTC
Permalink
Post by Michael Pelz Sherman
...[snip]...
...breaking up large systems into components
does reduce the application of inheritance, and may reduce some of
the problems associated with inheritance that you seem to prefer to
ignore...
I'm very well aware of these problems. [snip]
I'm also very much in favor of "breaking up large systems into
components". [snip]
I have never argued that component engineering should replace OO.
People making wild claims, but why get distracted by nonsense?
Componenet engineering is not going to replace OO. Indeed, you cannot
write Java beans without using Java - at least not yet!

For heavens sake, friend: look at the context of this discussion. We
were discussing whether JavaBeans was reproducing the functionality
of PB/IB/ObjC. The original quote to which I responded, Patrick
Post by Michael Pelz Sherman
I'm not disagreeing with this, but it's a funny thing: I've spent a little
time recently learning about Java Beans. And the thing that kept striking
me was how much the whole shebang felt like a way to shoehorn
Objective-C/Interface Builder runtime functionality onto Java.
I just pointed out that JavaBeans owe their origins not to ObjC nor
any particular OO, but to a distinct tradition of component
engineering. Essentially, the noted functionality of JavaBeans
addresses a different set of problems than PB/IB/ObjC: deployment of
modules by end users, rather than design of systems by engineers.
They are not an attempt to gain the advantages that dynamism offers
to engineers, even if they may return some of that advantage - very
inelegantly, as Patrick remarked.

I am not disputing that OO and components are both ways to decrease
complexity, increase code reuse and so on. But to a great extent,
they are battling for different turfs, and we are not in an either or
situation.


Regards,

Anders.

----------------------------------------------------------------

Anders Pytte Milkweed Software
Cemetery Road voice: (802) 472-5142
Craftsbury VT 05826 email: ***@milkweed.com

----------------------------------------------------------------
Ronald C.F. Antony
2000-02-04 02:19:04 UTC
Permalink
...breaking up large systems into components
does reduce the application of inheritance, and may reduce some of
the problems associated with inheritance that you seem to prefer to
ignore...
I wouldn't know how or why components would reduce the application of
inheritance. Any good piece of software is as small as possible, and
that is achieved by putting as much of the code into reusable (shared)
libraries. If I write my component the first thing I'd do is load
up my entire system with all consistent Cocoa/YB/OS libraries I could
find (AppKit, FoundationKit, ixKit (I wish), EOF, MiscKit, MPWFoundation,
Omni*Kit, etc.) *THEN* and only then will I even start thinking about
writing some software. Chances are, that my project just shrank by
at least 30-50% in size. Then I'll figure out what additional
functionality I need and can reuse, and I put that into object
categories and new classes, which you guessed it, *inherit* from a
whole slew of others in the shared libraries/frameworks, and I put
these into yet another framework. All these libraries and frameworks
are components; user installable software that is reconfigured by
the end user by additionally installing other software that makes
use of them. So then I write the glue code and one-shot code for
my component, which by then will most likely quite light-weight.
However, in the process I have heavily leveraged and used inheritance
and other OOP principles.

So for one I don't know what problems with OOP components could cure,
because the only problem with OOP I see are bad programmers that
don't grasp the concept of thinking in categories (I'm not talking
about ObjC Categories here, but about the general conceptual thing),
and even if there were a problem, then I wouldn't see how component
engineering would actually address it. By having lots of unreliable
spaghetti code in pseudo-independent modules? Given that alternative
I rather have "inheritance problems" in my components...

As for thinking in categories: some people get it, others don't.
Some people learn in school by compressing the knowledge by categorizing
it, others simply learn a million tidbits. For the same reasons
programmers have trouble with OOP, Lotus had trouble selling Agenda
and Improv. Sometimes it just requires a level of sophistication to
simplify things. I guess, sort of like it took a genius like
Einstein to grasp the simple concept of E=mc^2 ...
Funny how intelligence, simplicity and insight correlate...

Regards,

Ronald
==============================================================================
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | ***@cubiculum.com | NeXT-mail welcome
Lawson English
2000-02-03 22:42:26 UTC
Permalink
Post by Scott Anguish
Post by Ronald C.F. Antony
Post by Craig E Rasmussen
I'm assuming you find it useful because you can add methods to an
existing class. Why not just subclass? Oh, I suppose you want
users of that class to get the new behavior without recompiling
the entire framework. Am I thinking along the right lines?
Think of plug-ins. You can have a plug-in define categories on
classes in the existing, precompiled application.
I'd bet that e.g. some of the Mail.app add-ons like colorizer, etc.
have used categories to achieve their purpose, but I don't know
for sure.
I can't speak for Colorizer specifically.. but I can for the
SWSignature bundle (whose name is rather misleading at this
point)... it relies heavily on categories to get the access it does.
categories don't replace the need for a proper API though.
Is there an OD-like solution yet? I recall that you were talking about one
some time ago.

By "OD-like," I mean the ability to drag'n'drop or otherwise give end-users
the ability to include arbitrary visual content in an existing document and
print it out.*




*That was one of the drawbacks of OD originally: it didn't provide a
facility for coordinating color separations and other high-end DTP
capabilities, but was sorta a desktop equivalent of a real-time web-page
creation OS-level facility that wasn't suitable for professional DTP use
because it didn't allow for arbitrary DTP graphics issues to be handled at
the OD level.

-------------------------------------------------------------------------
Lawson English. Squeak, snore, etc.
Check out <http://www.squeak.org>
-------------------------------------------------------------------------
Scott Anguish
2000-02-04 02:04:17 UTC
Permalink
Post by Lawson English
Post by Scott Anguish
I can't speak for Colorizer specifically.. but I can for the
SWSignature bundle (whose name is rather misleading at this
point)... it relies heavily on categories to get the access it does.
categories don't replace the need for a proper API though.
Is there an OD-like solution yet? I recall that you were talking about one
some time ago.
No.. and frankly, who cares?

OD was a user oriented technology that never attracted users. It has
virtually NO relevance to the topic at hand either (but hey.. its no
surprise)... I can't see in any way shape or form where OD could even
remotely be related to the topic at hand (extending functionality for an
application programmatically). This doesn't have any relevance to
container style technology.

I'd actually like to give Maury a virtual slap (really funny for those
who actually know me BTW) for having inadvertantly opened the door for
you.
Post by Lawson English
By "OD-like," I mean the ability to drag'n'drop or otherwise give end-users
the ability to include arbitrary visual content in an existing document and
print it out.*
This isn't OD-like.. not at all.. but is covered off nicely by the
existence of PDF as a standard interaction means.

hell.. the basic PDFCompositor app could be used as a pasteup-board..
Michael Pelz Sherman
2000-02-03 22:35:55 UTC
Permalink
--- Anders Pytte <***@milkweed.com> wrote:
...
Post by Anders Pytte
For heavens sake, friend: look at the context of this discussion. We
were discussing whether JavaBeans was reproducing the functionality
of PB/IB/ObjC..
[snip]

Touche. This thread has certainly gotten far from the original context, as they often do, but it's
taken us into some interesting territory, at least for me. In spite of your attempts to convince
me otherwise, I do still think of components (and JavaBeans in particular) as just special kinds
of highly-decoupled Objects, which may be inspected visually in an editor (like the inspector in
IB). The similarity between JavaBeans and palettized AppKit objects is hard to dispute, even if
the JavaBeans creators didn't literally "steal" the idea from AppKit.

Finally, I'd like to see an example of JavaBeans being used by end users to plug & play with
different components in a shipping product. Most of the Bean examples I've seen are definitely
intended for "design of systems by engineers" rather than "deployment of modules by end users".
Not saying it can't be done, I'd just like to see an example.

Thanks for an interesting discussion,

- mps



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Continue reading on narkive:
Loading...