[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ObjectiveC accessors

From: Marcel Weiher
Subject: Re: ObjectiveC accessors
Date: Tue, 1 Jun 2004 23:01:18 +0100

Looks good enough :-)

No, it is not good enough :-)

Sure it is :-)

However, I still need to write @interface method entries for both, getter and setter,
idAccessor_h( var, setVar ) ? Or maybe: RACCESSORS_H( id , var, setVar )?

If I have to use that I'll stay with the standard way - no macros.

Yes, I frequently do that as well, because the interface should be more of a conscious decision.

I mean, why to write "I want to have thi variable accessible" three times? Like:

1. I want to have this variable
2. I will access this variable
3. I do access this variable like this
4. repeat from 1. for all variables

Where I can just write:

1. I want to have this variable and have it accessible
2. repeat from 1. for all variables.

Because they are quite different, and actually doing that would defeat part of the purpose of accessors.

The point of accessors is to make the interface of an object be message-based. It should not matter wether the messages that form the interface are connected to instance variables (simple accessors) or not.

If you add a tag to the instance variable to have all these accessors, you are tying the messaging interface to the instance variable declarations. And it gets even worse if you tie implementation to the interface. If you are going to do that, you could just as well make the instance variables public and access them directly.

so I have to write it in: ivar list, @interface method list, and @implementaion.
you forgot:
  - dealloc method
  - archiving/unarchiving
  - copying

That's another story.

Why?  It is just as boilperplate.

However, it would be good if the common patterns issue was solved. Either at the language level (not very nice) or by som higher level development tool...

There are various simple tools for generating the accessors. IIRC, some are even built into XCode. And you can probably easily tweak them to generate accessors.

And this is what I would like to avoid: to write single pattern on three places.
Seven places ;-)

Of course. :-) I have not mentionet the others, because they are more complicated to autogenerate, as there is higher probability of customisation.

There is?

 Where accessors are usualy still the same.

Hmm...there seems to be quite a large degree of disagreement as to how accessors should look. Also, I should repeat, the point of accessors is that how they are actually implemented is hidden, so the implementation can change without the interface changing. If this is tied to the instance variable declaration, then you lose this effect and might as well get rid of accessors.

On the other hand, something like the way a header-file declaration works is pretty fundamental to how C works, and having stuff that automagically appears in both seems well outside the scope of C and a little extension.

Yes, extension to the ObjectiveC language.

No.  Objective-C being a little extension to the C language.

Speaking about retain/release being OpenStep specific. Why not to include some kind of garbage collection into the language too?
GC and C semantics are incompatible at a fundamental level. That doesn't mean you can't have GC at an application level, but doing it safely at the language level seems impossible. Also, memory allocation isn't really at the language level, but at the library level.

I know, but why should not be GC at the language level? I do not say that it shold be or not, but why not?

This has been discussed at length (many times over): Objective-C is C, and you can't have GC at the language level in C.

It is used in majority of sources. Of course, with appropriate library hooks/callbacks, so one can implement custom GC method. I think it can be done in some simple way.
At an application-specific level, yes, just add Boehm's conservative GC. At a general library/language level: not a good idea, and not really possible while preserving existing language semantics.

Why to preserve existing language semantics? :-)

Because Objective-C is a *tiny* extension of C.

Complete backward compatibility is good, but only to certain point. Maybe I am speaking about different language, something [not-yet] derived from ObejctiveC...

Precisely. Just use Smalltalk, possibly backed by / hooked up to the Objective-C runtime. I've heard there's something like that available for GNUstep ;-)


Marcel Weiher                           Metaobject Software Technologies
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]