Accessing members from NSDictionary
I have a situation where a user might have a great many information windows
open at the same time (like the situation in Finder where you can click on a
file and select 'Get Info' ad infinitum.)
In order handle this situation, and so that I can still update each Window
individually, I decided to store the information window classes in an
NSDictionary so that I can fiddle with them individually (and release them
individually, obviously).
This seems to work quite well - except that I can't seem to access public
member variables. The following code gives the error 'No member named
'infoWindow' in 'struct objc_object'
NSEnumerator *e = [connectedDevices objectEnumerator];
id device;
while (device = [e nextObject])
{
if ([[device objectForKey:@LocationID] isEqualToNumber:[sender
representedObject]])
{
[device setObject:[[DisplayInformation alloc]
initWithDictionary:device] forKey:@InformationWindowRef];
[[device objectForKey:@InformationWindowRef] showWindow:self];
Error Here ---[[device objectForKey:@InformationWindowRef]-infoWindow
cascadeTopLeftFromPoint:NSMakePoint(20,20)];
}
}
So I have a few questions:
1. Am I approaching this problem correctly? After all, just because something
(mostly) works, it doesn't mean that it is the right, or efficient, way to do
things.
2. If my plan isn't utter lunacy, how do I get to the member variable?
3. If my plan is lunacy, or if there's a better more efficient solution, what
is it?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
On 5 Apr 2013, at 13:38, Pax wrote:
I have a situation where a user might have a great many information windows
open at the same time (like the situation in Finder where you can click on a
file and select 'Get Info' ad infinitum.)
In order handle this situation, and so that I can still update each Window
individually, I decided to store the information window classes in an
NSDictionary so that I can fiddle with them individually (and release them
individually, obviously).
This seems to work quite well - except that I can't seem to access public
member variables. The following code gives the error 'No member named
'infoWindow' in 'struct objc_object'
NSEnumerator *e = [connectedDevices objectEnumerator];
id device;
while (device = [e nextObject])
{
if ([[device objectForKey:@LocationID] isEqualToNumber:[sender
representedObject]])
{
[device setObject:[[DisplayInformation alloc]
initWithDictionary:device] forKey:@InformationWindowRef];
[[device objectForKey:@InformationWindowRef] showWindow:self];
Error Here ---[[device objectForKey:@InformationWindowRef]-infoWindow
cascadeTopLeftFromPoint:NSMakePoint(20,20)];
}
}
So I have a few questions:
1. Am I approaching this problem correctly? After all, just because
something (mostly) works, it doesn't mean that it is the right, or efficient,
way to do things.
2. If my plan isn't utter lunacy, how do I get to the member variable?
3. If my plan is lunacy, or if there's a better more efficient solution, what
is it?
For a start, trying to access instance variables directly is almost always a
bad idea. Expose proper accessor methods instead.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
On 5 Apr 2013, at 14:20, Mike Abdullah cocoa...@mikeabdullah.net wrote: For a start, trying to access instance variables directly is almost always a bad idea. Expose proper accessor methods instead. Why is it a bad idea? I do this quite often, and I find it has the double benefit of improving readability and reducing the number of lines of code. But if it's bad then I shall look to mend my ways - but I'll need to understand the badness first! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
On 5 Apr 2013, at 14:55, Pax 45rpmli...@googlemail.com wrote:
On 5 Apr 2013, at 14:20, Mike Abdullah cocoa...@mikeabdullah.net wrote:
For a start, trying to access instance variables directly is almost always a
bad idea. Expose proper accessor methods instead.
Why is it a bad idea? I do this quite often, and I find it has the double
benefit of improving readability and reducing the number of lines of code.
But if it's bad then I shall look to mend my ways - but I'll need to
understand the badness first!
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the class
with the ivar, without also changing the implementation of the other class now.
I don't really understand your argument about lines of code or readability, you
would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
Ah, I see. I shall try that out. And, referring to my earlier question, would
I be able to:
[[device objectForKey:@InformationWindowRef].infoWindow
cascadeTopLeftFromPoint:NSMakePoint(20,20)];
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;' an
IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
1) yes you could use the code you outlined to access the property
2) @property (assign, nonatomic) IBOutlet NSWindow *iWindow;
Note though to be careful about the assign tag there – you may well want that
to be a retain.
Thanks
Tom Davie
On 5 Apr 2013, at 15:06, Pax 45rpmli...@googlemail.com wrote:
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;' an
IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two strongly
coupled components of code. You can not change the implementation of the
class with the ivar, without also changing the implementation of the other
class now.
I don't really understand your argument about lines of code or readability,
you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
I never retain IBOutlet properties. The view retains the object when it is
added, so also retaining the property would increase the retain count to 2.
I have not encountered a condition where I was required to access an
IBOutlet property after the view had been unloaded, so this approach has
worked well for me. My foggy memory tells me this is (or was) best
practice, but I'm just too lazy to look it up right now. YMMV.
Regards,
-jwd
// Joseph W. Dixon
On Fri, Apr 5, 2013 at 9:18 AM, Tom Davie tom.da...@gmail.com wrote:
1) yes you could use the code you outlined to access the property
2) @property (assign, nonatomic) IBOutlet NSWindow *iWindow;
Note though to be careful about the assign tag there – you may well want
that to be a retain.
Thanks
Tom Davie
On 5 Apr 2013, at 15:06, Pax 45rpmli...@googlemail.com wrote:
…And how would I make '@property (assign, nonatomic) NSWindow* iWindow;'
an IBOutlet so that I can hook it up to my window in interface builder?
On 5 Apr 2013, at 15:00, Tom Davie tom.da...@gmail.com wrote:
The reason it's a bad idea is because it means that you have two
strongly coupled components of code. You can not change the implementation
of the class with the ivar, without also changing the implementation of the
other class now.
I don't really understand your argument about lines of code or
readability, you would be replacing
someObject-someIvar = 56.9f;
with
someObject.someProperty = 56.9f;
and
{
float someIvar;
}
with
@property (assign, nonatomic) float someProperty;
So neither is really true.
Thanks
Tom Davie
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/spam%40dixondata.com
This email sent to s...@dixondata.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
On 5 Apr 2013, at 16:54, Joseph Dixon s...@dixondata.com wrote: I never retain IBOutlet properties. The view retains the object when it is added, so also retaining the property would increase the retain count to 2. This assumes that the property you're talking about is a view, and that it's a subview of another view that's retained. The issue isn't quite as simple as never retain IBOutlets. Thanks Tom Davie ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
On Fri, Apr 5, 2013 at 10:55 AM, Tom Davie tom.da...@gmail.com wrote: This assumes that the property you're talking about is a view, and that it's a subview of another view that's retained. The issue isn't quite as simple as never retain IBOutlets. Tom, You are right, of course. Most issues cannot be covered by hard and fast rules, and I have no intention of creating doctrine. In my experience using assign/weak references to IBOutlet properties has worked well. Yes, my IBOutlets are always pointing to subviews that are retained. Perhaps that makes my code .. quaint. -jwd // Joseph W. Dixon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Accessing members from NSDictionary
On Apr 5, 2013, at 7:03 AM, Pax 45rpmli...@googlemail.com wrote: Ah, I see. I shall try that out. And, referring to my earlier question, would I be able to: [[device objectForKey:@InformationWindowRef].infoWindow cascadeTopLeftFromPoint:NSMakePoint(20,20)]; No, because -objectForKey: returns type id, i.e. a generic untyped object reference, but “.” syntax is strongly typed so it requires that the left-hand-side be an actual class that defines that property. Your choices are: [[device objectForKey:@InformationWindowRef”] infoWindow] ... or InfoWindowRef *ref = [[device objectForKey:@InformationWindowRef”]; ref.infoWindow ... —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
