Home > Archive > Objective C > March 2005 > gcc and Foundation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
gcc and Foundation
|
|
| dieymir 2005-03-16, 4:06 pm |
| I'm trying to learn objc using Linux, gcc and gnustep-base as my
Foundation kit.
Compile with gnustep-base is really annoying, so I wonder if there is
any way to configure all this so I can simply use gcc -lobjc
-lgnustep-base (installing the headers and library in standard
locations) to compile objc sources.
Does anybody know why gcc doesn't come with a Foundation kit ??
GNU C++ and Java compilers come with implementations of the STL and
Java API, Why not objc.
Why doesn't use gcc the GNUStep base library as Foundation, Are there
license problems ??
Maybe there is a project to use gnustep-base as Foundation for gcc, I
don't know, but I'm really surprised that nobody had have the idea.
Thanks for your help.
| |
| Michael Ash 2005-03-16, 4:06 pm |
| dieymir <dieymir@yahoo.es> wrote:
> I'm trying to learn objc using Linux, gcc and gnustep-base as my
> Foundation kit.
>
> Compile with gnustep-base is really annoying, so I wonder if there is
> any way to configure all this so I can simply use gcc -lobjc
> -lgnustep-base (installing the headers and library in standard
> locations) to compile objc sources.
Create a makefile, and put all the stupid junk inside it. That way all you
have to do is type 'make' and you're done. Computers are designed to
automate boring tasks; use it.
> Does anybody know why gcc doesn't come with a Foundation kit ??
> GNU C++ and Java compilers come with implementations of the STL and
> Java API, Why not objc.
STL stands for *Standard* Template Library. The Java API is part of its
standard. Objective-C has no standard. Foundation isn't even a de-facto
standard, since it's basically just a NeXT/Apple thing which various
people have cloned for other systems.
> Why doesn't use gcc the GNUStep base library as Foundation, Are there
> license problems ??
I wouldn't be surprised if GNUStep-base didn't work on all the platforms
where gcc supports Objective-C. Even if it did, it's an external library
and there's no significant reason to include it with the compiler.
| |
| dieymir 2005-03-16, 4:06 pm |
| >
>
> STL stands for *Standard* Template Library. The Java API is part of
its
> standard. Objective-C has no standard. Foundation isn't even a
de-facto
> standard, since it's basically just a NeXT/Apple thing which various
> people have cloned for other systems.
>
Maybe I didn't explain very well. This was only an example, mothern
object oriented computer languages come with an utility library,
developers consider this a must. I think that the STL library is
optional in C++ compilers and, of course, you can make a Java compiler
and not include the Java API with it (Java isn't standardized), but,
probably, you will think that it isn't an useful one. Imaging you are a
developer that is considering to make your new QT, Win32, GTK+,
console, ... app. you are thinking about the language to use, you have
heard about that oo extension to C (Objc) that it's said to be easier
than C++ to use, but the compiler doesn't seem to be very good, there
isn't even an utility library (Foundation kit) to help you with all
that common programming task... You see include a Foundation kit (I'm
not speaking about App Kit) with gnu Objc compiler will help a lot to
increase language popularity.
In fact, there is a project named libFoundation that has as one of its
long term aims to be integrated in gcc, but, unfortunately, it seems to
have been abandoned.
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <1109409015.923493@nfs-db1.segnet.com>,
Michael Ash <mike@mikeash.com> wrote:
>dieymir <dieymir@yahoo.es> wrote:
>
>Create a makefile, and put all the stupid junk inside it. That way all you
>have to do is type 'make' and you're done. Computers are designed to
>automate boring tasks; use it.
The gnustep-make package may also include helpful things. In general, I'd
suggest installing all of GNUStep, because that also allows you to use
things like Project Center to manage your project and do the Makefile
management for you.
>
>STL stands for *Standard* Template Library. The Java API is part of its
>standard. Objective-C has no standard. Foundation isn't even a de-facto
>standard, since it's basically just a NeXT/Apple thing which various
>people have cloned for other systems.
I'll disagree slightly here: Foundation certainly is a de-facto standard.
It is not just 'people cloning a NeXT/Apple thing', but there is the
actual OpenStep specification which defines Foundation. And indeed,
Foundation - in one of its different implementations, of which there are
at least three in current development (Apple's Cocoa Foundation, GNUstep's
gnustep-base and OpenDarwin's libFoundation) - is the most widely used
basic class library with Objective-C.
>
>I wouldn't be surprised if GNUStep-base didn't work on all the platforms
>where gcc supports Objective-C. Even if it did, it's an external library
>and there's no significant reason to include it with the compiler.
There is an argument for having a reasonable set of basic classes - a
Foundation framework, if you will - available along with a compiler,
because it allows any user of the compiler to immediately start building
not only on the language itself, but on that reasonable base of existing
classes. And such things as collections of some kind, and other
fundamental operations, are probably going to be needed by any programmer,
and fairly soon, too. So I'd say that it makes sense to bundle a
fundamental library (of classes, functions, datatypes, etc) with an
interpreter or compiler for any language, because it lets people get off
to a flying start.
Best wishes,
// Christian Brunschen
| |
| Michael Ash 2005-03-16, 4:06 pm |
| Christian Brunschen <cb@df.lth.se> wrote:
>
>
> I'll disagree slightly here: Foundation certainly is a de-facto standard.
> It is not just 'people cloning a NeXT/Apple thing', but there is the
> actual OpenStep specification which defines Foundation. And indeed,
> Foundation - in one of its different implementations, of which there are
> at least three in current development (Apple's Cocoa Foundation, GNUstep's
> gnustep-base and OpenDarwin's libFoundation) - is the most widely used
> basic class library with Objective-C.
Is it the most widely used base class outside of Apple-land, though? Apple
doesn't really count, since they have their own gcc branch and their own
distribution thereof. They certainly count big-time in the world of
Objective-C, but not quite so much in the world of gcc Objective-C.
Of course, I would be completely unshocked if your claim was the case even
for the set of Objective-C minus Apple.
>
> There is an argument for having a reasonable set of basic classes - a
> Foundation framework, if you will - available along with a compiler,
> because it allows any user of the compiler to immediately start building
> not only on the language itself, but on that reasonable base of existing
> classes. And such things as collections of some kind, and other
> fundamental operations, are probably going to be needed by any programmer,
> and fairly soon, too. So I'd say that it makes sense to bundle a
> fundamental library (of classes, functions, datatypes, etc) with an
> interpreter or compiler for any language, because it lets people get off
> to a flying start.
You make a good point, and I'm inclined to agree. I think this will run
into a couple of problems. One problem is that there's a bit of a
chicken-and-egg problem going on. Namely, one can easily say that there is
no class library that comes with the compiler and everything seems fine,
so it's obviously not a problem. A larger problem is that the gcc ObjC
community seems somewhat antagonistic with Apple (although I may be
mistaken, and I hope so), and this could hamper the inclusion of any class
library which is seen to be from Apple in some way.
Thinking about it some more, it would be nice if gcc came with a
Foundation clone, but it doesn't seem likely to happen soon.
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <1109451971.578372@nfs-db1.segnet.com>,
Michael Ash <mike@mikeash.com> wrote:
>Christian Brunschen <cb@df.lth.se> wrote:
>
>Is it the most widely used base class outside of Apple-land, though?
Considering that the vast majority of Objective-C use is done in the
context of Apple's Mac OS X, its Cocoa and related class libraries, or its
related implementations (such as GNUStep), discounting 'Apple-land' seems
an odd thing to do. After all, I'm not just talking about Apple themselves
using Objective-C, but also about all the non-Apple, third-party
developers writing Cocoa-based frmeworks and applications. Also, since it
could be argued that anything Apple-related is essentially part of
Apple-land, including GNUStep et al, saying 'outside Apple-land' would
essentially be outlining a space that excluded any OpenStep-related use by
definition - so of course, Foundation would not be used in a space
that it's been explicitly excluded from ...
>Apple
>doesn't really count, since they have their own gcc branch and their own
>distribution thereof. They certainly count big-time in the world of
>Objective-C, but not quite so much in the world of gcc Objective-C.
Unless I am misinformed (which may of course be the case, and in which
case I'd love to be corrected), the main driving forces behind the
Objective-C compiler in GCC are Apple and GNUstep. Apple have their own
gcc branch in which they do their development, but they work diligently on
getting their changes included in mainline gcc; GNUstep are working hard
on keeping the mainline gcc Objective-C support at a high quality so that
GNUstep can compile and run well, and across as many platforms as
possible.
In other words, the two main forces driving Objective-C in GCC are both
intimatly connected to the Foundation framewor, each with their own
implementation thereof.
Also, Objective-C is not limited to GCC. It's probably the most widely
used Objective-C compiler, but there are at least two other currently
available compilers that support the current Objective-C language:
Metrowerks' CodeWarrior
<http://www.metrowerks.com/MW/Develo...sional/Mac9.htm>
IBM's XL C
<http://www-306.ibm.com/software/awd.../xlcpp-mac.html>
Both of these are for the Mac OS X target platform, so I expect they'll
both be used mainly with Mac OS X's Cocoa frameworks. So actually trying
to look just 'outside Apple-land' would exclude from the discussion more
than just Apple's own gcc branch, but also two totally separate compilers,
which I think just goes to show that one simply cannot do that.
>Of course, I would be completely unshocked if your claim was the case even
>for the set of Objective-C minus Apple.
If you google for 'Objective-C', you'll find references to all sorts of
things - most of them relating in some way or another to NeXTStep,
OpenStep, Cocoa, GNUStep. The main other result that pops up is Swarm. As
far as I can tell, Swarm seems to be the main system that uses Objective-C
outside the Cocoa/GNUStep world. It has its own class library which is
unrelated to anything from NeXT/Apple, and to anything Stepstone for that
matter. I have never taken more than a cursory glance at Swarm, though, so
I cannot say much about it. It looks quite interesting, though.
>
>You make a good point, and I'm inclined to agree.
Thank you :)
>I think this will run
>into a couple of problems. One problem is that there's a bit of a
>chicken-and-egg problem going on. Namely, one can easily say that there is
>no class library that comes with the compiler and everything seems fine,
>so it's obviously not a problem.
Well, yes and no; I think that most people who start developing with
Objective-C using GCC will get themselves an implementation of Foundation,
probably gnustep-base, which is easy to find, so in that sense it's
not a problem - the class library is sufficiently easily available that
the fact that it isn't included with th ecompiler itself is not much of an
issue. But those who just have gcc installed on their system and are
trying to experiment a little, but who don't know about GNUstep etc, are a
bit left out in the cold without a good foundation to stand on.
>A larger problem is that the gcc ObjC
>community seems somewhat antagonistic with Apple (although I may be
>mistaken, and I hope so), and this could hamper the inclusion of any class
>library which is seen to be from Apple in some way.
I know nothing of any such antagonism, but I suspect it may be overstated;
look, for instance, at the exchange on the gcc mailing list starting at
<http://gcc.gnu.org/ml/gcc/2005-01/msg01604.html> . Things seem to be
going fairly amicably.
But regardless of that, if the class library came from an existing GNU
project - such as GNUStep - I don't see what the problem would be.
>Thinking about it some more, it would be nice if gcc came with a
>Foundation clone, but it doesn't seem likely to happen soon.
Oh, I don't think so either. And I don't really think it's a great issue -
after all, gnustep-base is easy enough to download and install, 'make' is
your friend, etc.
Best wishes,
// Christian Brunschen
| |
| Tilo Prütz 2005-03-16, 4:06 pm |
| dieymir wrote:
> In fact, there is a project named libFoundation that has as one of its
> long term aims to be integrated in gcc, but, unfortunately, it seems to
> have been abandoned.
It's not abandoned. It is still used by at least two companies for their
commercial products. One of them is still "maintaining" it (as a side task of
one developer AFAIK).
The quality of this foundation is poor (IMHO). But the gcc Objective-C code is
not better so probably they would fit together :). When I reported a bug in gcc
which cause a crash when you try to get method descriptions for inherited
methods from protocols which inherit from other protocols, I had to learn that
the gcc Objective-C maintainers obviously do not understand what their code is
for. Maybe they change too frequently or something else, I don't know.
But I lost my faith in gcc.
greetz
>tilo
| |
| David Stes 2005-03-16, 4:06 pm |
| dieymir <dieymir@yahoo.es> wrote:
>
> Does anybody know why gcc doesn't come with a Foundation kit ??
> GNU C++ and Java compilers come with implementations of the STL and
> Java API, Why not objc.
I think historically Objective-C has/had a lead over both C++ and Java.
The emphasis in Objective-C is precisely on the basic building blocks,
classes like Object, Set, OrderedCollection etc.
Unfortunately many efforts are lost by internal debates and "running
in circles" where people want to replace the basic foundation kit with
new versions of foundation kits etc. so that in the end there are,
alas, incompatible foundation kits etc.
There's not really a good technical reason for this.
| |
| David Stes 2005-03-16, 4:06 pm |
| Christian Brunschen <cb@df.lth.se> wrote:
>
> discounting 'Apple-land' seems an odd thing to do.
Why so ? Apple has not a lot of Objective-C know-how and has often stated
that they would prefer to migrate to Java.
Apple is completely irrelevant to Objective-C.
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <70oXd.33011$Gv2.3157082@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>dieymir <dieymir@yahoo.es> wrote:
>
>I think historically Objective-C has/had a lead over both C++ and Java.
Alas, this is wrong. The Objective-C language has never had a 'standard
class library'. Certainly, most compiler providers have offered some
classes to help developers get started, and Stepstone, for instance,
offered several class libraries to add to their compiler; but the
Objective-C language was designed to allow cevelopers to write their own
class hierachies, starting with root class and working down.
C++ initially also had no standard classes; it does now. Java has always
had a standard set of classes, though this set has varied over time - see
more below.
>The emphasis in Objective-C is precisely on the basic building blocks,
>classes like Object, Set, OrderedCollection etc.
Actually, no - the focus in Objective-C was initially on the language, on
the ability to _write_ reusable classes (in Stepstone's parlance,
'Software ICs'). It never mandated or assumed any 'standard class
library'.
>Unfortunately many efforts are lost by internal debates and "running
>in circles" where people want to replace the basic foundation kit with
>new versions of foundation kits etc. so that in the end there are,
>alas, incompatible foundation kits etc.
There have always been incompatible root classes, etc, simply because
Objective-C has never had one single mandated root class. The first
edition of Brad Cox's book on Objective-C described a different set of
classes than Stepstone sold to commercial customers in their ICPak 101,
for instance, so anyone who had an Objective-C compiler and followed the
book would end up with a different class hierarchy than ICPak101.
Of course, if one looks at Cocoa's Foudation Kit, one sees that it remains
fundamentally backwards compatible with the OpenStep Foundation Kit as
defined in 1994. Thus, OpenStep/Cocoa's Foundation Kit has offered a
foundation that has been functional and stable for over a decade - a
decade in which NeXT and Apple have promoted the use of Objective-C and
made it more widely used than ever before; and most of that use is done
using OpenStep/Cocoa's Foundation Kit.
>There's not really a good technical reason for this.
Actually, there are a number of technical reasons to prefer, say, Cocoa's
Foundation Kit over Stepstone's ICPak101 classes - things like having a
string class that isn't just a thin veneer on top of C's char *, a memory
management scheme that reduces the workload on developers, consistent
naming conventions that lead to readable and maintainable code, etc.
There's also the fact that simply *having* a standard class library is not
a sufficient thing; that class library has to be good enough for people to
use and feel comfortable with. Anyone who has been following Java will
have noticed that Java's fundamental APIs have shown an irritating _lack_
of stability, with different - and incompatible - classes and interfaces
for things like collections popping up every now and then.
Again, in contrast, OpenStep/Cocoa's Foundation Kit has been stable and
compatible for over a decade, and developers appear to be quite
comfortable with it.
Best wishes,
// Christian Brunschen
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <X3oXd.33015$Fb7.3078265@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>Christian Brunschen <cb@df.lth.se> wrote:
>
>Why so ?
Well, I could reiterate the reasons that I listed in the post that David
Stes snipped. But it all really comes down to the fact that Apple are the
main driving force behind Objective-C today, and the second most powerful
driving force is GNUStep - which is another implementation of OpenStep's
Foundation and AppKit, and building further on it.
>Apple has not a lot of Objective-C know-how
Obviously, David Stes has deep access to Apple's development teams, the
CVs of individual team members, and so forth. Or could it simply be the
case that he simply refuses to accept that there might be Objective-C
expertise that not only exists at a company he dislikes, but also that
disagrees with him?
>and has often stated
>that they would prefer to migrate to Java.
David Stes makes up his own facts when the real world fails to support
him. Apple have not in fact 'often stated that they would prefer to
migrate to Java', and I bet that David Stes will either refuse or simply
fail to offer any support for his allegation.
>Apple is completely irrelevant to Objective-C.
That's an interesting statement to make about the company that owns the
Objective-C trademark, that bases the development environment both for
third-party developers and for in-house development on their main platform
on Objective-C, maintains their own compiler - and where two other
compiler developers (IBM and Metrowerks) have added Objective-C support to
their compilers precisely in order to support Apple's OS platform.
It appears as if reality simply refuses to mold itself to David Stes'
desires. What a pity.
Best wishes,
// Christian Brunschen
| |
| David Stes 2005-03-16, 4:06 pm |
| Christian Brunschen <cb@df.lth.se> wrote:
>
> Alas, this is wrong. The Objective-C language has never had a 'standard
> class library'.
Well, Java is not much of an issue, here since it is much younger.
But wrt. to C++, it is clear that the big difference is that Objective-C
comes with standard classes like Object, Set, OrderedCollection and runtime
features like filing etc. So as opposed to syntax, the emphasis in O-C is
on the basic classes, where the selectors of these classes are the keywords
of the Objective-C language.
Now, some people without proper understanding of Objective-C, will remove
the standard class library, then claim that there is no standard library,
then try to make Objective-C look like C++. That is what Apple does.
Apple has C++ developers, but no serious Objective-C developers, no people
with understanding of Objective-C.
| |
| Sherm Pendley 2005-03-16, 4:06 pm |
| David Stes wrote:
> But wrt. to C++, it is clear that the big difference is that Objective-C
> comes with standard classes like Object, Set, OrderedCollection and
An interesting assertion. Please provide us with a reference to a document
issued by ISO, ANSI, IEEE, or some other widely recognized standards body,
that defines a standard library for Objective-C.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <z8JXd.33781$7V7.3359833@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>Christian Brunschen <cb@df.lth.se> wrote:
>
>Well, Java is not much of an issue, here since it is much younger.
Java matters because it has been able to learn from the mistakes of other
languages before it. It hasn't learned all the lessons, perhaps, but it
has learned some of them, for instance the one at the heart of this
discussion.
>But wrt. to C++, it is clear that the big difference is that Objective-C
>comes with standard classes like Object, Set, OrderedCollection and runtime
>features like filing etc. So as opposed to syntax, the emphasis in O-C is
>on the basic classes, where the selectors of these classes are the keywords
>of the Objective-C language.
Just because David Stes keeps repeating it, doesn't make it any more true:
his claims remain as inaccurate as ever. There never was a 'standard
Objective-C class library'. When Stepstone were still operating, their
Objective-C compiler was one product, and their ICPak101 and ICPak201
class libraries where different, separate products. The classes that David
Stes refers to - Object, Set, OrderedCollection etc - were part of
ICPak101, not of the Objective-C compiler.
Stepstone did bundle ICPak101 with their compiler, but it was still a
separate product, separate from the compiler. And since the Objective-C
language allows developers to write their own root classes, developers
were free to cheerfully ignore ICPak101 if they so decided, and use only
the compiler without being restricted to building their classes on the
foundation of ICPak101.
These days, C++ _does_ have a standard class library - actually, a
standard template library. Java has always had a standard class library,
which is one of its strengths as well as one of its weaknesses; the same
holds true for Python.
Objective-C, however, still keeps language and classes separate - which
has its own strengths and weaknesses. In the presence of good class
libraries for those developers who want to use them (such as Cocoa or
GNUstep), developers still have a nice foundation to stand on - but where
a language such as Java limits what developers can do in that all classes
must inherit from the java.lang.Object root class, Objective-C allows
developers to disregard any existing class hierarchy and write their own
starting at the root class or classes, if they so desire.
>Now, some people without proper understanding of Objective-C, will remove
>the standard class library, then claim that there is no standard library,
>then try to make Objective-C look like C++. That is what Apple does.
>Apple has C++ developers, but no serious Objective-C developers, no people
>with understanding of Objective-C.
David Stes' description is rather at odds with reality. One only needs to
look at the facts to see that there really wasn't a prescribed standard
class library, no matter how much he protests to the contrary. Apple are
not trying to turn Objective-C into C++.
Quite the contrary: NeXT/Apple have been continuously evolving the
Objective-C language - adding such things as Categories, Protocols, and
recently, exceptions. NeXT/Apple have in fact developed what has become
the most widely use Objective-C foundation class library -
OpenStep/Cocoa's Foundation Kit - which has essentially become the
de-facto standard class library for Objective-C; but without limiting the
language in the way a prescribed standard class library would. Apple's Mac
OS X is the premier platform for serious Objective-C development -
followed by GNUstep running on Linux, which again follows the
OpenStep/Cocoa Foundation Kit.
And again, David Stes trots out his claims of 'Apple not having any
Objective-C understanding' - with the implication that he, of course,
does, and that anyone who agreew with Apple rather than him must obviously
also lack this understanding. In essence, he is claiming to be the only
person who knows and understands Objective-C properly. Indeed, he has even
turned against employees of Stepstone (the company that Brad Cox, the
inventor of Objective-C, formed to market the Objective-C compiler and the
ICPak class libraries), cleaiming that their first-hand knowledge of
events at Stepstone must be false because it contradictes David Stes'
opinions.
Alas, David Stes' claims about Objective-C, NeXT, Apple, or really almsot
anything, cannot be taken at face value.
Best wishes,
// Christian Brunschen
| |
| Stefan Arentz 2005-03-16, 4:06 pm |
| David Stes <stes@dD5E02B62.access.telenet.be> writes:
....
> That is what Apple does.
> Apple has C++ developers, but no serious Objective-C developers, no people
> with understanding of Objective-C.
Time for your medication David!
S.
| |
| David Stes 2005-03-16, 4:06 pm |
| Christian Brunschen <cb@df.lth.se> wrote:
>
> developers were free to cheerfully ignore ICPak101 if they so decided,
> and use only
> the compiler without being restricted to building their classes on the
> foundation of ICPak101.
>
> These days, C++ _does_ have a standard class library - actually, a
> standard template library.
C++ developers are also free to cheerfully ignore the STL.
Just as C developers are free to cheerfully ignore stdlib.
The point is that ignoring the standard Objective-C library, ignoring
classes like Set, OrdCltn, SortCltn etc., the classes that come with
Objective-C since 1983, and that are the core of the language system,
is not a *smart* thing to do.
You can ignore cheerfully all you like, and cheerfully ignore using
anything Objective-C offers, but it is a rather stupid thing to do.
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <HnJYd.36210$Dz6.3472440@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>Christian Brunschen <cb@df.lth.se> wrote:
>
>C++ developers are also free to cheerfully ignore the STL.
>Just as C developers are free to cheerfully ignore stdlib.
There are a few significant differences though:
* C has an official, recognised standard by an official, recognized
standards body
- the current C standard includes a standard type and function library
* C++ has an official, recognised standard by an official, recognized
standards body
- the current C++ standard includes the standard template library
* Objective-C does _not_ have a standard from any recognized standards
body
- there isn't even an Objective-C standard in progress
- nor is there, nor has there been, an Objective-C standard class library
>The point is that ignoring the standard Objective-C library,
There is no 'standard Objective-C library'. The closest thing would be
trying to find a de-facto standard, by looking at what developers use. And
by those criteria, OpenStep/Cocoa/GNUStep's Foundation Kit 'wins'.
>ignoring classes like Set, OrdCltn, SortCltn etc., the classes that come with
>Objective-C since 1983, and that are the core of the language system,
>is not a *smart* thing to do.
Setting aside a an inferior set of classes in favor of a superior set,
strikes me as a very smart thing to do.
>You can ignore cheerfully all you like, and cheerfully ignore using
>anything Objective-C offers, but it is a rather stupid thing to do.
Developers who develop for Cocoa or GNUStep or Swarm are cheerfully
_using_ what Objective-C offers, but ignoring classes that they have no
desire to use because they have alternatives that suit them better. And
the fact that they are indeed free to use, or even develop, their own
class library starting from any root class(es) they need, _is_ one of the
things that Objective-C offers.
I'd say that choosing the right tool for the right job is rather the
opposite of being stupid.
Best wishes,
// Christian Brunschen
| |
| David Stes 2005-03-16, 4:06 pm |
| Christian Brunschen <cb@df.lth.se> wrote:
>
> Setting aside a an inferior set of classes in favor of a superior set,
> strikes me as a very smart thing to do.
I'm not impressed by you calling the standard set of objects of
Objective-C "inferior".
But the question was : "is there a standard set of objects like STL in C++" ?
Yes ... there has always been one. So historically, this is an odd question,
since Objective-C was (and still is, in my opinion) ahead of C++ here.
| |
| Stefan Arentz 2005-03-16, 4:06 pm |
| David Stes <stes@dD5E02B62.access.telenet.be> writes:
> Christian Brunschen <cb@df.lth.se> wrote:
>
> C++ developers are also free to cheerfully ignore the STL.
> Just as C developers are free to cheerfully ignore stdlib.
>
> The point is that ignoring the standard Objective-C library, ignoring
> classes like Set, OrdCltn, SortCltn etc., the classes that come with
> Objective-C since 1983, and that are the core of the language system,
> is not a *smart* thing to do.
Consider this:
ObjectPak:
Integer, BigInt, OrdCltn, Set, String, SortCltn
(taken from the docs on your site)
Cocoa:
NSAppleEventDescriptor, NSMutableURLRequest, NSAppleEventManager,
NSNameSpecifier, NSAppleScript, NSNetService, NSArchiver, NSNetServiceBrowser,
NSArray, NSNotification, NSAssertionHandler, NSNotificationCenter,
NSAttributedString, NSNotificationQueue, NSAutoreleasePool, NSNull, NSBundle,
NSNumber, NSCachedURLResponse, NSNumberFormatter, NSCalendar, NSObject,
NSCalendarDate, NSOutputStream, NSCharacterSet, NSPipe, NSClassDescription,
NSPort, NSCloneCommand, NSPortCoder, NSCloseCommand, NSPortMessage, NSCoder,
NSPortNameServer, NSComparisonPredicate, NSPositionalSpecifier,
NSCompoundPredicate, NSPredicate, NSConditionLock, NSProcessInfo,
NSConnection, NSPropertyListSerialization, NSCountCommand, NSPropertySpecifier,
NSCountedSet, NSProtocolChecker, NSCreateCommand, NSProxy, NSData,
NSQuitCommand, NSDate, NSRandomSpecifier, NSDateComponents, NSRangeSpecifier,
NSDateFormatter, NSRecursiveLock, NSDecimalNumber, NSRelativeSpecifier,
NSDecimalNumberHandler, NSRunLoop, NSDeleteCommand, NSScanner, NSDeserializer,
NSScriptClassDescription, NSDictionary, NSScriptCoercionHandler,
NSDirectoryEnumerator, NSScriptCommand, NSDistantObject,
NSScriptCommandDescription, NSDistantObjectRequest, NSScriptExecutionContext,
NSDistributedLock, NSScriptObjectSpecifier, NSDistributedNotificationCenter,
NSScriptSuiteRegistry, NSEnumerator, NSScriptWhoseTest, NSError, NSSerializer,
NSException, NSSet, NSExistsCommand, NSSetCommand, NSExpression, NSSocketPort,
NSFileHandle, NSSocketPortNameServer, NSFileManager, NSSortDescriptor,
NSFormatter, NSSpecifierTest, NSGetCommand, NSSpellServer, NSHost, NSStream,
NSHTTPCookie, NSString, NSHTTPCookieStorage, NSTask, NSHTTPURLResponse,
NSThread, NSIndexPath, NSTimer, NSIndexSet, NSTimeZone, NSIndexSpecifier,
NSUnarchiver, NSInputStream, NSUndoManager, NSInvocation, NSUniqueIDSpecifier,
NSKeyedArchiver, NSURL, NSKeyedUnarchiver, NSURLAuthenticationChallenge,
NSLocale, NSURLCache, NSLock, NSURLConnection, NSLogicalTest, NSURLCredential,
NSMachBootstrapServer, NSURLCredentialStorage, NSMachPort, NSURLDownload,
NSMessagePort, NSURLHandle, NSMessagePortNameServer, NSURLProtectionSpace,
NSMetadataItem, NSURLProtocol, NSMetadataQuery, NSURLRequest,
NSMetadataQueryAttributeValueTuple, NSURLResponse, NSMetadataQueryResultGroup,
NSUserDefaults, NSMethodSignature, NSValue, NSMiddleSpecifier,
NSValueTransformer, NSMoveCommand, NSWhoseSpecifier, NSMutableArray,
NSXMLDocument, NSMutableAttributedString, NSXMLDTD, NSMutableCharacterSet,
NSXMLDTDNode, NSMutableData, NSXMLElement, NSMutableDictionary, NSXMLNode,
NSMutableIndexSet, NSXMLParser, NSMutableSet
And that is just Foundation.
ObjectPak is an insignificant and outdated class library that stopped being developed more than a decade ago.
S.
| |
|
| On Wed, 09 Mar 2005 22:37:19 +0000, Christian Brunschen wrote:
>
> These days, C++ _does_ have a standard class library - actually, a
> standard template library.
This statement could be a little misleading, if I may say so. There is a
little bit of history behind this:
In the mid-nineties, while a C++ standard was being considered, certain
members of a committee stated that they would not approve any standard
that did not include an extensive library. Alexander Stepanov from HP came
forward and presented his STL, which was based on work he had done in Ada.
Since there were no competing proposals, Stepanov and Lee's work were
accepted as a basis for the new C++ standard library. Other parts of the
library, such as strings and IOStreams, were adapted to be compatible with
the STL, and the STL itself was adapted, so that it would integrate with
the rest of the library.
So in the terms of today's standard C++, the name 'Standard Template
Library' is something of an anachronism.
I believe the point that needs to be made is that Objective-C has never
been standardised and therefore cannot have a standard library. I suppose
it could also be argued that Foundation and AppKit are the closest thing
that Objective-C has to a de-facto standard library, since they must be by
far the most commonly used. However, this is a very loose usage of the
word 'standard'.
In a nutshell: there is no such thing as standard Objective-C or a
standard Objective-C library. Unless the language makes massive gains in
popularity and breaks out of the Apple niche, which seems unlikely on the
surface, this situation will probably persist into the foreseeable future.
Alwyn
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <0TVYd.36586$Ix5.3429438@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>Christian Brunschen <cb@df.lth.se> wrote:
>
> I'm not impressed by you calling the standard set of objects of
>Objective-C "inferior".
Whether or not something is standard actually has no bearing on whether it
is good or bad. There are a number of standards which at least contain
elements that are not particularly good, from a number of standpoints.
My personal experience as an Objective-C developer has led me to the
conclusion that OpenStep's Foundation classes are indeed superior, at
least for my purposes, to the classes in Stepstone's ICPak101.
> But the question was : "is there a standard set of objects like STL in C++" ?
>
> Yes ... there has always been one.
No, there hasn't. Indeed, if there were, one might expect that Brad Cox &
Andrew Novobilski's book 'Object-Oriented Programming, an evolutionary
approach' (second edition) might mention such a thing. However, the
lead-in to Appendix A, 'Specification Sheets', which lists the
specification sheets for the small set of foundation classes described and
used in the book, says, on page 217:
<quote>
These eight Software-ICs are a subset of the eighteen Software-ICs that
are routinely delivered with each Objective-C compiler license [ ... ].
This subset was chosen to provide a representative sample of a typical
Software-IC library, large enough to demonstrate how such libraries can be
built and documented, yet smal enough to be manageable.
The Software-ICs described here are the same as those in the commercial
library. However, fewer classes are described here, and not to nearly the
same level of detail. [ ... ] Names of functions and selectors have been
modified for greater readability [ ... ]
</quote>
So even in their own book - both Brad Cox and Andrew Novobilski were with
the Stepstone Corporation - they don't refer to the ICPak101 library as
'the standard library', but as 'the commercial library'. Indeed, in the
preface to the book, on page ix, Brad Cox writes:
<quote>
The second group of changes are with respect to the classes discussed
throughout this book and detailed in the specification sheets in Appendix
A. in previous editions, these classes were specific to this book and not
the same as the classes in ICPak101. One sign of this change is the
replacement of the old ByteArray class with the newer String class
throughout this book.
</quote>
So the first edition of the book that would introduce developers to
Objective-C actually used a different set of classes than Stepstones
commercial library, ICPak101. If there _had_ been a standard, one would
have thought that the book and the ICPak101 library would have agreed on
their classes, but that apparently only became the case in the book's
second edition - in 1991. And indeed the book would have mentioned the
_existance_ of this standard - but the word 'standard' doesn't even appear
in the index, nor in any of the places where one would expect it in the
book, if there indeed was such a standard.
There is one simple, obvious reason for the lack of mention of any
standard: there isn't one (at least there wasn't one at the time the book
was written).
>So historically, this is an odd question,
>since Objective-C was (and still is, in my opinion) ahead of C++ here.
Objective-C has neither an official language standard, nor a standard
class library, nor has it ever had either. Repeatedly claiming otherwise
does not change these facts. The avid reader will note, of course, that
David Stes has not offered any support other than his own assertions.
The conclusion is clear: There is no Objective-C standard, nor is there an
Objective-C 'standard class library', repeated unsapported assertions to
the contrary notwithstanding.
Best wishes,
// Christian Brunschen
| |
| David Stes 2005-03-16, 4:06 pm |
| Alwyn <alwyn@blueyonder.co.uk> wrote:
>
> I believe the point that needs to be made is that Objective-C has never
> been standardised and therefore cannot have a standard library.
But this, of course, omits the fact that any Objective-C user, from very
early on, even back in 1984 or so, would get a standard library of objects
with his or her compiler ... contrary to the situation with C++.
The situation has worsened a bit over the years, since people have worked
to *uncouple* the standard library from Objective-C (so you could argue
that there is a regression in Objective-C on this issue, and progress in C++
on the same issue).
| |
|
| On Sun, 13 Mar 2005 20:37:22 +0000, David Stes wrote:
> Alwyn <alwyn@blueyonder.co.uk> wrote:
>
> But this, of course, omits the fact that any Objective-C user, from very
> early on, even back in 1984 or so, would get a standard library of objects
> with his or her compiler
We obviously have a different understanding of the word 'standard'. In my
sense, a standard has to be approved by a recognised standards body. A
floating-point arithmetic standard, for instance, is maintained by the
IEC; standard C++ is supported by ISO and C# by ECMA. No such institution
has ever given its seal of approval to a library to work with Objective-C.
> ... contrary to the situation with C++.
I'm not sure I agree with this either. Pre-standard C++ development
systems used to come with IOStreams for simple input and output, maybe a
co-routine library and, in the later stages, a string class as well in
addition to the whole of the standard C library. IOStreams were in any
case universal, but I imagine few people would have called them 'standard'.
> The situation has worsened a bit over the years, since people have
> worked to *uncouple* the standard library from Objective-C (so you could
> argue that there is a regression in Objective-C on this issue, and
> progress in C++ on the same issue).
There has been progress in C++, certainly, which has not been matched in
the world of Objective-C. Our only real disagreement (and it is
substantial) is in our use of the word 'standard'.
Alwyn
| |
| Christian Brunschen 2005-03-16, 4:06 pm |
| In article <6w1Zd.36983$Zk5.3342454@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>Alwyn <alwyn@blueyonder.co.uk> wrote:
>
>But this, of course, omits the fact that any Objective-C user, from very
>early on, even back in 1984 or so, would get a standard library of objects
>with his or her compiler
The user would get _a library_, but this was not a _standard_ library - it
was just another product from the same company (Stepstone). When other
companies started providing Objective-C compilers, they supplied
_different_ class libraries - NeXT being one such example. If ICPak101 had
truly been a 'standard', then Stepstone would surely have included it in
part and parcel of the Objective-C system that licensors of Objective-C
would deliver to their clients. However, they did not - which is clear
indication that Stepstone certainly did not consider ICPak101 to be 'the
standard class library'.
>... contrary to the situation with C++.
There were certainly classes that C++ compilers would include - iostreams,
for instance - which more or less paralleled the situation in Objective-C.
>The situation has worsened a bit over the years, since people have worked
>to *uncouple* the standard library from Objective-C (so you could argue
>that there is a regression in Objective-C on this issue, and progress in C++
>on the same issue).
Since there never was a coupling in the first place, there is nothing to
uncouple.
A problem is also David Stes' insistence that there is one standard class
library which may never be replaced - essentially saying that it is more
important to limit what developers can do by forcing them to adhere to an
outdated 'standard' (which never was a standard in the first place), even
in the face of newer, improved, more complete class libraries that solve
those developers' problems in better and more suitable ways.
Another way of characterizing the development in the Objective-C world is
in fact to recognize that the previous chaotic situation with no standard
class library, having been replaced with a language that has evolved to
gain some powerful and useful improvements (such as, most recently,
exceptions) _and_ a de-facto standard class library (Foundation) that is
both tried and tested, in constant development and refinement, and very
rich and expressive.
The world of Objective-C, and everything else, moves on forward.
Attempting to force developers to use an older class library simply
because it was, years ago, shipped with one of the compilers that were
commercially available, strikes me as misguided - as does calling people
'stupid' for preferring to use a more modern and complete class library
over an older one that also makes no use of more modern features of the
language itself.
Best wishes,
// Christian Brunschen
| |
| silverdr 2005-03-16, 4:06 pm |
| Stefan Arentz wrote:
[...]
>
>
> Consider this:
>
> ObjectPak:
>
> Integer, BigInt, OrdCltn, Set, String, SortCltn
>
> (taken from the docs on your site)
>
> Cocoa:
>
> NSAppleEventDescriptor, NSMutableURLRequest, NSAppleEventManager,
[... a NUMBER of classes' names snipped...]
> NSMutableIndexSet, NSXMLParser, NSMutableSet
>
> And that is just Foundation.
"The NUMBER of cockroaches on this planet is supposed to be an order of
magnitude bigger than the NUMBER of humans... "
"Quality is spelled almost the same as quantity, but not exactly... "
And a few more ;-)
| |
| David Stes 2005-03-19, 4:01 pm |
| Alwyn <alwyn@blueyonder.co.uk> wrote:
>
> We obviously have a different understanding of the word 'standard'. In my
> sense, a standard has to be approved by a recognised standards body.
You confuse the standard with your recognised standards body.
A standard exists before it is formalized;
For example, if I'm purchasing a new car, then I wonder what the "standard"
equipment is (whether it comes 'standard' with ESP, for example).
ESP is not recognized by a standards body as standard for cars, but I
can still say that it is standard for a certain car manufacturer.
Just as you can say, this car comes 'standard' with ESP, it is clear that
Objective-C has always come with a standard set of objects, things
like Object, Set, OrderedCollection etc. that are *included* with the
compiler. This is like Smalltalk, but unlike other systems, like C++,
which you get without standard classes. Objective-C is like Smalltalk
in this respect, and you could say that Smalltalk when it did not have
an approved recognized standards body, but it still had its standard classes
and its standard class hierarchy (and the Objective-C standard objects are
directly traceable back to the standard classes of Smalltalk-76).
| |
| Christian Brunschen 2005-03-19, 4:01 pm |
| In article <iiW_d.41167$M24.3548213@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>Alwyn <alwyn@blueyonder.co.uk> wrote:
>
>You confuse the standard with your recognised standards body.
Actually, no. he isn't  at all: He states above that he considers
that for something to be 'a standard' with no further qualifications, it
needs to be approved by a recognized standards body. There is absolutely
no confusion on his part.
>A standard exists before it is formalized;
>
>For example, if I'm purchasing a new car, then I wonder what the "standard"
>equipment is (whether it comes 'standard' with ESP, for example).
>
>ESP is not recognized by a standards body as standard for cars, but I
>can still say that it is standard for a certain car manufacturer.
The word 'standard' can be used in a few different ways, and can be
somewhat ambiguous. Perhaps a closer look will clear up the confusion a
bit.
There are different kinds of 'standards':
1) standards from a recognized, sometimes international, standards body
These standards are things like the Metric system, character sets
(ISO10646 etc), safety, electricity, building standards and so on.
Standards bodies in this area are ISO, ECMA, and also national standards
bodies like DIN, ANSI, and so on.
2) manufacturer standards
These are basically when a manufacturer decides to set a certain baseline
for a product or series of products, such as when Sun decide to define a
specific set of classes as the standard Java class library, or when a car
manufacturer starts shipping airbags on all cars as standard.
When a manufacturer is the sole, or authoritative, source for something,
then that manufacturer in effect can function as a sort of standards body
for that product/system, especially when trademarks are involved. For
instance, Sun are effectively the standards body for Java, because they
own the trademark.
Even lacking an authoritative standing, a specific manufacturer's standard
can also become a de-facto standard, forcing other manufacturers to follow
their lead because users come to expect the functionality or features hat
a specific manufacturer offers. For instance, the Microsoft Word '.doc'
file format has become a de-facto standard for word processing doument
interchange, because so many users of Word expect to be able to exchange
these documents, that other word processors essentially need to offer .doc
file compatibility to be competitive, even though Microsoft is not an
authoritative source of file formats as such.
3) de-facto standards
these standards are when a large community of users, customers, start to
want and even _expect_ a certain set of functionality, features, and
whatnot, and suppliers thus begin to supply the elements that their
customers expect - things like how automobiles these days offer similar
controls (steering wheel for directional control, gear shift stick on the
floor of the car for manual transmission, etc).
For instance, in Europe, manual gearshift with the stick on the floor of
the car between the driver and passenger seats, is the de-facto standard
for car transmissions; in the USA, if I understand correctly, the de-facto
standard is an automatic gearbox with a control by the steering wheel.
As shown, there can be different de-facto standards in different user
communities, and there can of course be exceptions as well - manual-shift
cars are sold in the US, and automatic-transmission ones in Europe.
Standards can, and do, evolve. Something that is a recognized standard may
be displaced in actual usage by a de-facto standard, simply by people
preferring to use something other than the defined standard and eventually
agreeing on that replacement - which might in turn become a recognized
standard in its own right. Or there can be an organized effort because of
percieved inadequacies in a standard, and a new one is developed to
replace the old one, such as when C99 replaced C89.
Of these types of standards, only the first kind (standards from a
recognized body) are really prescriptive; de-facto standards are probably
closely following on that, because when people expect something as part of
a de-facto standard, it may well be foolish to try to break people's
expectations. Vendor 'standards' fall somewhere to the side, because they
can appear very similar to recognized standards, and they can also be
de-facto standard, both in the absence of or contrary to recognized
standards.
There can also be different standards that co-exist at the same time; both
recognized standards, manufacturer standards, and de-facto standards,
though the point of a recognized standard is usually to supersede other,
manufacturer or de-facto, standards that may exist in the space covered by
the recognized standdard when it is defined/established. To that end, such
standards tend to get developed to be sufficiently versatile, flexible,
and cover as much ground as possible within the subject matter they
concern.
In other words, the only times when one can truly talk about '_the
standard_', are when there is one current and widely-used standard from a
recognized standards body - or a similarly current and widely used
authoritative manufacturer standard (i.e., a manufacturer stanard from the
authoritative manufacturer).
>Just as you can say, this car comes 'standard' with ESP, it is clear that
>Objective-C has always come with a standard set of objects, things
>like Object, Set, OrderedCollection etc. that are *included* with the
>compiler. This is like Smalltalk, but unlike other systems, like C++,
>which you get without standard classes.
Unfortunately, David Stes' statements above only match reality to a
certain extent, and his analogy only extends so far.
Cars coming 'standard' with ESP are, simply speaking, manufacturer
standards. ESP on cars is neither a recognized standard, nor a de-facto
standard - though it could become either one of those.
When there was only one single source for Objective-C - Stepstone - it
could certainly be argued that the classes shipped with Stepstone's
Objective-C compiler were a manufacturer standard; except for the fact
that Stepstone themselves didn't use that phrase, so apparently themselves
didn't consider that to be the case.
Objective-C has always had a clear separation between _language_
(semantics and syntax, i.e., compiler and runtime system) on the one hand,
and _classes_ on the other hand. Stepstone's own documentation - such as
Brad Cox & Andrew Novobilsky's book 'Object-Oriented Programming: An
Evolutionary Approach, Second Edition' - refers to the ICPak101 classes as
being 'the commercial library', and 'routinely delivered with each
Objective-C compiler license' - but never as 'standard', or as a _part_ of
the Objective-C _language_ itself.
Of course, once other Objective-C compilers became available, those did
_not_ all come with that same, or a compatible, class library; and users
didn't appear to expect those classes to be there, so apparently the
classes hadn't established themselves as a de-facto standard. Other
Objective-C compilers shipped with different classes, or with no classes
at all - after all, the language allows developers to write their own
class library from the ground up. NeXT, for instance, defined their own
manufacturer standard in the shape of the NeXTStep classes.
>Objective-C is like Smalltalk
>in this respect, and you could say that Smalltalk when it did not have
>an approved recognized standards body, but it still had its standard classes
>and its standard class hierarchy
That was because there was a de-facto standard, which had evolved from the
manufacturer standard - i.e., users were expecting Smalltalk systems to
behave similar to and include the same sort of classes as an original
Xerox Smalltalk system. With Objective-C, users' expectations didn't
apparently extend as far in the realm of classes, as was the case in
Smalltalk.
However, even if one were to assume, for the sake of this argument, that
the ICPak101 classes were indeed a de-facto standard for Objective-C at
one time, this does not mean that they are forever locked in time as the
one true Objective-C class library - because standards evolve, and get
replaced, as mentioned above. This means that even if David Stes'
assertions about Object&OrderedCollection&co being 'standard' at one time
were true, this does not mean that they _are_ 'standard' _now_.
One quick look at the Objective-C landscape of today shows that:
a) There is one authoritative source for the Objective-C language: Apple.
b) The vast majority of Objective-C development is done on and for Apple's
Mac OS X, with its Cocoa frameworks
c) The second biggest Objective-C development community is the GNUStep
community - which uses the same basic Foundation calsses as Apple's Cocoa.
In other words, the Cocoa/GNUStep/OpenStep Foundation classes are both an
authoritative manufacturer standard (from Apple - the authoritative source
for all things Objective-C - for Apple's own OS), and a de-facto standard
used by the majority of Objective-C users.
So if there's anything today that deserves the moniker 'standard
Objective-C class library', it would be Cocoa's Foundation - not ICPak101.
>(and the Objective-C standard objects are
>directly traceable back to the standard classes of Smalltalk-76).
The world has moved a fair bit since 1976. It should be no surprise that
there are more modern classes that have displaced those that were
originally developed almost three decades ago. Desperately clinging on to
an old and outmoded set of classes strikes me as suboptimal.
Best wishes,
// Christian Brunschen
| |
| David Stes 2005-03-20, 8:58 am |
| Christian Brunschen <cb@df.lth.se> wrote:
>
> Cars coming 'standard' with ESP are, simply speaking, manufacturer
> standards. ESP on cars is neither a recognized standard, nor a de-facto
> standard - though it could become either one of those.
>
> When there was only one single source for Objective-C - Stepstone - it
> could certainly be argued that the classes shipped with Stepstone's
> Objective-C compiler were a manufacturer standard;
The point that I was making, is that removing the standard set of
collection classes that come integrated with the Objective-C compiler,
is like removing ESP as a standard feature from a car.
Suppose that a car manufacturer that ships ESP as a standard feature,
is purchased by another car manufacturer who *removes* the standard ESP
functionality. That's what happens with some Objective-C implementations,
who instead of having more standard features, have actually less.
| |
| Stefan Arentz 2005-03-20, 8:58 am |
| David Stes <stes@dD5E02B62.access.telenet.be> writes:
> Christian Brunschen <cb@df.lth.se> wrote:
>
> The point that I was making, is that removing the standard set of
> collection classes that come integrated with the Objective-C compiler,
> is like removing ESP as a standard feature from a car.
>
> Suppose that a car manufacturer that ships ESP as a standard feature,
> is purchased by another car manufacturer who *removes* the standard ESP
> functionality. That's what happens with some Objective-C implementations,
> who instead of having more standard features, have actually less.
Show some proof. Every single class that the OS X world does not use has
an excellent replacement in the Cocoa framework. Of course you would not
know that since you have never used Cocoa.
Really David, don't you ever get bored of this pointless discussion?
S.
| |
| Michael Ash 2005-03-20, 4:03 pm |
| Stefan Arentz <stefan.arentz@gmail.com> wrote
>
> Really David, don't you ever get bored of this pointless discussion?
David is obviously insane, so the question is not very interesting. I do
wonder about the rest of you though; don't *you* ever get bored of it?
| |
|
| On Sat, 19 Mar 2005 14:02:54 +0000, David Stes wrote:
> Alwyn <alwyn@blueyonder.co.uk> wrote:
>
> You confuse the standard with your recognised standards body.
No it is you who confuse standards in programming languages with those in
(mainly German) cars.
> A standard exists before it is formalized;
No, before a standard is formalised, the term 'pre-standard' is often
used. All C++ before 1997 is called pre-standard, and the same term could
be applied to C before 1998.
Another example is ML. The first ML (Meta-Language) was invented at
Edinburgh in 1974 as a language for proving theorems, A standard version
dates from 1990, called SML (Standard ML), and this is a fully fledged
programming language with a formal definition. (The current SML standard
was established in 1997.) There are other dialects of ML in existence,
most notably O'Caml (Objective Caml). Nobody talks about 'standard OCaml'
because a formal definition of OCaml has never been presented, yet, given
that there is only one implementation, this is not necessarily a handicap.
<http://caml.inria.fr/>
> For example, if I'm purchasing a new car, then I wonder what the
> "standard" equipment is (whether it comes 'standard' with ESP, for
> example).
>
> ESP is not recognized by a standards body as standard for cars, but I
> can still say that it is standard for a certain car manufacturer.
Certainly. I have no problem with that.
> Just as you can say, this car comes 'standard' with ESP, it is clear
> that Objective-C has always come with a standard set of objects, things
> like Object, Set, OrderedCollection etc. that are *included* with the
> compiler.
But I do have a problem with this. 'Objective-C has always come with a
standard set of objects' is fiction, not fact. Perhaps we differ not only
in the use of 'standard' but also in that of 'always'. A most
extraordinary state of affairs!
> This is like Smalltalk, but unlike other systems, like C++,
> which you get without standard classes.
Well no, every standard C++ compiler in existence today comes with a
standard class library. Sine qua non.
> Objective-C is like Smalltalk
> in this respect, and you could say that Smalltalk when it did not have
> an approved recognized standards body, but it still had its standard
> classes and its standard class hierarchy (and the Objective-C standard
> objects are directly traceable back to the standard classes of
> Smalltalk-76).
But the problem is that without an official definition which is commonly
followed, there is never any kind of guarantee that vendor X's product
will work the same as that of vendor Y.
I sometimes have the impression that the discourse of David Stes is more
like theology than informatics. There is an entrenched position based on
tradition, while in the computing world, everything is in a state of flux.
Alwyn
| |
|
| On Sun, 20 Mar 2005 07:20:13 -0600, Michael Ash wrote:
>
> David is obviously insane, so the question is not very interesting.
I don't know about 'obviously insane'. I observed elsewhere that he uses
a religious mode of thought, which is fine for theology but inappropriate
for informatics.
> I do
> wonder about the rest of you though; don't *you* ever get bored of it?
So little happens in this forum that arguing with Mr Stes is probably a
diversion. As on occasional visitor, I don't particularly mind, but I
appreciate it can get repetitive for regulars.
Alwyn
| |
| glenn andreas 2005-03-20, 4:03 pm |
| In article <apb%d.41712$Cz6.3704886@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
> Christian Brunschen <cb@df.lth.se> wrote:
>
> The point that I was making, is that removing the standard set of
> collection classes that come integrated with the Objective-C compiler,
> is like removing ESP as a standard feature from a car.
So why doesn't POC come with the standard classes? You know, the ones
that come standard with the Objective-C distribution that comes from the
legally recognized owners of the language?
| |
| Christian Brunschen 2005-03-20, 4:03 pm |
| In article <gandreas-88DFE2.09564720032005@ip-lcc.supernews.net>,
glenn andreas <gandreas@no.reply> wrote:
>In article <apb%d.41712$Cz6.3704886@phobos.telenet-ops.be>,
> David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>
>
>So why doesn't POC come with the standard classes? You know, the ones
>that come standard with the Objective-C distribution that comes from the
>legally recognized owners of the language?
For that matter, why doesn't POC come with the _language_ features -
Categories, Protocols, constant strings and so on - that have been part of
the official Objective-C language for almost a decade?
Best wishes,
// Christian Brunschen
| |
| Stefan Arentz 2005-03-20, 4:03 pm |
| Michael Ash <mike@mikeash.com> writes:
> Stefan Arentz <stefan.arentz@gmail.com> wrote
>
> David is obviously insane, so the question is not very interesting. I do
> wonder about the rest of you though; don't *you* ever get bored of it?
I just p at this group once in a while and post little messages. Unlike
for example Christian, who writes whole books as replies. Now where does he
find the time and motivation :-)
S.
| |
| Christian Brunschen 2005-03-20, 4:03 pm |
| In article <87br9ez0mr.fsf@keizer.soze.com>,
Stefan Arentz <stefan.arentz@gmail.com> wrote:
>Michael Ash <mike@mikeash.com> writes:
>
>
>I just p at this group once in a while and post little messages. Unlike
>for example Christian, who writes whole books as replies. Now where does he
>find the time and motivation :-)
I dislike leaving FUD standing unrefuted. When composing my replies, I try
to be as comprehensive as possible, and to provide references, quotes,
sample source code, etc as best I can. I also try to be descriptive enough
that my reasoning is hopefully fairly straightforward to follow, and
demonstrate how and why I arrive at my conclusions.
It does get a bit boring that David Stes keeps bringing out the same old
FUD over and over. But, as his arguments sometimes seem almost lucid, it's
an occasionally useful challenge to arrange an express my arguments just
to make sure I've countered his false claims and exposed them.
> S.
Best wishes,
// Christian Brunschen
| |
| David Stes 2005-03-20, 4:03 pm |
| glenn andreas <gandreas@no.reply> wrote:
>
> So why doesn't POC come with the standard classes?
POC comes with the standard Object subclasses; the classes that one can
use without having to rewrite time after time again the same things.
Removing Object, Set, OrderedCollection, SortedCollection etc. is
removing essential functionality from the system.
In this sense, some Objective-C implementations have regressed.
| |
| Christian Brunschen 2005-03-20, 4:03 pm |
| In article <_Xj%d.42037$f24.3543092@phobos.telenet-ops.be>,
David Stes <stes@dD5E02B62.access.telenet.be> wrote:
>glenn andreas <gandreas@no.reply> wrote:
>
> POC comes with the standard Object subclasses; the classes that one can
>use without having to rewrite time after time again the same things.
Not the 1988 classes - the 2005 classes, please; NSObject, NSArray,
NSDictonary, NSString, etc - the classes that are defined by the owners of
the Objective-C trademark, the maintainers of the Objective-C langauges,
Apple, and which obsoleted the ICPak101 classes when the OpenStep
specification was released over a decade ago, in 1994.
> Removing Object, Set, OrderedCollection, SortedCollection etc. is
>removing essential functionality from the system.
This would only be the case if there weren't other classes available that
offer similar functionality - and there are: the Cocoa/OpenStep/GNUStep
Foundation classes, which in fact offer _more_ functionality than the
ICPak101 classes did.
> In this sense, some Objective-C implementations have regressed.
Ah! I get it: David Stes' vision is fixed on one specific point in time,
which is now firmly in the past. Thus, he sees everything that takes
Objective-C away from that particular 'ideal point' as 'regression' -
because he is looking back, and has got 'forwards' and 'backwards' mixed
up.
Best wishes,
// Christian Brunschen
| |
| Charlton Wilbur 2005-03-20, 8:59 pm |
| >>>>> "CB" == Christian Brunschen <cb@df.lth.se> writes:
CB> When composing my replies, I try to be as comprehensive as
CB> possible, and to provide references, quotes, sample source
CB> code, etc as best I can. I also try to be descriptive enough
CB> that my reasoning is hopefully fairly straightforward to
CB> follow, and demonstrate how and why I arrive at my
CB> conclusions.
I've learned useful things from the refutations of David Stes, and I'm
glad his FUD gets challenged by those with more free time than I.
Charlton
--
cwilbur at chromatico dot net
cwilbur at mac dot com
| |
| Erwann ABALEA 2005-03-21, 3:58 am |
| On Sun, 20 Mar 2005, Alwyn wrote:
> On Sat, 19 Mar 2005 14:02:54 +0000, David Stes wrote:
[...]
>
> No, before a standard is formalised, the term 'pre-standard' is often
> used. All C++ before 1997 is called pre-standard, and the same term could
> be applied to C before 1998.
Not really. C was standardized in 1989 by ANSI, and 1990 by ISO.
Did you meant 1988 in your sentence?
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Et si Windows NT plante c'est que vous ętes trop débile que pour le
configurer correctement ... ou alors vous avez du matos de merde .
-+- BB in : Guide du Neuneu d'Usenet - Attention neuneu violeNT -+-
| |
| Ian Robinson 2005-03-21, 9:00 am |
| On Sun, 20 Mar 2005 18:25:52 +0000, Christian Brunschen wrote
(in article <d1kf7g$kh1$1@news.lth.se> ):
> I also try to be descriptive enough
> that my reasoning is hopefully fairly straightforward to follow, and
> demonstrate how and why I arrive at my conclusions.
I'd like to thank you. I find your post very informative.
Ian
--
Ian Robinson, Belfast, UK - <http://www.canicula.com>
Soapbox - <http://homepage.mac.com/ianrobinson/index.html>
| |
|
| On Mon, 21 Mar 2005 08:04:20 +0100, Erwann ABALEA wrote:
> On Sun, 20 Mar 2005, Alwyn wrote:
>
> [...]
>
> Not really. C was standardized in 1989 by ANSI, and 1990 by ISO.
> Did you meant 1988 in your sentence?
No, I meant 1989 and accidentally transposed the last two digits.
Erwann Abalea,  name. Anv brezhonek eo?
Alwyn
|
|
|
|
|