Properties and objc1

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Properties and objc1

Bertrand Dekoninck
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_ {
   [defaultbuttoncell_ retain];
   [defaultbuttoncell release];
   defaultbuttoncell = defaultbuttoncell_;
}

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_;
   }


Thanks,

Bertrand

Is this correct ?



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

David Chisnall-7
On 17 Aug 2018, at 11:06, Bertrand Dekoninck <[hidden email]> wrote:
>
> 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.

A couple of things about this:

1. I think that libobjc2 should work on PowerPC, only without support for the assembly paths.  You won’t be able to use objc_msgSend (and the compiler will use the slower message sending mechanism) or imp_implementationWithBlock, but everything else should work.

2. If libobjc2 doesn’t work, you don’t actually need it to be able to use declared properties.  Clang (and, I think, gcc 4.6ish or later) will generate calls to runtime functions.  These are supported in either a vaguely recent GCC runtime or by the ObjectiveC2 compatibility framework that GNUstep builds as part of Foundation.

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

Ivan Vučica-2
In reply to this post by Bertrand Dekoninck
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
<[hidden email]> 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.

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

David Chisnall-7
On 17 Aug 2018, at 14:58, Ivan Vučica <[hidden email]> wrote:
>
> 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.

Exactly right.  Class property metadata and property metadata for properties declared in categories work only with -fobjc-runtime=gnustep-2.0 (or, in theory, later), instance property metadata on properties declared in classes works only with -fobjc-runtime=gnustep-1.something (I forget which, with 1.7 or later we get better metadata)

Methods synthesised from properties should work with any runtime.

David


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

Bertrand Dekoninck
In reply to this post by Ivan Vučica-2


Le 17/08/2018 à 15:58, Ivan Vučica a écrit :

> 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.
It helps me to understand more things. Thanks.

>
> On Fri, Aug 17, 2018 at 11:09 AM Bertrand Dekoninck
> <[hidden email]> 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!)
I did notice that by myself  : I would have named the variable
defaultButtonCell if it wasnt already named as is. That's why I named
the setter  setdefaultbuttoncell and didn't think to your solution.
>
> 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.
  KVC/KVO ? I don't know anything about this. I should dig a little. In
fact, yesterday, I didn't know what properties were doing and I'm
leveling my skills a little up now. So you can understand this part of
your comment is completely obscure to me. Don't matter.

>
>>     [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;
I found explanations about properties at
https://www.quora.com/How-are-atomic-properties-implemented-in-ObjC?share=1 
and I followed the notation.

>
> (3) Finally I'd add a small check:
>    if (self->defaultbuttoncell == defaultbuttoncell_)
>      return;
What for ? To escape without the 3 lines that follow if true ?

>
>
> 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.
I've read a little more on atomic/non atomic attributes and was
wondering if atomic is anything useful for a theme : should it be
threadsafe ? If so, should I use @synchronize ? and would it be
available without libobjc2 and libdispatch ?

Anyway, the whole discussion is now useless if gcc supports properties.

>
>>
>> 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.

Thanks a lot for this review.

Bertrand

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

Bertrand Dekoninck
In reply to this post by David Chisnall-7
Hi,


Le 17/08/2018 à 15:15, David Chisnall a écrit :
> On 17 Aug 2018, at 11:06, Bertrand Dekoninck <[hidden email]> wrote:
>> 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.
> A couple of things about this:
>
> 1. I think that libobjc2 should work on PowerPC, only without support for the assembly paths.  You won’t be able to use objc_msgSend (and the compiler will use the slower message sending mechanism) or imp_implementationWithBlock, but everything else should work.

I've read again your comment on the issue
<https://github.com/gnustep/libobjc2/issues/65> I had opened on github
for this. I hadn't understood that libobjc2 should work. So it is pretty
good news for me. Anyway, when I will have time, I may bend over the
remaining  pthread bug you mentionned when closing the issue.

>
> 2. If libobjc2 doesn’t work, you don’t actually need it to be able to use declared properties.  Clang (and, I think, gcc 4.6ish or later) will generate calls to runtime functions.  These are supported in either a vaguely recent GCC runtime or by the ObjectiveC2 compatibility framework that GNUstep builds as part of Foundation.
Good ! And is the dot syntax (eg someButton.reverse = reverse) also
supported ?

Anyway, I tried to build the theme today in a virtual machine with
debian 9 (x86) and gnustep debian packages (which are build with gcc). I
haven''t  yet checked that properties are supported because the build
fails badly  on this :

- (void)setIsDefaultButton:(NSNumber*) val
{
   objc_setAssociatedObject(self, kRikIsDefaultButton, val,
OBJC_ASSOCIATION_COPY);
}

I didn't even know what associated objects are and it need time to
understand them. And maybe to replace them. But it seems overkill tome


Thanks a lot.
Bertrand

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

Riccardo Mottola-5
In reply to this post by Bertrand Dekoninck
Hi,

Ivan explained it already to you, although some matter of taste remains.

I have converted a lot of obj-c2 code a couple of years ago and got
quick about it.


I do not like using _ in variable names except in private ivars


On 08/17/18 12:06, Bertrand Dekoninck 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.

Fine idea. libobjc2 has issues with gcc, since I cannot use libobjc2
with gnu-gnu-gnu but only with ng-gnu-gnu both with clang and gcc. I was
unable to write the testcases David requested and did not pursue that
further, I'll ping him again.

As long as you don't have blocks it is quite an easy but tedious
rewrite. That's what properties were probably invented for, but their
syntax is so ugly I can't stand them.

>
> For now, I'm dealing with properties.
>
> I've managed to convert this one :
>
> @property (retain) NSButtonCell * defaultbuttoncell;
>
> into :
>
> - (NSButtonCell *) defautbuttoncell {
>   return defaultbuttoncell;
> }

that is fine. I'm with ivan for naming it defaultButtonCell and if that
is taken understand why you need two.
>
> - (void) setdefaultbuttoncell: (NSButtonCell *) defaultbuttoncell_ {
>   [defaultbuttoncell_ retain];
>   [defaultbuttoncell release];
>   defaultbuttoncell = defaultbuttoncell_;
> }

I would write this differently, just for taste:


- (void) setdefaultbuttoncell: (NSButtonCell *) aButtCell {
   if (defaultbuttoncell != aButtCell)
    {
     [defaultbuttoncell release];
     defaultbuttoncell = aButtCell;
     [defaultbuttoncell retain];
}
}

I like it that way because it is clear that you "release" and "retain"
the IVAR.
since you do not want to release the same object you are assigning to,
you check it is really a different one. This is important! otherwise you
would release it before assigning and retaining it!
I learned it the hard way tracking strange crashes...



>
> 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_;
>   }

except for BOOL and Bool, it is correct. Avoiding _ applies too.


Happy hacking,

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Properties and objc1

Bertrand Dekoninck

> Le 17 août 2018 à 21:44, Riccardo Mottola <[hidden email]> a écrit :
>>



>> - (void) setReverse: (Bool) reverse_ {
>>   reverse = reverse_;
>>   }
>
> except for BOOL and Bool, it is correct. Avoiding _ applies too.
>

I kinda like the « aReverse » naming scheme. :-)

Bertrand
_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep