On Feb 4, 2007, at 11:00 AM, John Jobe wrote:
Not a bug. Just a limit. Besides it kind of forces you to think
through your code a little bit more (which is usually a good
thing). Super long methods aren't really ideal. As a general rule
I recommend keeping methods to the amount that is readable on a
given screen without scrolling whenever possible. If that method
must call 10 or 12 other methods that's fine, but they should also
try to follow that rule too. If you believe that in your case this
type of goal isn't possible I won't argue, but look at your code
carefully before saying that it can't be done. I've rarely seen a
case where things couldn't be broken down and simplified.
No need to wonder about whether it is a bug or not.
The refactoring of the entire method is a given. My curiosity about
this compile problem rests in the difference between 2006r1, where it
compiled, 2006r2, where it showed 39k stack usage and all later
versions, including 2007r2a1, where it showed 44k stack usage. Why is
the compiler using this space and what might be causing it. There is
no unusual quitting of Rb and it responds to the "error" quite nicely
both during an IDE run or a Build attempt. I can see more stack space
used by calling multiple methods within methods but this particular
code doesn't do that.
I guess I just don't understand the compiler's quirks enough to
understand the effect of a long method.
Terry
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
