ObjC 2.0
Graham J Lee
http://developer.apple.com/leopard/overview/index.html
"Now in Leopard, the Objective-C runtime has been updated to include a
thoroughly modern and high performance garbage collection system, making
memory management a thing of the past.
Also new in Objective-C 2.0 are a set of syntax improvements, including
property accessors and fast enumeration. These improvements bring the
language up-to-date with the expectations of today’s programmers. And,
since Objective-C 2.0 is compatible with existing Objective-C source,
you can adopt it at your own pace."
But AFAICT the meat and two veg is still hidden behind the NDA'd Leopard
Early Start Kit for developers.
--
Graham Lee
http://www.thaesofereode.info
Michael Ash
> OK, ObjC2 has now been slightly more publicly announced:
> http://developer.apple.com/leopard/overview/index.html
>
> "Now in Leopard, the Objective-C runtime has been updated to include a
> thoroughly modern and high performance garbage collection system, making
> memory management a thing of the past.
>
> Also new in Objective-C 2.0 are a set of syntax improvements, including
> property accessors and fast enumeration. These improvements bring the
> you can adopt it at your own pace."
>
> But AFAICT the meat and two veg is still hidden behind the NDA'd Leopard
> Early Start Kit for developers.
Let's see what I can say without having large burly well-dressed NDA
police show up outside my door.
For anyone who may have seen the name and panicked, don't. The "2.0" is
definitely a marketing thing, nothing more. This are not enormous
far-reaching changes to the language that will forever change how we do
things. (Garbage collection is a possible exception here, but it is
optional and probably a good thing overall.)
In particular, I see previous new language features like categories and
protocols as being of similar significance to these, and yet they never
got anybody talking about a "2.0".
One unfortunate thing is that the new language features mostly or entirely
require new runtime features, meaning that apps which use them will
require Leopard. Assuming Leopard ships in about six months, this means I
won't be able to use them in shipping apps for probably two years or more.
But such is the way with most new features.
--
Michael Ash
Rogue Amoeba Software
Charlton Wilbur
> One unfortunate thing is that the new language features mostly or entirely
> require new runtime features, meaning that apps which use them will
> require Leopard. Assuming Leopard ships in about six months, this means I
> won't be able to use them in shipping apps for probably two years or more.
> But such is the way with most new features.
Isn't there a possible counter-precedent for this, with Apple updating
certain runtime libraries in 10.3.9? Not with the full Core Data
treatment that you get in 10.4, of course.
Charlton
Michael Ash
This is an interesting point, and you are correct. However, that situation
was unique in several ways:
- The libraries in question (just libstdc++.dylib afaik, are there
others?) were reqired for compatibility with code generated with a major
new compiler version.
- The libraries are required for *any* code generated with that compiler,
not just code that takes advantage of new features.
- This major new compiler version was required for building universal
binaries*. Although nobody outside Apple realized this was important at
the time, I would not be surprised if this was a major reason for doing
it.
There are also counter-precedents, such as the new runtime functionality
required for the @syntax exceptions introduced in 10.3, which was never
made available for previous OSes. (Are there actually other
counter-precedents?)
We can also be sure that garbage collection, at least, will not be made
available on 10.4 because it requires extensive changes to all ObjC
libraries which the application uses, and it's extremely doubtful Apple
will make the necessary changes to things like Foundation and AppKit on
Tiger.
* Yes, you can make UBs with gcc3.3 on the PPC side and gcc4 on the i386
side, but it's a pain in the ass and Apple surely wanted people to be
building UBs as easily as possible.
Michael Ash
> Charlton Wilbur <cwi...@mithril.chromatico.net> wrote:
>>
>> Isn't there a possible counter-precedent for this, with Apple updating
>
> There are also counter-precedents, such as the new runtime functionality
Obviously I meant to say counter-counter-predecents here. No doubt some
smart fellow will be along with some counter-counter-counter-predecents
shortly.
Charlton Wilbur
(in response to me)
> > Isn't there a possible counter-precedent for this, with Apple updating
> > certain runtime libraries in 10.3.9? Not with the full Core Data
> > treatment that you get in 10.4, of course.
>
> This is an interesting point, and you are correct. However, that situation
> was unique in several ways:
>
> - The libraries in question (just libstdc++.dylib afaik, are there
> others?) were reqired for compatibility with code generated with a major
> new compiler version.
Thank you; I didn't remember what it was, only that it didn't really
affect any of the work I was doing at the time.
> There are also counter-precedents, such as the new runtime functionality
> required for the @syntax exceptions introduced in 10.3, which was never
> made available for previous OSes. (Are there actually other
> counter-precedents?)
Hrm, I thought that @try/@catch/@finally were just syntactic sugar for
the NS_* style of exception handling. I might be wrong on that.
> We can also be sure that garbage collection, at least, will not be made
> available on 10.4 because it requires extensive changes to all ObjC
> libraries which the application uses, and it's extremely doubtful Apple
> will make the necessary changes to things like Foundation and AppKit on
> Tiger.
Probably; and it's also a driver to get more people to upgrade. Part
of the migration strategy to Tiger, where most of the improvements
were under the hood, was to get developers on board as early as
possible so that when Tiger shipped there would already be apps out
there using Core Data and Core Image and with support for Spotlight
and Dashboard. It wouldn't surprise me if that was part of the
strategy here too.
Charlton
Clark S. Cox III
> > required for the @syntax exceptions introduced in 10.3, which was never
> > made available for previous OSes. (Are there actually other
> > counter-precedents?)
>
> Hrm, I thought that @try/@catch/@finally were just syntactic sugar for
> the NS_* style of exception handling. I might be wrong on that.
The NS_ macros are just that, macros, the
@try/@catch/@finally@synchronized require compiler and runtime support
beyond what 10.3's libraries provide.
--
Clark S. Cox III
clar...@gmail.com
Michael Ash
>> required for the @syntax exceptions introduced in 10.3, which was never
>> made available for previous OSes. (Are there actually other
>> counter-precedents?)
>
> Hrm, I thought that @try/@catch/@finally were just syntactic sugar for
> the NS_* style of exception handling. I might be wrong on that.
There's fairly extensive compiler support, as should be obvious from the
fact that things don't break if you return from the middle of a @try
block. The support functions were also moved from Foundation into the objc
runtime itself, probably because this is supposed to be a language feature
and so it should be available even if you're not using Foundation.
At the same time, the Foundation functions that the NS macros use were
made to wrap the new runtime functions, so that the two systems can work
together.
>> We can also be sure that garbage collection, at least, will not be made
>> available on 10.4 because it requires extensive changes to all ObjC
>> libraries which the application uses, and it's extremely doubtful Apple
>> will make the necessary changes to things like Foundation and AppKit on
>> Tiger.
>
> Probably; and it's also a driver to get more people to upgrade. Part
> of the migration strategy to Tiger, where most of the improvements
> were under the hood, was to get developers on board as early as
> possible so that when Tiger shipped there would already be apps out
> there using Core Data and Core Image and with support for Spotlight
> and Dashboard. It wouldn't surprise me if that was part of the
> strategy here too.
Apple wins upgrades by taking the path of least resistence, sounds like a
good strategy to me.
I would tend to believe that it's more due to simplicity than anything
else. It's *hard* to backport new features. The 10.3.9 example was really
just a single library which doesn't interact with the OS at all (again,
unless I missed one). But I'm sure they appreciate the push for upgrades
that it causes too.
Graham J Lee
swallowed it, so apologies for terseness...
It's my belief that the new features in ObjC 2 (and hence the marketing
push of reversioning the language) are there to get external developers
(and new developers too) to take a fresh look at ObjC. These new
runtime enhancements seem to me to round off a stack which is Cocoa+Core
Data+Cocoa Bindings, and has been trickling out of Apple since 10.3 (if
we take 10.2 to be a "shoring up" of the existing Cocoa port).
What's interesting to me is that the new features seem to be aimed more
at Ruby, Python and possibly Java types than the C/C++ types I'd have
expected Apple to be pushing ObjC to.
Ian Robinson
(in article <12juccl...@corp.supernews.com>):
> What's interesting to me is that the new features seem to be aimed more
> at Ruby, Python and possibly Java types than the C/C++ types I'd have
> expected Apple to be pushing ObjC to.
Realbasic developers (who don't want cross platform features) might
take a look at Cocoa/Obj-C now that the need to (semi) manually manage
memory is optional.
Ian
--
Ian Robinson, Belfast, UK
<http://www.canicula.com/wp/>
Michael Ash
> On Wed, 25 Oct 2006 10:42:26 +0000, Graham J Lee wrote
> (in article <12juccl...@corp.supernews.com>):
>
>> What's interesting to me is that the new features seem to be aimed more
>> at Ruby, Python and possibly Java types than the C/C++ types I'd have
>> expected Apple to be pushing ObjC to.
>
> Realbasic developers (who don't want cross platform features) might
> take a look at Cocoa/Obj-C now that the need to (semi) manually manage
> memory is optional.
It's not really "now" yet, unless you pay Apple some big bucks for an
unfinished bug-ridden OS and write code the public won't be able to run
for months.
In any case, garbage collection is nice but if that's the only thing
stopping you from switching to Objective-C then something really strange
is going on. Sure, it has a bit of a steep learning curve but so do a
zillion other things in programming. Your RBer is still going to get
caught by the type system, pointers, syntax, buffer overflows, etc.
Ian Robinson
(in article <11621256...@nfs-db1.segnet.com>):
> In any case, garbage collection is nice but if that's the only thing
> stopping you from switching to Objective-C then something really strange
> is going on.
True. But you often see comments about having to manually manage memory
in Cocoa at present. Whether it's hard to do or not is not relevant to
a certain section of developers (hobbyists writing apps for themselves
etc.) as some of them have a perception that it is.
Many people who are not commercial developers, and therefore don't have
to maintain their apps on pre-Leopard OSes, will be able to use the new
features, including GC, from day 1.
Anyway, if it brings over more RB developers into the Cocoa camp then
happy days. It'll result in better apps. RB is okay but Xcode, Obj-C &
Cocoa is better. I moved an RB app to Xcode & Cocoa and it's noticeably
faster, and the controls gets drawn better (nicer) on screen so the app
feels much better in use.
David Stes
>
> thoroughly modern and high performance garbage collection system, making
> memory management a thing of the past.
Is NSobject now also replaced again by the normal Object class ?
Looks like NSobject has no role any longer, now that 'autorelease pool'
memory management is obsolete.
David Stes
>
> True. But you often see comments about having to manually manage memory
> in Cocoa at present. Whether it's hard to do or not is not relevant to
> a certain section of developers (hobbyists writing apps for themselves
> etc.) as some of them have a perception that it is.
This perception stems from the core dumps that are perceived to crash
the applications.
Christian Brunschen
Those core dumps only occur if the reference counting is used incorrectly.
Fortunately, this is a rare occurrance. There is only really one point at
which Cocoa's reference-counted memory management may be problematic - and
that is the brief period of time when someone is first learning it. On the
plus side, it is quite simple and straightforward, and easy to learn, so
that period is indeed pleasantly brief (except, apparently, for David
Stes, who has been making the same inaccurate claims for _years_).
However, to certain developers (such as the hobbyists mentioned above) who
are used to an environment (such as RealBasic) where they have much more
hand-holding in place, the prospect of having to learn to use any memory
management scheme can sound like having to make a bigger investment (in
time and effort) than they actually would, and may thus steer them away
from using Cocoa.
The introduction of garbage collection in Objective-C will allow more
developers to more easily start using Cocoa, because one more percieved
hurdle is gone - and thus, to use Objective-C.
Of course, garbage collection has its own issues, but those tend to become
apparent only later on, and don't intimidate people initially.
Best wishes,
// Christian Brunschen
Christian Brunschen
Of course not. For one, it is _NSObject_ that is now the 'normal' root
class, whereas Object has been obsolete for a number of years. For
another, this would discard all of the _other_ improvements that NSObect
has over Object, including of course using and supporting more modern
language features (which have still been in the language for many years,
and showcasing how ancient Object really is) such as protocols and
categories - not to mention that NSObject is part of a framework with lots
of other classes, including for instance NSString and NSInvocation, which
combine to make a much richer environment than was ever offered by Object
and its derived classes.
Greg Parker
> Graham J Lee <info.thae...@leeg.invalid> wrote:
>>
>> "Now in Leopard, the Objective-C runtime has been updated to include a
>> thoroughly modern and high performance garbage collection system, making
>> memory management a thing of the past.
>
> Is NSobject now also replaced again by the normal Object class ?
Nope. In fact, class Object will likely be removed altogether
from the 64-bit runtime, because nobody uses it anymore.
--
Greg Parker gpa...@apple.com Runtime Wrangler
David Stes
>
> Those core dumps only occur if the reference counting is used incorrectly.
> Fortunately, this is a rare occurrance.
Of course not. Ever since Apple converted Object to NSObject in their
implementation of Objective-C, all of their applications were either leaking
tons of memory or just crashing because their NSObject memory management
(with retain/release/autorelease and so on) simply didn't work.
Fortunately this is now all a thing of the past.
We must look forward, not backwards to this silly NSautorelease stuff that
is now dead, obsolete, and very soon to be forgotten .
Christian, did you already run a conversion script on your code to remove
the autorelease/retain/release messages ? You don't need them any more.
Christian Brunschen
David Stes <st...@dD5E02BEB.access.telenet.be> wrote:
>Christian Brunschen <c...@df.lth.se> wrote:
>>
>> Those core dumps only occur if the reference counting is used incorrectly.
>> Fortunately, this is a rare occurrance.
>
>Of course not. Ever since Apple converted Object to NSObject in their
>implementation of Objective-C, all of their applications were either leaking
>tons of memory or just crashing because their NSObject memory management
>(with retain/release/autorelease and so on) simply didn't work.
The above claim is, of course, entirely inaccurate, as has been shown over
and over in this very newsgroup - and of course as is demonstrated by the
large and constantly growing number of applications that build on, and
use, Cocoa and its reference counting _without_ collapsing - leaving David
Stes' claims to do the falling apart, instead.
>Fortunately this is now all a thing of the past.
Even more fortunately, it actually never was real in the first place.
>We must look forward, not backwards to this silly NSautorelease stuff that
>is now dead, obsolete, and very soon to be forgotten .
The reference-counting memory management will certainly be gladly laid
aside by a number of people - but it will also be remembered, and rightly
so, as one of the big improvements that NeXT/Apple made in the progress of
Objective-C through the years, and in which chain garbage collection is
now the next step. And of course, reference counting is still a valuable
technique for managing the lifecycles of other dependencies (such as
external resources), which garbage collection is _not_ well-equipped to
handle.
>Christian, did you already run a conversion script on your code to remove
>the autorelease/retain/release messages ? You don't need them any more.
No conversion script is needed, nor is it a good idea if developers want
their code to compile and run both systems that support garbage collection
and those that don't. Of course the same code will work fine both with and
without garbage collection - which goes to show the strength of the
existing solution.
For more information and to learn more about Objective-C, please feel free
to join Apple Developer Connection, at <http://connect.apple.com/> .
There's a brief mention of new Objective-C features at
<http://developer.apple.com/leopard/overview/> .
Clark S. Cox III
> Christian Brunschen <c...@df.lth.se> wrote:
> > Those core dumps only occur if the reference counting is used incorrectly.
> > Fortunately, this is a rare occurrance.
>
> Of course not. Ever since Apple converted Object to NSObject in their
> implementation of Objective-C, all of their applications were either leaking
> tons of memory or just crashing because their NSObject memory management
> (with retain/release/autorelease and so on) simply didn't work.
Wow, you must be using a completely different set of Apple programs than
I have ... oh yeah, you have zero experience with MacOSX, and remain
willfully ignorant of modern Objective-C implementations, yet continue
to spread worthless FUD.
> Fortunately this is now all a thing of the past.
>
> We must look forward, not backwards to this silly NSautorelease stuff that
> is now dead, obsolete, and very soon to be forgotten .
First, the class is "NSAutorelease", not "NSautorelease". Second,
garbage collection is not the right tool for every job, there will still
be occasions where retain/release is still the best memory management model.
> Christian, did you already run a conversion script on your code to remove
> the autorelease/retain/release messages ? You don't need them any more.
Ian Robinson
(in article <jnu1h.157363$tx4.2...@phobos.telenet-ops.be>):
> This perception stems from the core dumps that are perceived to crash
> the applications.
No it doesn't. Silly person.
David Stes
>
> The reference-counting memory management will certainly be gladly laid
> aside by a number of people - but it will also be remembered, and rightly
> so, as one of the big improvements that NeXT/Apple made in the progress of
> Objective-C through the years, and in which chain garbage collection is
> now the next step.
Apple autorelease will be remembered as a messy piece of garbage,
that was badly designed from day one.
The best proof of this is that they apparently are trying to get rid of
their own badly developed software, themselves.
David Stes
> willfully ignorant of modern Objective-C implementations
I am not ignorant of modern Objective-C, in fact, what you call "modern"
like garbage collection (GC) has been available since 1989 or so to
Objective-C to the Stepstone compiler.
It seems that Objective-C "2.0" starts to adopt some of the functionality
like GC from 1989, but I have not seen an indication yet that ObjC 2.0
have closures and Objective-C BLOCKS ("action expressions" ?)
Christian Brunschen
David Stes <st...@dD5E02BEB.access.telenet.be> wrote:
>Christian Brunschen <c...@df.lth.se> wrote:
>>
>> The reference-counting memory management will certainly be gladly laid
>> aside by a number of people - but it will also be remembered, and rightly
>> so, as one of the big improvements that NeXT/Apple made in the progress of
>> Objective-C through the years, and in which chain garbage collection is
>> now the next step.
>
>Apple autorelease will be remembered as a messy piece of garbage,
>that was badly designed from day one.
Hardly. It will be remembered as a solid, working, solution to a hard
problem - how to offer the developer assistance in managing object
lifecycles, without making existing code stop working.
>The best proof of this is that they apparently are trying to get rid of
>their own badly developed software, themselves.
... and after only about 15 years of successful use!
The truth is that Cocoa's reference counting has worked well, and let
developers write solid, well-working applications, for a long time. But in
that time, things have changed: other language features have come to be
added, and be more heavily relied on. For instance, exceptions - they were
also once a feature outside the language itself (usually offered by macros
such as NS_DURING, NS_HANDLER and NS_ENDHANDLER, and a hierarchy of
cebspoke exception classes), but have now become a part of the language.
Similarly, object lifecycle and memory management has, until now, always
been outside the language itself, and offered by the classes. Now, memory
management is being made into a language feature. It's simply a case of
natural progress, but without rushing headlong into things.
Christian Brunschen
David Stes <st...@dD5E02BEB.access.telenet.be> wrote:
>Clark S. Cox III <clar...@gmail.com> wrote:
>
>> willfully ignorant of modern Objective-C implementations
>
>I am not ignorant of modern Objective-C, in fact, what you call "modern"
>like garbage collection (GC) has been available since 1989 or so to
>Objective-C to the Stepstone compiler.
I'm fairly certain that the modern Objective-C features Clarc Cox was
referring to also include things such as categories and protocols, which
have been in the language for well over a decade, but which David Stes
appears to conveniently forget whenever modern Objective-C is mentioned.
>It seems that Objective-C "2.0" starts to adopt some of the functionality
>like GC from 1989, but I have not seen an indication yet that ObjC 2.0
>have closures and Objective-C BLOCKS ("action expressions" ?)
Closures, 'blocks' and 'action expressions' are all similar but also
slightly different.
Closures are of course a well-known concept in many computing paradigms
and languages, and offer functionality that can be very useful (among
other things depending on what other tools you have available to work
with). This includes such functionality that, if a closure is created
referring to a variable declared outside it, and the closure modifies that
variable, then the actual variable declared outside the closure is
modified. This is done by the closure keeping a reference to any context
in which it was created to which the closure refers; so, for any variable
that is open within the closure itself but which is declared outside the
closure, the closure is 'closed' by keeping a reference not just to that
variable, but to the context in which that variable was declared.
Closures indeed _rely_ on being able to keep around the context in which
the closure was created, including the activation record of the
function/method/procedure in which this occurred. In laguages of the C
family, this is extremely tricky, as C keeps all its activation records on
a stack - which means that you cant keep one around once he function in
question has been returned from. Languages that offer closures do so by
allowing activation records to live in other places than on the stack,
which adds some complexity (they now have to be allocated from the heap,
and possibly garbage-collected), but also gives precisely the flexibility
needed for closures.
Smalltalk, for instance, offers closures under the name 'Blocks'.
Smalltalk actually _needs_ blocks, because Smalltalk has no features in
the language for control flow features like conditions or iteration ('if'
or 'while' statements in C) - these are all achieved using Blocks.
Objective-C, while borrowing its object model from Smalltalk, is
fundamentally a language of the C family, and thus cannot offer closures.
Brad Cox, in his Taskmaster paper
(<http://www.virtualschool.edu/cox/pub/TaskMaster/>), describes a similar
concept, 'action expressions', which he describes: "Action expressions in
Objective-C are related to block expressions in Smalltalk, with
differences that adapt to the constraints of stack-based languages like
C."
The main difference is that rather than closing the action expression by
keeping references to those variables that are open in the action
expression itself but defined in its enclosing context (which would
necessitate keeping the activation records in which they were declared),
an action expression is 'closed' by receiving a _copy_ of each such
variable, initialised to the same value that it has when the action
exression was instantiated. The action expression thus no longer needs to
refer to its context, because it has been given, at instantiation time,
all the information it needs. But it also means that if the action
expression modifies such a variable, only its copy of the variable is
modified, _not_ the original variable that was referred to then the action
expression was created. Thus, action expressions are _not_ closures in the
sense that the term is commonly used.
Brad Cox's action expressions never made it into any released version of
the Objective-C language.
David Stes, in his 'POC' ('Portable Object Compiler') (which is a hobby
project, quite buggy, and hasn't properly tracked the Objective-C language
for over a decade, instead focusing on his own, incompatible extensions),
implements a further, different beast, which he erroneously claims is the
same as Brad Cox's action expressions, but is in fact incompatible in its
semantics. Again, he runs up against the issue that any C-family language
is stack-based, and thus cannot support closures. However, to attempt to
address this issue, he takes a different approach than Brad Cox. Rather
than copying the values of externally referenced variables into the action
expression, POC modifies the declarations of all variables that are
referenced from within a Block: They get moved to being members of a C
struct, which is then heap-allocated, and _all_ references to those
variables will now have to go through a pointer indirection, even those
references that one would expect (from the code itself) to go directly to
the variable on the stack. Thus, POC essentially tries to move _some_ of
the necessary activation record(s) onto the heap, but of course cannot do
so entirely. This still doesn't give full closure, but is also still
different from Brad Cox's action expressions (for instance, two action
expressions referring to the same variable will get a copy each, whereas
to POC Blocks will each have a reerence to a shared variable, which would
give different results when running); and of course it actually changes
code that is _outside_ the 'block' itself, which may have rather
interesting effects on the performance of that code (when variables that
are 'declared on the stack' are actually malloc()ed on the heap, all
references to them have to go through an extra pointer, etc - whether or
not the instantiated block is ever executed or even instantiated, just
because it _might be_).
There's also the issue whether or not Objective-C even _needs_ something
like blocks. Smalltalk does indeed need them, as discussed above - but
Objective-C, as a C-family language, already has control flow facilities
for conditions and loops, so that pressing need goes out the window.
Of course, closures are useful for other things, as well, essentially
being a higher-order programming mechanism - for instance, Smalltalk has
methods on its collection classes that take a block and evaluate it for
every object in the collection in question, gathering the result into a
new collection - akin to the 'map' function in functional programming. But
here, too, Objective-C already has other mechanisms that offer similar
fucntionality, without having to try to add closure support onto a
substrate (C) that is ill suited to this task: Specifically, Objective-C's
powerful messaging model (borrowed from Smalltalk) can be leveraged in the
form of higher order messaging, 'HOM', as described by Marcel Weiher in
his OOPSLA paper,
<http://www.metaobject.com/papers/Higher_Order_Messaging_OOPSLA_2005.pdf>.
So we have a situation where closures are difficult, perhaps impossible,
to implement properly, while at the same time their necessity is
questionable. Is it really surprising that they _aren't_ in the
Objective-C language?
[ And as an aside - if there was a desire for something like blocks ...
there is a _C_ language construct that would be much more suitable as a
basis: the function. A closure is essentially just an anonymous function,
whose open variables have been closed by supplying it with a context in
which all those variables are defined. Thus, the 'right' way to implement
closures in Objective-C, might in fact be to implement them in _C_ - at
least first; such an underlying facility could then be used to wrap an
object around, if desired. ]
Also, no compiler from any authoritative source for Objective-C has, until
now, supported garbage collection. David Stes' own POC has some support
for using the Boehm conservative garbage collector, as does the GNU
Objective-C runtime, but those are, and have always been, experimental
extensions - and have never previously been features of the Objective-C
language.
Now, of course, Apple (who own the Objective-C language, trademark, etc)
are adding garbage collection as a supported, official language feature,
not as an exerimental add-on - as well as adding other things (the
'Leopard Technology Overview' page at
<http://developer.apple.com/leopard/overview/> mentions a few of them) -
and where Apple mentions 'a thoroughly modern and high performance garbage
collection system', I beleive it's fair to guess that this is _not_ about
adding on a conservative garbage collector like Boehm's, but one that
takes into account the developments in garbage collection in the
intervening time. So this is not about 'catching up with a feature that
has been there for ages' - it's actually doing something _right_ that has
been, up to now, an interesting _experiment_.
But the upshot of all of this is that David Stes is lamenting that Apple
simply keep developing Objective-C forward, in a direction that doesn't
match _his_ personal vision, that doesn't include _his_ pet features. And,
in a sad way, lamenting that Objective-C is so successful, in spite of all
his doomsaying, in spite of his repeated claims that first NeXT, now
Apple, would disappear and become a distant memory, thus leaving him to
finally rule the Objective-C world as _he_ sees fit - instead, the success
of Apple, the success of Cocoa, the success of Objective-C, and the
continued development of Objective-C by Apple (and the way that
Objective-C and Cocoa are being tied closer together), all keep conspiring
to fly in the face of his dire predictions and wild claims and assertions
of disaster, making him ever more irrelevant. And the Objective-C world
moves on without him.
Clark S. Cox III
> Clark S. Cox III <clar...@gmail.com> wrote:
>
>> willfully ignorant of modern Objective-C implementations
>
> I am not ignorant of modern Objective-C, in fact, what you call "modern"
> like garbage collection (GC) has been available since 1989 or so to
> Objective-C to the Stepstone compiler.
I wasn't calling GC "modern", I was calling Apple's/GCC's Objective-C
implementations modern. Many language features (categories, etc.) that
are now integral part of the language, are met with your constant FUD
and ignorance.
--
Michael Ash
You have figured out that it's useless to argue, right? Whether it's due
to ignorance, incomprehension, or deliberate argumentation is irrelevant,
attempting to educate him never works and never will.
Graham J Lee
> Graham J Lee <info.thae...@leeg.invalid> wrote:
>> "Now in Leopard, the Objective-C runtime has been updated to include a
>> thoroughly modern and high performance garbage collection system, making
>> memory management a thing of the past.
>
> Is NSobject now also replaced again by the normal Object class ?
Not while features which NSObject has and Object lacks are still
required. Does ObjectPak's Object class conform to the NSObject
protocol? Perhaps I could add it as a category, or create my own new
root class to implement it. Similarly, I don't see the other useful
root class, NSProxy going anywhere.
Charlton Wilbur
> You have figured out that it's useless to argue, right? Whether it's due
> to ignorance, incomprehension, or deliberate argumentation is irrelevant,
> attempting to educate him never works and never will.
On the other hand, I've learned things from other people's responses
to Stes, and so I'm glad for the responses. There is a point at which
you have to decide that the point has been made, though.
Charlton
David Stes
>
> Not while features which NSObject has and Object lacks are still
> required. Does ObjectPak's Object class conform to the NSObject
> protocol?
The goal of ObjC 2.0 is to remove the NSObject methods, and turn it
into normal Objective-C again.
Christian Brunschen
No, the goal Objective-C is to move _forward_, not _backward_ - to offer
developers useful features that will help them, help _us_, be even more
productive and be able to write even better software with even more support
from the language.
And, of course, Apple _define_ what is 'normal' Objective-C ... and the
old, obsolete class 'Object' doesn't figure in it at all.
guenther
> On the other hand, I've learned things from other people's responses
> to Stes, and so I'm glad for the responses.
this is really true!
guenther
Graham J Lee
you're required not to disclose them. Not that I expect you do ;-)
John C. Randolph
<info.thae...@leeg.invalid> said:
>
> It's my belief that the new features in ObjC 2 (and hence the marketing
> push of reversioning the language) are there to get external developers
> (and new developers too) to take a fresh look at ObjC.
No, they're there to improve the language for the benefit of
developers. Attracting new developers is incidental.
-jcr
Bernard van Gastel
oef, I am using it.... :(
Are you really going to remove it?
Bernard van Gastel