macOS Out of scope variables - please Help....

[Fajhetti]

I have this little bit of code that where i am trying to check to see if there is a duplicate file name, but may have a different path. Meaning two files named the same thing but reside in a different location on their hard drive were added into my application. Now when I am checking for those things the inside loop seems to have variables out of scope and not checking them correctly.

In sample code there is a Category that has a NSMutableArray of a class called Pictures. Pictures has FileName and FullPath on it.

for ( Category * info in [CategoriesController arrangedObjects])
	{
		for (PictureInfo * pictureOne in [info Pictures])
		{
			NSString * fileName = pictureOne.FileName;
			NSString * fullPath = pictureOne.FullPath;
			for (PictureInfo * pictureTwo in [info Pictures])
				if (pictureTwo.FileName == fileName && pictureTwo.FullPath != fullPath)
					[validationitems addObject:[ValidationItem InitWithValues:	[NSString stringWithFormat:@"It appears you have multiple images in Category %@ that has the same name of %@.  This will very difficult for your customer to relay the correct image when ordering proofs.  Please rectify and resubmit.",info.Description, pictureTwo.FileName] button:button]];
		}
	}

 

[chown33]

Exactly which variables are out of scope?

What is the error message? Copy and paste it.

 

[lee1210]

I'll get this out of the way first:
i hate the dot syntax for accessors.

Now that that's out of the way...
you can't compare NSStrings, char *s, etc. with ==. As such,:

pictureTwo.FileName == fileName && pictureTwo.FullPath != fullPath

is going to go badly for you. I assume those are NSStrings, and if so you should use isEqualToString: to compare them instead of ==. If for some odd reason they are char *s, you can use strcmp to compare them.

-Lee

 

[Fajhetti]

Thanks lee1210.

I realized that I was comparing wrong after chown133's post and that was the problem. Then I was back to explain my stupidity when i saw your post. Too much switching between C#.NET and x-code. We have an app written in both and I am not as fluent in x-code.

Thanks and sorry for wasting everyones time.

 

[HiRez]

Going a little off-track, I don't hate the dot-sytax for accessors because I think it is easier to follow a deep path. For example aPlayer.team.league.leagueName is a lot easier to read (and type or modify) for me than [[[aPlayer team] league] leagueName]. For one thing I don't have to try to anticipate in advance how many opening brackets I'm going to need, or go back later to correct them. What I don't like is that they only went half way with it. You can't use the dot-syntax to call methods. Dot-syntax is also used for KVM and Bindings paths, so you end up using it a lot anyway. Personal preference and I understand why Cocoa purists could dislike it.

 

[lee1210]

haha! Someone took the bait! =)

My major beef (i certainly don't consider myself an Objective-C or Cocoa purist) is "overloading" what the . means in C. This has obviously been discussed before, i just try to be a pain in the ass every time i see it being used. When I see a dot, i expect that to be getting a field from a local struct or union. Pointers have -> applied to them. Except now, maybe that thing is an object pointer, but you can . it. Why can't i just . a struct pointer, then? I just feel that other additions made to Objective-C kept the original C syntax and its meaning intact, which made it very clear when the Objective part was kicking in, and when you were reading C.

To each his own, obviously digging deep into the properties of a number of objects isn't going to be a very good time... but i guess i'm not that picky about writing getLeagueName on player, typing the [[[[ once when defining that method, then invoking getLeagueName in all of the other places you need it. You then also get the benefit of only having to change one thing if leagues split into divisions, instead of all of the places in the code that you had referencing aPlayer.team.league.leagueName to aPlayer.team.division.league.leagueName.

-Lee

 

[kainjow]

You can't use the dot-syntax to call methods.

You can, but only if the method doesn't take any arguments. For example, this compiles:

NSAutoreleasePool *pool = NSAutoreleasePool.alloc;
pool.init;

NSString *str = @"/Applications/Utilities/Console.app";
str.retain;
str = str.stringByDeletingLastPathComponent;
str.release;

NSMutableDictionary *dict = NSMutableDictionary.dictionary;

pool.drain;

 

[GorillaPaws]

You can, but only if the method doesn't take any arguments. For example, this compiles:

It is my understanding that even though it compiles it's still considered incorrect. The 2.0 dot syntax is only supposed to be used for accessing properties and not for general message sending.

Would it have been possible for Apple to choose the "•" symbol for property dot-syntax and kept the "." exclusively for c-structs? I'm with Lee on disliking how the dot syntax creates ambiguity in the language.

"aPlayer•team•league•leagueName" looks ok to me, has the same advantages of the dot-syntax and remains visually distinct from c-structs. Sorry for taking this even further OT.

 

[jared_kipe]

"aPlayer•team•league•leagueName" looks ok to me, has the same advantages of the dot-syntax and remains visually distinct from c-structs. Sorry for taking this even further OT.

Well for one there isn't a • on my keyboard.
And • is UTF8: E2 80 A2, vs . is UTF: 2E Meaning that • is 3 bytes wide so wouldn't necessarily play fair in a non-unicode environment. Unless you want to get used to seeing "aPlayer,.¢team,.¢league,.¢leagueName"

 

[Catfish_Man]

You can, but only if the method doesn't take any arguments. For example, this compiles:

NSAutoreleasePool *pool = NSAutoreleasePool.alloc;
pool.init;

NSString *str = @"/Applications/Utilities/Console.app";
str.retain;
str = str.stringByDeletingLastPathComponent;
str.release;

NSMutableDictionary *dict = NSMutableDictionary.dictionary;

pool.drain;

Yes, but every time you do that, a puppy dies. Keep it for accessors (and preferably, keep it for accessors that are conceptually* "pure accessors". That way you know that [foo bar] indicates something with side effects).


*I say conceptually because a lot of "pure" accessors actually do caching behind the scenes. This isn't part of their interface and shouldn't impact coding style related to them.

 

[GorillaPaws]

Well for one there isn't a • on my keyboard.

I get • with an "option + 8" on my keyboard, about the same amount of work it takes to generate an * which is "shift +8." Or are you referring to the fact that it's not labeled on the the keyboard itself? Which could be solved by putting a small dot of whiteout (or glow-in-the-dark paint for backlit-keyboards) next to our *'s on the 8 key (I'm kidding).

Unless you want to get used to seeing "aPlayer,.¢team,.¢league,.¢leagueName"

I think I would prefer that to the current implementation .

But in all seriousness, I'm a bit confused as to why non-unicode environments would be an issue if we're talking about Objective-C 2.0 syntax since we're all using Xcode. I think there must be something I'm missing (like how the compiler interprets characters or something else beyond my current understanding).

 

[jared_kipe]

But in all seriousness, I'm a bit confused as to why non-unicode environments would be an issue if we're talking about Objective-C 2.0 syntax since we're all using Xcode. I think there must be something I'm missing (like how the compiler interprets characters or something else beyond my current understanding).

Kinda like how I'm programming away and all a sudden a string literal that should be (??) turns into (]
http://en.wikipedia.org/wiki/Digraphs_and_trigraphs
Why do we still have digraphs and trigraphs in modern C derivatives? Because someone thinks removing them from modern C languages will break some legacy code somewhere written on an archaic keyboard?

Ironically Digraphs and Trigraphs came along because some people's keyboards didn't have certain characters on them.

 

[GorillaPaws]

Kinda like how I'm programming away and all a sudden a string literal that should be (??) turns into (]
http://en.wikipedia.org/wiki/Digraphs_and_trigraphs

Thanks for the reference.

 

[lee1210]

Kinda like how I'm programming away and all a sudden a string literal that should be (??) turns into (]
http://en.wikipedia.org/wiki/Digraphs_and_trigraphs
Why do we still have digraphs and trigraphs in modern C derivatives? Because someone thinks removing them from modern C languages will break some legacy code somewhere written on an archaic keyboard?

Ironically Digraphs and Trigraphs came along because some people's keyboards didn't have certain characters on them.

Man, it's been 5 months. Those trigraphs didn't mean to do you so dirty.
https://forums.macrumors.com/threads/711139/

=)
-Lee