[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ObjectiveC accessors
Re: ObjectiveC accessors
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,
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
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
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
- dealloc method
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
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
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
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
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.