discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Properties and objc1


From: Ivan Vučica
Subject: Re: Properties and objc1
Date: Fri, 17 Aug 2018 14:58:22 +0100

Hey,

just some random thoughts regarding what I'd ask of a contributor to a
project I'd be writing.

This is in addition to David's comment: I would *expect* @property and
@synthesize to work to the extent you need them to even without
runtime support. David can correct me, but situation, I believe,
changes only if you want to query the runtime for which *properties*
exist and with which attributes, instead of just querying which
methods exist. I believe this means GNUstep's implementation of Core
Animation APIs can't be fully featured without libobjc2, because it
can't construct @dynamic properties without knowing that a property is
@dynamic. Of course, I need to finish the @dynamic support :-)

I hope what follows helps a bit.

On Fri, Aug 17, 2018 at 11:09 AM Bertrand Dekoninck
<bertrand.dekoninck@gmail.com> wrote:
>
> Hi everyone on the list.
>
> I'm enjoying my summertime to do some gnustep stuff. I want to convert
> the rik.theme to objc1 because I can't have libobjc2 running on my ppc
> computers.
>
> For now, I'm dealing with properties.
>
> I've managed to convert this one :
>
> @property (retain) NSButtonCell * defaultbuttoncell;
>
> into :
>
> - (NSButtonCell *) defautbuttoncell {
>    return defaultbuttoncell;
> }
>
> - (void) setdefaultbuttoncell: (NSButtonCell *) defaultbuttoncell_ {

That should be "setDefaultbuttoncell". (This shows why it's a good
idea to camelcase your variables; "defaultButtonCell" would result in
"setDefaultButtonCell:". Assuming you can do that in the theme!)

Naming this correctly helps KVC/KVO work correctly. I *think* you *do
not* need to notify KVO of the change in value. If it turns out you
do, just call "willChangeValueForKey:" and "didChangeValueForKey:"
(iirc) manually.

>
>    [defaultbuttoncell_ retain];
>    [defaultbuttoncell release];
>    defaultbuttoncell = defaultbuttoncell_;
> }


(1)
I like to use "self->" to make it clear that I'm referring to an ivar.
So [defaultbuttoncell_ retain]; [self->defaultbuttoncell release];
self->defaultbuttoncell = defaultbuttoncell_;.

(2)
Tendency for the past few years seems to be to use ivars named
"_propertyname". (While @synthesize will default to naming the ivar
the same, so "propertyname", if you omit @synthesize and the ivar
completely on modern Clang, it'll use "_propertyname" by default.)
So:
{
  NSButtonCell * _defaultbuttoncell;
}
@property (retain) NSButtonCell * defaultbuttoncell;
...
@synthesize defaultbuttoncell=_defaultbuttoncell;


(3) Finally I'd add a small check:
  if (self->defaultbuttoncell == defaultbuttoncell_)
    return;


So this is what it'd look like (assuming you can apply all these in a theme):

@interface Whatever
{
  NSButtonCell * _defaultButtonCell;
}
- (NSButtonCell *) defaultButtonCell;
- (void) setDefaultButtonCell: (NSButtonCell *) defaultButtonCell;
@end

@implementation Whatever
- (NSButtonCell *) defaultButtonCell
{
  return self->_defaultButtonCell;
}

- (void) setDefaultButtonCell: (NSButtonCell *) defaultButtonCell
{
  if (defaultButtonCell == self->_defaultButtonCell)
    return;

  [defaultButtonCell retain];
  [self->_defaultButtonCell release];
  self->_defaultButtonCell = defaultButtonCell;
}
@end

This seems clear and readable to me, if you are attempting to avoid
@synthesize. But, I might be embarrassing myself by missing something
obvious.

>
>
> And I  want to be sure for this one because of the non atomic and assign
> attributes :
>
> @property (nonatomic, assign) BOOL reverse;
>
> is replaced by :
>
> - (BOOL) reverse {
>    return reverse;
> }
> - (void) setReverse: (Bool) reverse_ {
>    reverse = reverse_;
>    }


This seems ok, except:
(1) s/Bool/BOOL/
(2) I'd still name the ivar "_reverse", the argument "reverse", and
use "self->" to make it clear I refer to the ivar.



reply via email to

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