Re: Amount of Arguments per Method
On Jun 23, 2009, at 9:14 AM, WT wrote: On Jun 23, 2009, at 4:57 PM, mmalc Crawford wrote: On Jun 23, 2009, at 4:05 AM, WT wrote: Let's start with bug reporting, which is of general relevance to developers here: Whether or not it's an actual *error* is immaterial -- it's a usability issue. It's still considered as a bug. Not if it's a usability issue to only a very small group of people, which seems to be the case here. Wrong. As far as those people are concerned, it's still a usability issue, which is considered a bug, and worth reporting. (Here and hereafter bug may mean feature or enhancement request.) Without reports, we will never know how widespread it is... Bug reports don't have to be a novel. You could have spent less time filing a bug report than you have posting messages to this thread. Since you're going to one extreme, let me go to the other. What do you think the result would be if someone filed a request that just said add spaces to the documentation ? The positive result would be that it would be added to a database of bugs for consideration for action. If many people provided feedback along the lines of: --- Long method declarations and invocations in a single, e.g. - (id) outputImageProviderFromBufferWithPixelFormat:(NSString*)format pixelsWide:(NSUInteger)width pixelsHigh:(NSUInteger)height baseAddress: (const void*)baseAddress bytesPerRow:(NSUInteger)rowBytes releaseCallback:(QCPlugInBufferReleaseCallback)callback releaseContext: (void*)context colorSpace:(CGColorSpaceRef)colorSpace shouldColorMatch: (BOOL)colorMatch are difficult to parse. The documentation would be more readable if such code were laid out to make the relationship between the keywords and arguments more obvious. To illustrate, one possible format would be: - (id) outputImageProviderFromBufferWithPixelFormat: (NSString*) format pixelsWide: (NSUInteger) width pixelsHigh: (NSUInteger) height baseAddress: (const void*) baseAddress bytesPerRow: (NSUInteger) rowBytes releaseCallback: (QCPlugInBufferReleaseCallback) callback releaseContext: (void*) context colorSpace: (CGColorSpaceRef) colorSpace shouldColorMatch: (BOOL) colorMatch --- then it might be determined that: (a) The documentation tools should be modified to output method declarations in a different format; (b) Guidelines should be changed such that writers are encouraged to format such code appropriately. There are a few important subtleties here: 1. This might be a nice to have feature, but if it's one that a sufficiently large number of people desire then it's more important, particularly if the solution can be provided at comparatively low cost. Of course, we'll only know how many people might like this if they actually bother to file bugs. 2. There's no need to spend more time on crafting the report than has been spent in this thread so far -- it doesn't have to be an extensive treatise. 3. The bug stated the problem but avoided requiring a particular solution, instead providing an example. When making requests such as this, it's typically better to describe the problem and perhaps point in the general direction of a solution rather than require a specific implementation. Such issues may be considered in a broader context -- there may be several possible remedies to the problems, and the one chosen may be dependent on other factors. So to reiterate, the documentation is considered part of the product. If you can identify a change that might make you more productive as a developer, then it's worth reporting as a bug. The remainder of the message relates to mailing list etiquette -- feel free to skip it. ** Any responses to this section should be made off-list. ** To address these points generally: Why is it so baffling? The question is not wanting something to be changed, but wanting *bad enough* to have something changed. Because, as has been stated so often, posting messages to a list will not cause any change. If you complain about something on a list but don't actually file a bug report, then you're simply wasting everyone's time. You're making the unjustified assumption that my original comment was a complaint intended to cause a change. It's clearly sufficiently important an issue that you're willing to bring it to several thousand other people's attention. If it's important enough for that, it's important enough for a bug report. Another unjustified assumption. If my intention was to bring this specific matter to the attention of several thousand people with the specific intention of effecting change, I
[Moderator] Re: Amount of Arguments per Method
This thread is closed. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
Not a method, but NSCell.h has a function with 13 arguments. APPKIT_EXTERN void NSDrawNinePartImage(NSRect frame, NSImage *topLeftCorner, NSImage *topEdgeFill, NSImage *topRightCorner, NSImage *leftEdgeFill, NSImage *centerFill, NSImage *rightEdgeFill, NSImage *bottomLeftCorner, NSImage *bottomEdgeFill, NSImage *bottomRightCorner, NSCompositingOperation op, CGFloat alphaFraction, BOOL flipped) AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER; -Ken On Mon, Jun 22, 2009 at 1:03 AM, Roland King r...@rols.org wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. -(id)initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: WT wrote: On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com This email sent to kenfe...@gmail.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 23, 2009, at 7:45 AM, Scott Anguish wrote: There should be whitespace automatically generated between the necessary bits. There is necessary as far as the compiler is concerned and there is necessary as far as humans are concerned. The second isn't technically a necessity, and is therefore a subjective issue, but I think most people would agree that some white space makes code easier to read. In any case, there is no valid reason that I can think of to have the documentation be so terse. If you'd rather see it the other way (and I can see an argument for that), hit up bugreporter or feedback. On an off-list reply to the question have you filed a bug?, I said: No. My perception is that A LOT of people in the cocoa-dev list really don't see this as a problem (Do you? If so, have you filed a bug?), which puts me in a very small minority. I don't expect Apple to change their entire documentation based on something that is not a bug and that most people have no problems with. So, it's just one of those things in life that I just deal with on my own. On the other hand, if I'm mistaken about how many people think as I do, I'll probably see some supporting feedback to my post on cocoa- dev. If that's the case, I'll consider filing a documentation enhancement request. Devpubs listens, and our delivery team (the folks that take the XML and output it to the various formats) ROCK. I am now leaning more and more towards filing a documentation enhancement request. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 22, 2009, at 10:59 PM, WT wrote: Devpubs listens, and our delivery team (the folks that take the XML and output it to the various formats) ROCK. I am now leaning more and more towards filing a documentation enhancement request. This is simply baffling. If you want something to be changed, then *file a bug report*. mmalc ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 23, 2009, at 9:33 AM, mmalc Crawford wrote: On Jun 22, 2009, at 10:59 PM, WT wrote: Devpubs listens, and our delivery team (the folks that take the XML and output it to the various formats) ROCK. I am now leaning more and more towards filing a documentation enhancement request. This is simply baffling. If you want something to be changed, then *file a bug report*. mmalc Why is it so baffling? The question is not wanting something to be changed, but wanting *bad enough* to have something changed. As I pointed out in the section that you left out of your quote of my previous message, I don't believe that Apple would change something across their entire documentation that is not an actual error and which most people in this list don't even think is an issue at all, which means that in order to make a convincing case I'd have to spend an atypically large amount of time composing my request. Like most people, I have other things to do. Unlike many people, I try not to do things in a half-cooked way and would/will file a request only if I'm reasonably sure that my efforts would/will pay off. Also, I do not consider this such a high-priority issue, which I already alluded to earlier when I said that I've learned to deal with it in my own way, or else I would already have filed a documentation enhancement request. So, ease off with the head-chewing. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
That can be better, but then you end up with 2x as many arguments, in a way: [NSDictionary dictionaryWithObjectsAndKeys: ob1, key1, ob2, key2, ... etc. On 6/22/09 7:10 AM, Jack Carbaugh said: With that many arguments, i'd make a dictionary and pass only that dictionary. I understand your choice for not doing so however. jack On Jun 22, 2009, at 4:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. - (id )initWithBitmapDataPlanes:pixelsWid e:pixelsHigh:bitsPerSample:samplesPer Pixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : WT wrote: On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/intrntmn%40aol.com This email sent to intrn...@aol.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: http://lists.apple.com/mailman/options/cocoa-dev/sean%40rogue-research.com This email sent to s...@rogue-research.com -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 23, 2009, at 4:05 AM, WT wrote: Why is it so baffling? The question is not wanting something to be changed, but wanting *bad enough* to have something changed. Because, as has been stated so often, posting messages to a list will not cause any change. If you complain about something on a list but don't actually file a bug report, then you're simply wasting everyone's time. As I pointed out in the section that you left out of your quote of my previous message, I don't believe that Apple would change something across their entire documentation that is not an actual error Whether or not it's an actual *error* is immaterial -- it's a usability issue. It's still considered as a bug. and which most people in this list don't even think is an issue at all, which means that in order to make a convincing case I'd have to spend an atypically large amount of time composing my request. Like most people, I have other things to do. Bug reports don't have to be a novel. You could have spent less time filing a bug report than you have posting messages to this thread. You would also have better respected others' time. Unlike many people, I try not to do things in a half-cooked way and would/will file a request only if I'm reasonably sure that my efforts would/will pay off. Efforts posting to a list without filing a bug report are certainly wasted. Also, I do not consider this such a high-priority issue, which I already alluded to earlier when I said that I've learned to deal with it in my own way, or else I would already have filed a documentation enhancement request. It's clearly sufficiently important an issue that you're willing to bring it to several thousand other people's attention. If it's important enough for that, it's important enough for a bug report. So, ease off with the head-chewing. Please don't misrepresent others' behaviour. mmalc ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 23, 2009, at 4:57 PM, mmalc Crawford wrote: On Jun 23, 2009, at 4:05 AM, WT wrote: Why is it so baffling? The question is not wanting something to be changed, but wanting *bad enough* to have something changed. Because, as has been stated so often, posting messages to a list will not cause any change. If you complain about something on a list but don't actually file a bug report, then you're simply wasting everyone's time. You're making the unjustified assumption that my original comment was a complaint intended to cause a change. As is clear from what I said - or at least it should have been - I can live with things as they are, so my original comment was merely that: a comment. Last I checked, people can still post comments in this list, provided they are related to the list's subject matter. That is, comments don't *have* to imply an action. Whether or not it's an actual *error* is immaterial -- it's a usability issue. It's still considered as a bug. Not if it's a usability issue to only a very small group of people, which seems to be the case here. Bug reports don't have to be a novel. You could have spent less time filing a bug report than you have posting messages to this thread. Since you're going to one extreme, let me go to the other. What do you think the result would be if someone filed a request that just said add spaces to the documentation ? If this is something important to me, I'd make the effort to be thorough in my reasoning when filing a request. Being thorough does not equate to writing a novel, but it still requires time. You would also have better respected others' time. It's the second time in your message that you subtly accuse me of wasting your time (and other people's). No one forced you to read my posts. Efforts posting to a list without filing a bug report are certainly wasted. See the first paragraph of this reply. It's clearly sufficiently important an issue that you're willing to bring it to several thousand other people's attention. If it's important enough for that, it's important enough for a bug report. Another unjustified assumption. If my intention was to bring this specific matter to the attention of several thousand people with the specific intention of effecting change, I would have done it in a separate thread, not in this thread. As I pointed out above, my original message was merely a comment. So, ease off with the head-chewing. Please don't misrepresent others' behaviour. I don't think I did that and I stand by my request. Your This is simply baffling was clearly judgmental, and uncalled for in a public venue. === Not that I see a reason to continue this exchange, but should you choose to do so, we should do it off the list. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Amount of Arguments per Method
clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? also, just for fun, what's the longest method name you've seen? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? The C99 standard states that conforming compilers must support at least 127 function arguments. I don't know if GCC enforces a limit above this, but if it doesn't, then the maximum number of arguments is only limited by the available stack space at run time. I assume Objective-C would support the same functionality, but I'm sure someone will correct me if I'm wrong. (Note that Obj-C uses two hidden arguments when sending messages: self and _cmd. So in the case that GCC supports the bare minimum of 127 function arguments, when sending messages with Objective-C, you'd only be able to use 125. In practice though, I think we all have a better chance of winning the lottery, getting struck by lightning, and contracting swine flu all in the same night, than creating a genuinely useful function that takes 128 arguments.) also, just for fun, what's the longest method name you've seen? Probably my own; I'm relentless when it comes to clarity in method, class and variables names. I've got a class name that's 55 characters, a category (filename) that's 51, and a variable name that's (drumroll) 63 characters. Of course, it's arguable that after a certain length, it's counterproductive. I think I'm just crazy... David ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. -(id)initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: WT wrote: On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
With that many arguments, i'd make a dictionary and pass only that dictionary. I understand your choice for not doing so however. jack On Jun 22, 2009, at 4:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. - (id )initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : WT wrote: On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/intrntmn%40aol.com This email sent to intrn...@aol.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
That one's not mine, that's Apple's. The original poster asked what the longest one was, that's the longest Cocoa one I've come across. I didn't use it! On Jun 22, 2009, at 7:10 PM, Jack Carbaugh wrote: With that many arguments, i'd make a dictionary and pass only that dictionary. I understand your choice for not doing so however. jack On Jun 22, 2009, at 4:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. - (id )initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : WT wrote: On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/intrntmn%40aol.com This email sent to intrn...@aol.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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 22, 2009, at 6:10 AM, Jack Carbaugh wrote: With that many arguments, i'd make a dictionary and pass only that dictionary. I understand your choice for not doing so however. Why? If you break up the call by hitting return after each argument and line up the colons (which Xcode will do automatically), it is about as clear as it can get. With a dictionary there is no validation during compilation that you have set up all of the parameters, you can't pass scalar values directly, and it adds all kinds of unnecessary additional dependencies (like memory management, if in non-GC). Still, I avoid such a monstrosity of a method when defining APIs. b.bum ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 22, 2009, at 4:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. - (id )initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : That's still the longest, both by name length (148) and number of arguments, if you look only at the most commonly used frameworks. However, as of Leopard, the longest *documented* method name (150, though with only 9 arguments) is [QCPlugInContext outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch :] http://developer.apple.com/documentation/Cocoa/Reference/QCPlugInContext_Protocol/Reference/Reference.html#//apple_ref/occ/intfm/QCPlugInContext/outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch: . I also found two undocumented methods with 15 arguments, both in DOMMouseEvent: initMouseEvent:canBubble:cancelable:view:detail:screenX:screenY:clientX:clientY:ctrlKey:altKey:shiftKey:metaKey:button:relatedTarget : initMouseEvent::: On the iPhone [2], the longest by name (113), with 6 arguments, is [NSDecimalNumberHandler decimalNumberHandlerWithRoundingMode:scale:raiseOnExactness:raiseOnOverflow:raiseOnUnderflow:raiseOnDivideByZero :] Until recently, the method with the most arguments (7) was [NSString drawAtPoint:forWidth:withFont:minFontSize:actualFontSize:lineBreakMode:baselineAdjustment :] In the 3.0 SDK there is now [NSMigrationManager migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error :] with 8 arguments. --Andy [1] Based on a search of: AddressBook, AirPort, AppKit, ApplicationServices, Automator, CalendarStore, Collaboration, CoreData, DiscRecording, DiscRecordingUI, ExceptionHandling, Foundation, InputMethodKit, InstantMessage, IOBluetooth, IOBluetoothUI, Message, OpenDirectory, PreferencePanes, PubSub, QTKit, Quartz, QuartzCore, ScreenSaver, ScriptingBridge, SecurityFoundation, SecurityInterface, ServerNotification, SyncServices, WebKit, XgridFoundation [2] Based on a search of: AddressBook, AddressBookUI, AudioToolbox, AudioUnit, AVFoundation, CFNetwork, CoreAudio, CoreData, CoreFoundation, CoreGraphics, CoreLocation, ExternalAccessory, Foundation, GameKit, MapKit, MediaPlayer, MessageUI, OpenGLES, QuartzCore, Security, StoreKit, SystemConfiguration, UIKit ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 22, 2009, at 4:14 PM, Andy Lee wrote: On Jun 22, 2009, at 4:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. - (id )initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : That's still the longest, both by name length (148) and number of arguments, if you look only at the most commonly used frameworks. However, as of Leopard, the longest *documented* method name (150, though with only 9 arguments) is snip This brings to mind a peeve of mine: Apple's unofficially sanctioned practice, followed by a lot of people, of NOT throwing in some white space in between parts of method names. Programmers spend most of their time *reading* code (their own or other people's), and with method names as verbose as those found in Cocoa, it seems to me that adding some white space ought to be a common practice. Alas... I mean, seriously, how easy is it to read - (id) outputImageProviderFromBufferWithPixelFormat:(NSString*)format pixelsWide:(NSUInteger)width pixelsHigh:(NSUInteger)height baseAddress: (const void*)baseAddress bytesPerRow:(NSUInteger)rowBytes releaseCallback:(QCPlugInBufferReleaseCallback)callback releaseContext: (void*)context colorSpace:(CGColorSpaceRef)colorSpace shouldColorMatch: (BOOL)colorMatch (copied directly from the documentation link Andy provided) compared to - (id) outputImageProviderFromBufferWithPixelFormat: (NSString*) format pixelsWide: (NSUInteger) width pixelsHigh: (NSUInteger) height baseAddress: (const void*) baseAddress bytesPerRow: (NSUInteger) rowBytes releaseCallback: (QCPlugInBufferReleaseCallback) callback releaseContext: (void*) context colorSpace: (CGColorSpaceRef) colorSpace shouldColorMatch: (BOOL) colorMatch I know that XCode will automatically pretty-print code for us, but I'm talking about Apple's documentation (and code-sharing in this list and elsewhere). It's not like pdfs or html pages kill trees, you know. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On 23/06/2009, at 1:03 AM, WT wrote: This brings to mind a peeve of mine: Apple's unofficially sanctioned practice, followed by a lot of people, of NOT throwing in some white space in between parts of method names. Programmers spend most of their time *reading* code (their own or other people's), and with method names as verbose as those found in Cocoa, it seems to me that adding some white space ought to be a common practice. Alas... I mean, seriously, how easy is it to read I totally agree with you. On a very similar note, I really dislike the fact that in headers (and source for that matter), the return type of a method is immediately followed by the start of the method name. It makes it very hard to visually separate the two and hence very easy to miss a method relevant to a given problem when hunting through the headers. In my own headers, I put whitespace between the return type and the start of the method name, and also line up the method names on a tab. It makes manually 'parsing' headers far easier, since I'm usually more interested in what the method does than the type it returns, at least on a first pass. e.g: - (BOOL)shouldAutoActivateWithEvent:(NSEvent*) event; - (BOOL)hitLayer:(NSPoint) p; - (DKDrawableObject*) hitTest:(NSPoint) p; - (void)mouseDown:(NSEvent*) event inView:(NSView*) view; - (void)mouseDragged:(NSEvent*) event inView:(NSView*) view; - (void)mouseUp:(NSEvent*) event inView:(NSView*) view; - (void)flagsChanged:(NSEvent*) event; - (NSView*) currentView; - (NSCursor*) cursor; - (NSRect) activeCursorRect; as opposed to: - (BOOL)shouldAutoActivateWithEvent:(NSEvent*)event; - (BOOL)hitLayer:(NSPoint)p; - (DKDrawableObject*)hitTest:(NSPoint)p; - (void)mouseDown:(NSEvent*) event inView:(NSView*)view; - (void)mouseDragged:(NSEvent*)event inView:(NSView*)view; - (void)mouseUp:(NSEvent*) event inView:(NSView*)view; - (void)flagsChanged:(NSEvent*)event; - (NSView*)currentView; - (NSCursor*)cursor; - (NSRect)activeCursorRect; --Graham ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 22, 2009, at 1:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. -(id) initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : One of the Objective-C runtime's unit tests includes methods with names like @selector(idret) That's 28 unnamed parameters. (The test fills every parameter register with a value, to make sure objc_msgSend() doesn't trample them. Some architectures have a lot of parameter registers.) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
In documentation, stacking the arguments verticaly is of value. In actual code, I _always_ concatenate on to as few lines as necesary (tho' using double indentation for subsequent lines) as I find it makes for much _more_ readable code. Reasoning? - I wrote that code, or I've already read it carefully, so I know - as well as I need to - what kinds of arguments it takes. What I'm much more interested in is the 'shape' of the code, or it's structure. So fitting more on a page is much of more value (but not over-compressing the code as this has exactly the oposite effect). A problem with an individual function call means I concentrate on the line or lines that it occupies, stacking verticaly doesnt help much. If the structure of the code is obfusicated, that will always be a problem and an ongoing one. That's just my view. The point is - do what works best for you, and leave others do what's best for them. Trying to force others to your preference is a great way to stifle creativity, enjoyment and quality. Everybody is different and works differently, and the very best they can do is to do what works best for them. paulm On 23/06/2009, at 3:03 AM, WT wrote: This brings to mind a peeve of mine: Apple's unofficially sanctioned practice, followed by a lot of people, of NOT throwing in some white space in between parts of method names. Programmers spend most of their time *reading* code (their own or other people's), and with method names as verbose as those found in Cocoa, it seems to me that adding some white space ought to be a common practice. Alas... I mean, seriously, how easy is it to read - (id) outputImageProviderFromBufferWithPixelFormat:(NSString*)format pixelsWide:(NSUInteger)width pixelsHigh:(NSUInteger)height baseAddress:(const void*)baseAddress bytesPerRow:(NSUInteger)rowBytes releaseCallback:(QCPlugInBufferReleaseCallback)callback releaseContext:(void*)context colorSpace:(CGColorSpaceRef)colorSpace shouldColorMatch:(BOOL)colorMatch (copied directly from the documentation link Andy provided) compared to - (id) outputImageProviderFromBufferWithPixelFormat: (NSString*) format pixelsWide: (NSUInteger) width pixelsHigh: (NSUInteger) height baseAddress: (const void*) baseAddress bytesPerRow: (NSUInteger) rowBytes releaseCallback: (QCPlugInBufferReleaseCallback) callback releaseContext: (void*) context colorSpace: (CGColorSpaceRef) colorSpace shouldColorMatch: (BOOL) colorMatch I know that XCode will automatically pretty-print code for us, but I'm talking about Apple's documentation (and code-sharing in this list and elsewhere). It's not like pdfs or html pages kill trees, you know. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Mon, Jun 22, 2009 at 7:46 PM, Paul Ml...@no-tek.com wrote: In documentation, stacking the arguments verticaly is of value. In actual code, I _always_ concatenate on to as few lines as necesary (tho' using double indentation for subsequent lines) as I find it makes for much _more_ readable code. Reasoning? - I wrote that code, or I've already read it carefully, so I know - as well as I need to - what kinds of arguments it takes. What I'm much more interested in is the 'shape' of the code, or it's structure. So fitting more on a page is much of more value (but not over-compressing the code as this has exactly the oposite effect). A problem with an individual function call means I concentrate on the line or lines that it occupies, stacking verticaly doesnt help much. If the structure of the code is obfusicated, that will always be a problem and an ongoing one. The trouble with this sort of thing is that when you come back to the code in six months' time you will no longer know what kinds of arguments it takes and other such important details. Whether it's better to optimize for the short term or for the long term is of course a difficult decision that you need to make for yourself. I personally like to split long methods onto multiple lines or, better yet, take long methods as a sign of a design flaw and eliminate them altogether. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
On Jun 23, 2009, at 6:03 AM, Michael Ash wrote: On Mon, Jun 22, 2009 at 7:46 PM, Paul Ml...@no-tek.com wrote: In documentation, stacking the arguments verticaly is of value. In actual code, I _always_ concatenate on to as few lines as necesary (tho' using double indentation for subsequent lines) as I find it makes for much _more_ readable code. Reasoning? - I wrote that code, or I've already read it carefully, so I know - as well as I need to - what kinds of arguments it takes. What I'm much more interested in is the 'shape' of the code, or it's structure. So fitting more on a page is much of more value (but not over-compressing the code as this has exactly the oposite effect). A problem with an individual function call means I concentrate on the line or lines that it occupies, stacking verticaly doesnt help much. If the structure of the code is obfusicated, that will always be a problem and an ongoing one. The trouble with this sort of thing is that when you come back to the code in six months' time you will no longer know what kinds of arguments it takes and other such important details. Whether it's better to optimize for the short term or for the long term is of course a difficult decision that you need to make for yourself. I personally like to split long methods onto multiple lines or, better yet, take long methods as a sign of a design flaw and eliminate them altogether. Mike Exactly! Moreover, often times (especially if you're part of a team) one doesn't write code that's read just by oneself. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
Meh. I'd much rather see calls to methods that take many arguments broken up across a number of lines for three reasons (drawing the line at methods that take 4 or more arguments, for me): (0) I can scan any given line of the method invocation sub-expression and know that the aligned colons mean method name fragment on left, argument on right. Reading the method name becomes a simple vertical scan. Reading the arguments becomes scan left o' colon for context, right o' colon for value. (1) If any argument isn't a simple variable or constant, breaking it up by line makes reading the expression easier. (2) Knowing the exact extent of the method invocation expression is as simple as double-clicking the opening or closing bracket. (Or you can ctrl-d then ] on the closing bracket to have the opening bracket highlighted, if so configured). I find the whole cram-the-whole-expression-on-one-line notion to be utterly bizarre and painful to read. Code isn't a novel and we aren't writing paragraphs. Code is a highly structured sequence of expressions and our tools are optimized to navigating, editing and compiling said structured code. b.bum ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
I actually had to use that method once in one of my very first Cocoa apps. My personal rule of thumb for my own code is, when a method I write has more than 3 parameters I start to suspect there's a more OO way of breaking up the problem. Huge argument lists indicate a procedural design, and really feel wrong in the OO mental model. Rob On Jun 22, 2009, at 1:03 AM, Roland King wrote: This still the longest one or has Apple outdone themselves since? 11 args, you really wouldn't want much more than this. - (id )initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel : WT wrote: On Jun 22, 2009, at 8:05 AM, Chunk 1978 wrote: clearly simplicity is important, but i'd like to know if there is a limit for the amount of arguments which a method can handle? I don't know if there's an upper limit, but I don't recall ever writing a method with more than 5 or 6 arguments. When I feel inclined to do otherwise, it typically means that there's a flaw in my design. Wagner ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Amount of Arguments per Method
There should be whitespace automatically generated between the necessary bits. If you'd rather see it the other way (and I can see an argument for that), hit up bugreporter or feedback. Devpubs listens, and our delivery team (the folks that take the XML and output it to the various formats) ROCK. On 2009-06-22, at 11:03 AM, WT wrote: I mean, seriously, how easy is it to read - (id) outputImageProviderFromBufferWithPixelFormat:(NSString*) format pixelsWide:(NSUInteger)width pixelsHigh:(NSUInteger)height baseAddress:(const void*)baseAddress bytesPerRow:(NSUInteger) rowBytes releaseCallback:(QCPlugInBufferReleaseCallback)callback releaseContext:(void*)context colorSpace:(CGColorSpaceRef)colorSpace shouldColorMatch:(BOOL)colorMatch (copied directly from the documentation link Andy provided) compared to - (id) outputImageProviderFromBufferWithPixelFormat: (NSString*) format pixelsWide: (NSUInteger) width pixelsHigh: (NSUInteger) height baseAddress: (const void*) baseAddress bytesPerRow: (NSUInteger) rowBytes releaseCallback: (QCPlugInBufferReleaseCallback) callback releaseContext: (void*) context colorSpace: (CGColorSpaceRef) colorSpace shouldColorMatch: (BOOL) colorMatch ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
