|
Toady posted:-isEqual: takes an id and implies the possibility of comparing to non-strings. The method probably calls -isEqualToString: when passed a string, or calls the same internal functionality. In Cocotron, for example, both methods end up calling the inline function isEqualString(). -isEqual: must first do a class lookup, and if by construction your code will only ever compare strings, you can skip that check. Reasons for using the class-specific equality methods include faster performance, better expression of intent, and static type checking of the argument. Alright, so maybe I'm just not getting it, but why does calling [aString isEqualToString:someArray] not throw an exception? By your logic it should be a programmer error, right? Or it should blow up on some internal call to a string comparison function, or somehow not work. When in reality it simply returns NO. (Also, did you miss the part where I countered your claims of "better expression of intent" or "faster performance" (see above question), or am I being so stupid that you'll simply repeat the same line until I get it?)
|
#
?
Sep 22, 2011 23:26
|
|
|
|
| # ? May 15, 2024 12:15 |
|
|
pokeyman posted:Alright, so maybe I'm just not getting it, but why does calling [aString isEqualToString:someArray] not throw an exception? By your logic it should be a programmer error, right? Or it should blow up on some internal call to a string comparison function, or somehow not work. When in reality it simply returns NO. I don't know the details of Apple's implementation or the source of the claimed performance improvement. That's why I used Cocotron as an example. Since the framework has knowledge of its internals, there's no telling what sanity checks it might employ for cases like this. In any event, the compiler will warn you if you explicitly pass a non-string argument. The expression of intent is in the declaration that you will only be dealing with strings, and the faster performance claimed by Apple may or may not be related to the fact that the framework can assume it's comparing to a string. There's no practical reason that I can think of not to use this method for comparing strings.
|
|
#
?
Sep 23, 2011 06:16
|
|
|
Just a quick question and maybe to stir up a debate, but is there a difference between using YES/NO, TRUE/FALSE and true/false?
|
|
#
?
Sep 23, 2011 08:22
|
|
|
Sir Davey posted:Just a quick question and maybe to stir up a debate, but is there a difference between using YES/NO, TRUE/FALSE and true/false? No.
|
|
#
?
Sep 23, 2011 08:37
|
|
|
I've started using YES/NO because it's shorter to type and fits the readability more.
|
|
#
?
Sep 23, 2011 14:56
|
|
|
Apple's convention seems to be YES/NO so I just go with that.
|
|
#
?
Sep 23, 2011 16:01
|
|
|
CAT ON THE COUCH!! posted:Let me clarify the problem: What's "subscriberDetailsXML"? Also I can't speak for the other people, but if you make a simple project that just consists of the issue it's easier for me to poke around at it. Otherwise I gotta do that myself and 
|
|
#
?
Sep 23, 2011 19:09
|
|
|
pokeyman posted:Alright, so maybe I'm just not getting it, but why does calling [aString isEqualToString:someArray] not throw an exception? By your logic it should be a programmer error, right? Or it should blow up on some internal call to a string comparison function, or somehow not work. When in reality it simply returns NO. You didn't counter his claim of "better expression of intent". If you think isEqual means the same thing as isEqualToString, even if they do the same thing, you're doing a pretty good job of arguing for the viewpoint that the Objective-C "type system" is a travesty.
|
|
#
?
Sep 24, 2011 00:19
|
|
|
My iPad game seems to have appeared on a couple of warez sites, but none of the titles or descriptions mention it being cracked at all, so I'm assuming my delayed anti-piracy measures are still in there  (You can play a couple of songs but then it starts missing notes and you'll eventually fail, and then you'll be prompted to buy it legitimately.)
|
|
#
?
Sep 24, 2011 08:37
|
|
|
Akuma posted:My iPad game seems to have appeared on a couple of warez sites, but none of the titles or descriptions mention it being cracked at all, so I'm assuming my delayed anti-piracy measures are still in there How are you detecting a pirated copy? I'm interested in implementing anti-piracy measures in my future apps but haven't found any useful information online.
|
|
#
?
Sep 24, 2011 17:08
|
|
|
I found some blog (forum?) post that was a compilation of a shitload of different methods, so I implemented a few of them and poll one of them randomly every time I check. I can't seem to find it now but when I'm back in the office on Monday I'll see if I can dig it up for you.
|
|
#
?
Sep 24, 2011 17:25
|
|
|
wellwhoopdedooo posted:You didn't counter his claim of "better expression of intent". If you think isEqual means the same thing as isEqualToString, even if they do the same thing, you're doing a pretty good job of arguing for the viewpoint that the Objective-C "type system" is a travesty. I didn't counter the claim because he's right: the two messages don't mean the same thing to either the compiler or the person reading the code. If you page back, the claim I disagreed with was quote:You use -isEqualToString: when you know both objects are strings. Which isn't an expression of intent ("these should be strings"), but an expression of presumed fact ("I think these are strings so I'm using this other method"). If you want them both to be strings, there's value in showing that intent using isEqualToString:, and getting a compiler warning or getting sent -doesNotRecognizeSelector: if you mess up. If you're already sure they're both strings, or if you don't care, there's no value in using one over the other. What's the argument for Objective-C's type system being a travesty?
|
|
#
?
Sep 26, 2011 08:23
|
|
|
nolen posted:How are you detecting a pirated copy? I'm interested in implementing anti-piracy measures in my future apps but haven't found any useful information online. I have absolutely no idea how they can tell this. There's absolutely no way, that I can see from the SDK documentation, that you can tell if something has been illigitimately downloaded. There are one or two threads over on iphonedevsdk about the issue, but their suggestions don't seem to work from feedback received. Funso Banjo fucked around with this message at 14:55 on Sep 26, 2011 |
|
#
?
Sep 26, 2011 14:39
|
|
|
I always figured you'd have to build a separate pirate build that's gimped in some way, then be the one to upload it to whatever pirate sites are out there. Seems a bit risky though - the chance of it backfiring with negative feedback seems pretty high.
|
|
#
?
Sep 26, 2011 16:08
|
|
|
Piracy is a difficult one if someone is determined but in reality most apps are pirated by script kiddies running a packaged cracker and they have no clue... So if you implement the various pirate checks but let the app run, just causing it to gently caress up here and there they most likely won't notice. They are typically just trying to download and crack as many apps as possible to ++ their e-peen. As far as I am aware since the legit Apple ecosystem is so standard and controlled there is an extremely low false-positive rate but YMMV.
|
|
#
?
Sep 26, 2011 18:49
|
|
|
Funso Banjo posted:I have absolutely no idea how they can tell this. You can do things like checking to see if the binary is encrypted, checking file modification times, exiting the app if it's a distribution build but a debugger is attached, etc. Nothing a knowledgeable person with a hex editor couldn't get around, but as Ender.uNF said, most are just script kiddies.
|
|
#
?
Sep 26, 2011 19:54
|
|
|
pokeyman posted:Which isn't an expression of intent ("these should be strings"), but an expression of presumed fact ("I think these are strings so I'm using this other method"). Those quotes seem flipped to me, but regardless, the method is an expression not just to the reader but also to the framework, allowing it to make assumptions that might improve performance. quote:If you want them both to be strings, there's value in showing that intent using isEqualToString:, and getting a compiler warning or getting sent -doesNotRecognizeSelector: if you mess up. If you're already sure they're both strings, or if you don't care, there's no value in using one over the other. This is untrue. -isEqualToString: is faster, statically typed, and self-documenting. It's not just an assertion statement.
|
|
#
?
Sep 26, 2011 20:33
|
|
|
Toady posted:This is untrue. -isEqualToString: is faster, statically typed, and self-documenting. It's not just an assertion statement. I made a little test thinger to verify that isEqualToString: actually is faster. By all means critique it, I'm sure I've done at least five stupid things here. Running the test a dozen times, I find that isEqualToString: is maybe a nanosecond (< 1%) faster than isEqual: when comparing two strings, and isEqual: is maybe 10% faster when comparing a string with a non-string. What do you find when you run it? If by "statically typed" you mean "gives compiler warning if an apparent non-string is passed in", I agree that there's non-zero value there. If you mean anything else, please explain. (Also, "self-documenting"? You're comparing the value of two objects. What's to document? You wouldn't write code:
|
|
#
?
Sep 27, 2011 03:13
|
|
|
pokeyman posted:
I think the self-documenting thing is when you're reading code and there's something like: [peopleArrayFirstValue isEqual:chosenListingsOfApartments[3]] vs [peopleArrayFirstValue isEqualToString:chosenListingsOfApartments[3]] where the second one gives you at least a better understanding of what the program is trying to do. Not really a matter of what you'd write, but what other people have to read.
|
|
#
?
Sep 27, 2011 04:44
|
|
|
I'm having an odd issue with UISegmentedControl... My structure looks something like this... - Controller's UIView -- UIImageView (This is a background bar for the segmented control) --- UISegmentedControl (Control with 3 items, added as a subview of the ImageVIew) -- UITableView -- UITableView -- UITableView The idea is that the table views hide/show depending on which SegmentedControl button is selected. This works... mostly... There is a weird issue I'm running into. If I tap any of the segment buttons, then attempt to drag the table (which is well below the segmented control), it "pops" the selected segmented control back to the first one, un-hiding the first table in the process. It only seems to occur on a tap+drag motion and tapping on a table row selects it just fine. I tried telling the segmented control to resignFirstResponder when the method bound to the UIControlEventValueChanged fires but to no avail. Anyone run into this?
|
|
#
?
Sep 27, 2011 05:59
|
|
|
WildFoxMedia posted:If I tap any of the segment buttons, then attempt to drag the table (which is well below the segmented control), it "pops" the selected segmented control back to the first one, un-hiding the first table in the process. It only seems to occur on a tap+drag motion and tapping on a table row selects it just fine. Without seeing any code (would be handy to reduce this to a simple test case), maybe the segmented control is still getting touchesMoved events after you think you've chosen a segment. When you then drag on the table, the segmented control finally gets a touchesEnded event, and since the end touch isn't on a segment, it cancels the whole thing. Is that possible?
|
|
#
?
Sep 27, 2011 06:18
|
|
|
WildFoxMedia posted:I'm having an odd issue with UISegmentedControl... This doesn't answer your specific issue, but from my personal experience I would recommend that you never have multiple table views in the same view, simply reload the table data using the new data source that you want to use.
|
|
#
?
Sep 27, 2011 06:47
|
|
|
pokeyman posted:Without seeing any code (would be handy to reduce this to a simple test case), maybe the segmented control is still getting touchesMoved events after you think you've chosen a segment. When you then drag on the table, the segmented control finally gets a touchesEnded event, and since the end touch isn't on a segment, it cancels the whole thing. Is that possible? I would imagine it certainly is possible, I don't know how/why touchesEnded wouldn't be triggered, but I'll mess around with it. false image posted:This doesn't answer your specific issue, but from my personal experience I would recommend that you never have multiple table views in the same view, simply reload the table data using the new data source that you want to use. I wasn't sure what best practices dictated in cases like that, but I will definitely switch it up.
|
|
#
?
Sep 27, 2011 08:04
|
|
|
I'm a loving derp... [modeControl setSelectedSegmentIndex:0]; in layoutSubviews...
|
|
#
?
Sep 27, 2011 08:25
|
|
|
pokeyman posted:I made a little test thinger to verify that isEqualToString: actually is faster. By all means critique it, I'm sure I've done at least five stupid things here. I'm going by Apple's documentation that the method is faster. I believe you that in your particular benchmark, the method is faster by a nanosecond. quote:If by "statically typed" you mean "gives compiler warning if an apparent non-string is passed in", I agree that there's non-zero value there. Correct, that is what is meant by static typing. quote:(Also, "self-documenting"? You're comparing the value of two objects. What's to document? You wouldn't write Does [userID isEqual:[array objectAtIndex:0]] compare to an NString, NSNumber, NSManagedObject, a custom class, or what? -isEqual: is a declaration that the program doesn't exclusively expect a certain type, but that could be untrue (in fact, you were recommending not being specific when the code expects a certain type). For that and other reasons, using generic equality checks when a program, by construction, is only supposed to be working with a certain type is smelly because it signals an unclearly written program and engenders possibly incorrect expectations in the reader. This is especially important if someone else is going to be maintaining your code--or you six months from now. You're also missing out on expressing intent to the framework, which may or may not be relevant in this case in terms of performance but is always something to take advantage of when a method is made available, due to the potential for specialized behavior in the future based on the framework's internal knowledge of its objects. Why use static typing at all? Why not type every object pointer, method argument, and return value as id? NeXTStep actually used to do that early on, but there is value in being able to warn that an object doesn't respond to a method before crashing at runtime. Apple has been moving in the direction of stronger checking and specificity over the years. Trying to access an undeclared property generates a compiler error rather than a warning, and Xcode 4.2 now warns for mismatched types between a pointer and an object returned from alloc/init (you had to explicitly cast the NSArray in your test code to avoid this). Objective-C's dynamism is an advantage in several situations but does not preclude specificity. My replies have specifically been to your claim that there is no value in using the class-specific method when it is known what class the objects are, but there is value. I don't understand your rationale for avoiding it.
|
|
#
?
Sep 27, 2011 09:58
|
|
|
Toady posted:Correct, that is what is meant by static typing. Right you are; I think I was confusing Objective-C's duck typing with its static typing. (Though I imagine it's debatable whether Objective-C uses duck typing, which could be at the very core of our argument.) quote:Does [userID isEqual:[array objectAtIndex:0]] compare to an NString, NSNumber, NSManagedObject, a custom class, or what? Do I care? Usually I don't, and when I do then I happily use isEqualToString: (though to be honest, it's usually because it comes up first in autocomplete). I was confident in my original recommendation because the guy honestly didn't seem to care, and it didn't seem important that he was comparing strings. In your example, if you did care that you were comparing to an NSManagedObject, how would you show that in your code? I don't see an isEqualToManagedObject: method that would be useful here, unless you defined your own. Is the omission of isEqualToManagedObject: an oversight, in your opinion? quote:-isEqual: is a declaration that the program doesn't exclusively expect a certain type, but that could be untrue (in fact, you were recommending not being specific when the code expects a certain type). For that and other reasons, using generic equality checks when a program, by construction, is only supposed to be working with a certain type is smelly because it signals an unclearly written program and engenders possibly incorrect expectations in the reader. I'm not sure I follow you here. Programs that expect a certain type declare that in their methods' parameter lists (or in their classes' properties; is there another static way in Objective-C code?), or maybe at runtime using e.g. assertions. Once your program has (or thinks it has) an instance of that certain type, I don't find greater clarity by drumming it in over and over. To me, it has the feeling of calling NSAssert([string isKindOfClass:[NSString class]]) every single time before sending the string a message. I know that's not what you're saying but it smells the same to me. quote:You're also missing out on expressing intent to the framework, which may or may not be relevant in this case in terms of performance but is always something to take advantage of when a method is made available, due to the potential for specialized behavior in the future based on the framework's internal knowledge of its objects. Don't subclasses of NSObject override isEqual: precisely with specialized behaviour based on the framework's internal knowledge of its objects? If Foundation's string comparison gets faster, NSString's overridden isEqual: can (and surely would) be switched to use that. quote:Why use static typing at all? Why not type every object pointer, method argument, and return value as id? NeXTStep actually used to do that early on, but there is value in being able to warn that an object doesn't respond to a method before crashing at runtime. Of course there's value in static typing, I'm not sure where you see me arguing for the elimination of static typing from Objective-C. I'm arguing that you're overemphasizing what value there is in using the isEqualTo<Type>: family of methods.
|
|
#
?
Sep 27, 2011 11:14
|
|
|
Wow.. quite a discussion about isEqualToString we've got going here. I'll check back to see if everyone finally comes to an agreement to what is, and what is not. Most of it is over my head to debate anything, but it is interesting. Is anyone familiar with Cocos2D for iOS, particularly passing parameters when calling methods with actions? I've done it with NSNumber and retaining the value and releasing it when the method is called, but I'm totally confused on how to go about doing this when passing a CGPoint. Just with guessing, this is what I currently have: code:code:edit: I just noticed I wouldn't even have to pass the spriteCoord, because I can always get the value from saveStation.sprite.position anywhere,  but I'm still curious on how to do this.
LP0 ON FIRE fucked around with this message at 19:12 on Sep 27, 2011 |
|
#
?
Sep 27, 2011 19:04
|
|
|
You're passing the address of a struct to a function that does not expect to receive a pointer to that struct.
|
|
#
?
Sep 27, 2011 19:52
|
|
|
Your method expects to receive the CGPoint by value, and instead you are passing it by reference. Also, it's on the stack so it goes away at the end of the function.
|
|
#
?
Sep 27, 2011 20:17
|
|
|
What do you guys think of Corona? edit: screw it Unity seems like the way to go. I'm interviewing for a game startup and they're asking me about Gamesalad/Corona/Unity and I'm kinda pushing Unity. The guy isn't a programmer so he's actually asking me questions about what I think is better and what I would like to work with. Also he said he heard Unity sucks for 2D games? mellowjournalism fucked around with this message at 22:15 on Sep 28, 2011 |
|
#
?
Sep 28, 2011 21:10
|
|
|
pokeyman posted:In your example, if you did care that you were comparing to an NSManagedObject, how would you show that in your code? I don't see an isEqualToManagedObject: method that would be useful here, unless you defined your own. Is the omission of isEqualToManagedObject: an oversight, in your opinion? I was responding to your recommendation to not use the method even when the objects are known to be strings. If the objects are always going to be strings by design, it's likely that the code is in some way dependent on them being strings. I don't consider the lack of an -isEqualToManagedObject: method to be an oversight (I think NSManagedObject equality is done by pointer anyway), but if there is no class-specific method, then it does make it more difficult to tell what types the code is expecting to work with, if any. The existence of a class-specific method is welcome. quote:Of course there's value in static typing, I'm not sure where you see me arguing for the elimination of static typing from Objective-C. I'm arguing that you're overemphasizing what value there is in using the isEqualTo<Type>: family of methods. I was responding to the statement that there was "no value." Type checking, self-documentation, and faster performance for using a slightly longer method name? I'll take that trade! 
|
|
#
?
Sep 28, 2011 22:04
|
|
|
yellowjournalism posted:What do you guys think of Corona? If you're wanting to do 2D, why aren't you looking at cocos2d?
|
|
#
?
Sep 28, 2011 22:31
|
|
|
Awesome, I'll take a look at it. Honestly this is all me scrambling to see what's out there because I'm doing an interview today, and they're asking me what kind of stuff I would like to work with.
|
|
#
?
Sep 28, 2011 22:37
|
|
|
Toady posted:I was responding to your recommendation to not use the method even when the objects are known to be strings. If the objects are always going to be strings by design, it's likely that the code is in some way dependent on them being strings. I don't consider the lack of an -isEqualToManagedObject: method to be an oversight (I think NSManagedObject equality is done by pointer anyway), but if there is no class-specific method, then it does make it more difficult to tell what types the code is expecting to work with, if any. The existence of a class-specific method is welcome. Not sure if NSManagedObject equality goes by pointers or not, though it appears to override isEqual: (quoth the docs: "Core Data relies on NSManagedObject’s implementation of the following methods, which you therefore absolutely must not override: ... isEqual: ..."). quote:I was responding to the statement that there was "no value." Type checking, self-documentation, and faster performance for using a slightly longer method name? I'll take that trade! I find it curious that the value you get out of isEqualToString: is greater than isEqual: but less than defining your own isEqualTo<Type>: methods. i.e. overridden isEqual: < isEqualToString: < defining isEqualTo<Type>: yourself If it's as valuable as you say to have a specialized method for equality, why not write them yourself? And again, it's not clear to me why isEqual: would be faster than isEqualToString: once the implementation of isEqual: figures out it's comparing two strings. Nor is it clear to me what self-documentation is going on.
|
|
#
?
Sep 28, 2011 23:50
|
|
|
yellowjournalism posted:Awesome, I'll take a look at it. Honestly this is all me scrambling to see what's out there because I'm doing an interview today, and they're asking me what kind of stuff I would like to work with. Yes, use Cocos2D for 2D games.
|
|
#
?
Sep 29, 2011 02:10
|
|
|
pokeyman posted:Not sure if NSManagedObject equality goes by pointers or not, though it appears to override isEqual: (quoth the docs: "Core Data relies on NSManagedObject’s implementation of the following methods, which you therefore absolutely must not override: ... isEqual: ..."). I don't know if it does or not, but the default implementation of -isEqual: compares pointers, which makes sense since managed objects in a context are unique. quote:I find it curious that the value you get out of isEqualToString: is greater than isEqual: but less than defining your own isEqualTo<Type>: methods. i.e. Where did you get that impression? quote:If it's as valuable as you say to have a specialized method for equality, why not write them yourself? I agree. It's good to implement specialized equality methods for all your value classes that have logical equality. quote:And again, it's not clear to me why isEqual: would be faster than isEqualToString: once the implementation of isEqual: figures out it's comparing two strings. Nor is it clear to me what self-documentation is going on. Whatever performance increase there may be is claimed by Apple. The self-documentation is in declaring that the code is working with strings. Toady fucked around with this message at 21:34 on Sep 29, 2011 |
|
#
?
Sep 29, 2011 18:03
|
|
|
Toady posted:Where did you get that impression? When you said the omission isEqualToManagedObject: wasn't an oversight. I took that to mean you wouldn't implement the method yourself. quote:I agree. It's good to implement specialized equality methods for all your value classes that have logical equality. What's a value class? And what about classes that simply use pointer equality, should those have specialized equality methods? Why not? I imagine you also override isEqual: for those classes. Does isEqual: in turn immediately call your specialized equality methods? Do your specialized equality methods claim increased performance? quote:Whatever performance increase there may be is claimed by Apple. The self-documentation is in declaring that the code is working with strings. I feel like we're talking by each other at this point. Thanks very much for the discussion, I've learned a lot.
|
|
#
?
Sep 29, 2011 22:45
|
|
|
I have another odd issue... I created a category for a particular class and even though I've yet to actually import the category into ANY class, the prefix header or anywhere I can find via searching in XCode and grepping the filesystem - the category is still being loaded and doing it's voodoo. What the hell?
|
|
#
?
Sep 30, 2011 00:52
|
|
|
WildFoxMedia posted:I have another odd issue... If the .m file gets compiled and linked (i.e. has a target in Xcode), the class gains the methods. The .h file simply tells the compiler about the methods defined therein. If you want to keep the category methods out, remove the .m from the target.
|
|
#
?
Sep 30, 2011 01:56
|
|
|
|
| # ? May 15, 2024 12:15 |
|
|
pokeyman posted:If the .m file gets compiled and linked (i.e. has a target in Xcode), the class gains the methods. The .h file simply tells the compiler about the methods defined therein. If you want to keep the category methods out, remove the .m from the target. Clearly my sound understanding of ObjectiveC comes into question... That makes sense Another quick one - Is there an accepted strategy for requesting/displaying remote retina images?
|
|
#
?
Sep 30, 2011 02:27
|
|