NSObject vs Object - C

In article <711817.SDJYKYTX@news.ya.com>, <trash@yahoo.com> wrote:
>Hello, why Objective-C has two runtime class: GNU Object and NeXT NSObject?

Actually, there are several, and the history is a bit different.

First of all, the Objective-C _language_ doesn't include any classes
itself. Indeed, the language allows programmers to write their own root
class, or indeed root _classes_.

Object was introduced as part of the ICPak101 class library by Stepstone,
the original developers of Objective-C. Object ended up being widely used,
becamse essentially a de-facto standard of sorts. NeXTStep's class library
was also initially bnased on Object as the root class.

Experience developing larger systems with Objective-C prompted NeXT to
develop a new class library which ended up having to be in someways
incompatible with the Object class. Rather than trying to change the
Object class, NeXT introduced NSObject in the OpenStep frameworks (which
became today's Cocoa frameworks, and on which GNUstep is based).

Over time, NeXT purchased all Objective-C assets (including technology and
trademarks) from Stepstone, and Apple purchased NeXT. Apple is currently
the company essentially defining the language and certainly provides the
biggest platform where Objective-C is currently used. Apple use, and
advocate the use of, NSObject and its related classes (including another
root class, NSProxy, which is used among other things in Apple's
Distributed Objects system).

The GNU runtime library for Objective-C includes the Object class, but not
most of the other classes included with Stepstone's ICPak101 library.

>Is any of them deprecated?

In the sense that NSObject was developed due to perceived deficiencies in
Object, Object is deprecated by NSObject.

>I suppose that GNU Objective-C could be a try to make a Cocoa
>independent library, but I'm not sure. and I don't know if GNU Object is
>discontinued, or actually some people is working in improving it.

Certainly one could develop another, separate class library. But that begs
the question: why? just to be separate and different? And if those are the
main reasons, how do you intend to persuade people that yours is better,
especially in comparison to the one that is the current market leader
(NSObject with Cocoa / GNUStep)?

>Greetings: Fernando

Best wishes,

// Christian Brunschen

On 1/7/06 18:09, Christian Brunschen wrote:
> In article <711817.SDJYKYTX@news.ya.com>, <trash@yahoo.com> wrote:
>
>> Is any of them deprecated?
>
> In the sense that NSObject was developed due to perceived deficiencies in
> Object, Object is deprecated by NSObject.
>

And in the very real sense, if you use Object (annoyingly unavoidable,
what with a Protocol being an Object) on the Apple runtime you get
deprecation warnings:

2006-07-01 18:25:31.767 wibble[2237] *** -[Protocol
respondsToSelector:]: warning: Object compatibility method has been
executed at least once. Convert source code off it NOW!

Graham Lee <uk.ac.ox.physics.teaching@leeg.invalid> writes:
> On 1/7/06 18:09, Christian Brunschen wrote:
> > In article <711817.SDJYKYTX@news.ya.com>, <trash@yahoo.com> wrote:
> >
> >> Is any of them deprecated?
> > In the sense that NSObject was developed due to perceived deficiencies
> > in Object, Object is deprecated by NSObject.
>
> And in the very real sense, if you use Object (annoyingly unavoidable,
> what with a Protocol being an Object) on the Apple runtime you get
> deprecation warnings:
>
> 2006-07-01 18:25:31.767 wibble[2237] *** -[Protocol respondsToSelector:]:
> warning: Object compatibility method has been executed at least once.
> Convert source code off it NOW!

That's because -respondsToSelector: isn't an Object method, but
Foundation adds an implementation for compatibility. If you use
Object's own -respondsTo: method instead, you won't get the warning.

Other than class Protocol, use of class Object is discouraged.


--
Greg Parker gparker@apple.com Runtime Wrangler

Yes, your explanation sound right, but in my opinion a reason to build a library based on Object is justified to make a no Cocoa library. Currently Cocoa is very good, but proprietary library. Is not there people devoted to improve Object hierarchy / build another Objective-C library?

>> I suppose that GNU Objective-C could be a try to make a Cocoa independent
>> library, but I'm not sure. and I don't know if GNU Object is
>> discontinued, or actually some people is working in improving it.

> Certainly one could develop another, separate class library. But that
> begs the question: why? just to be separate and different? And if those
> are the main reasons, how do you intend to persuade people that yours is
> better, especially in comparison to the one that is the current market
> leader (NSObject with Cocoa / GNUStep)?

>> Greetings: Fernando

> Best wishes,

> // Christian Brunschen

Joe Challagan <challaganmadridDELIT@yahoo.com> writes:

Upside-down. Please stop that.

> Yes, your explanation sound right, but in my opinion a reason to build a
> library based on Object is justified to make a no Cocoa library. Currently
> Cocoa is very good, but proprietary library.

That's all well and good, but it says *nothing* about why you'd base your
replacement library on Object instead of making it compatible with Foundation
and AppKit.

Heck, even if I were writing a whole new view layer to replace AppKit, I'd
*still* want to make it Foundation-based so I could have model-level classes
that would be portable to Cocoa.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

On 1/7/06 21:41, Greg Parker wrote:
> Graham Lee <uk.ac.ox.physics.teaching@leeg.invalid> writes:
>> On 1/7/06 18:09, Christian Brunschen wrote:
>>> In article <711817.SDJYKYTX@news.ya.com>, <trash@yahoo.com> wrote:
>>>
>>>> Is any of them deprecated?
>>> In the sense that NSObject was developed due to perceived deficiencies
>>> in Object, Object is deprecated by NSObject.
>> And in the very real sense, if you use Object (annoyingly unavoidable,
>> what with a Protocol being an Object) on the Apple runtime you get
>> deprecation warnings:
>>
>> 2006-07-01 18:25:31.767 wibble[2237] *** -[Protocol respondsToSelector:]:
>> warning: Object compatibility method has been executed at least once.
>> Convert source code off it NOW!
>
> That's because -respondsToSelector: isn't an Object method, but
> Foundation adds an implementation for compatibility. If you use
> Object's own -respondsTo: method instead, you won't get the warning.
>

Fine, but if you're on the Apple runtime and you use the [object
message] syntax, it is *going* to trigger a
-respondsToSelector:@selector(message) message. So you have no choice
but to send -respondsToSelector:, or give up on ObjC syntax and bang the
runtime.

Graham Lee <uk.ac.ox.physics.teaching@leeg.invalid> wrote:
> On 1/7/06 21:41, Greg Parker wrote:
>> Graham Lee <uk.ac.ox.physics.teaching@leeg.invalid> writes:
>>> On 1/7/06 18:09, Christian Brunschen wrote:
>>>> In article <711817.SDJYKYTX@news.ya.com>, <trash@yahoo.com> wrote:
>>>>
>>>>> Is any of them deprecated?
>>>> In the sense that NSObject was developed due to perceived deficiencies
>>>> in Object, Object is deprecated by NSObject.
>>> And in the very real sense, if you use Object (annoyingly unavoidable,
>>> what with a Protocol being an Object) on the Apple runtime you get
>>> deprecation warnings:
>>>
>>> 2006-07-01 18:25:31.767 wibble[2237] *** -[Protocol respondsToSelector:]:
>>> warning: Object compatibility method has been executed at least once.
>>> Convert source code off it NOW!
>>
>> That's because -respondsToSelector: isn't an Object method, but
>> Foundation adds an implementation for compatibility. If you use
>> Object's own -respondsTo: method instead, you won't get the warning.
>
> Fine, but if you're on the Apple runtime and you use the [object
> message] syntax, it is *going* to trigger a
> -respondsToSelector:@selector(message) message. So you have no choice
> but to send -respondsToSelector:, or give up on ObjC syntax and bang the
> runtime.

This is not the case in my testing. I'm assuming you're trying to say that
it will trigger such a message once, rather than saying it will trigger it
every time (which is completely ridiculous), but sending a supported
message to a Protocol, such as -hash, does not trigger any warnings of any
kind under Mac OS X 10.4.7.

--
Michael Ash
Rogue Amoeba Software

Sherm Pendley wrote:
> That's all well and good, but it says *nothing* about why you'd base your
> replacement library on Object instead of making it compatible with Foundation
> and AppKit.
>

What I'm about to post is just a thought, but...

Objective-C could be a good choice for replacing regular C on memory or
space-constrained systems. I think there's a group of programmers are
trying to create a variant of GNUstep for the Zaurus line of PDAs.
That said, there are a lot of systems (I imagine, anyway) that don't
have as much memory or space to play with. It's possible that
Objective-C is useful in this situation, but the Foundation and Appkit
libraries themselves might be too big.

In a case like that, it might be useful to simply create a new library
that's more appropriate to the system. Although, as I write this, it
occurs to me that one could also basically create a subset of
Foundation and/or Appkit and remain compatible with any
Openstep-compliant system.

Erik

On 2/7/06 08:57, Erik wrote:
> Sherm Pendley wrote:
>> That's all well and good, but it says *nothing* about why you'd base your
>> replacement library on Object instead of making it compatible with Foundation
>> and AppKit.
>>
>
> What I'm about to post is just a thought, but...
>
> Objective-C could be a good choice for replacing regular C on memory or
> space-constrained systems.

How so? You go from needing a C library to needing a C library *and* an
Objective-C runtime; surely a static language such as (though it pains
me to say it) eC++ would be better here.