Re: ObjectiveC accessors

[Stefan Urbanek]

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