[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ObjectiveC accessors
From: |
Stefan Urbanek |
Subject: |
Re: ObjectiveC accessors |
Date: |
Tue, 01 Jun 2004 22:57:46 +0200 |
On 2004-05-31 11:59:31 +0200 Marcel Weiher <address@hidden> wrote:
and apply it as:
RACCESSORS(NSString *, rootObjectNames, RootObjectNames)
RACCESSORS(NSArray *, prototypes, Prototypes);
RACCESSORS(NSDictionary *, objects, Objects);
Looks good enough :-)
No, it is not good enough :-)
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. 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.
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. 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...
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.
Where accessors are usualy still the same.
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.
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?
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? :-) Complete backward
compatibility is good, but only to certain point. Maybe I am speaking about
different language, something [not-yet] derived from ObejctiveC...
Stefan Urbanek
--
http://stefan.agentfarms.net
First they ignore you, then they laugh at you, then they fight you, then you
win.
- Mahatma Gandhi