Bug 3060 - stack trace api suggestions
Summary: stack trace api suggestions
Status: NEW
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks: 1736
  Show dependency treegraph
 
Reported: 2006-08-15 17:28 UTC by Tom Tromey
Modified: 2006-11-28 16:43 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2006-08-15 17:28:35 UTC
While playing with the stack trace API I came across a 
couple places where it felt odd.  Maybe these changes would
be improvements.

Currently there is a static method in StackFactory to create
a stack trace for a Task.  An ordinary instance method on Task
would arguably be "more OO" (bear with me here, there's more coming...)

It seems strange for StackFrame to be both an object and its own
iterator (in a way; since it has getInner and getOuter).  Perhaps
createStackFrame could be renamed and could return an ordinary ordered
collection of StackFrame objects.

I suspect that a very common thing to do with a stack trace is iterate
over it in order.  If task had a method to return an ordinary collection
you could write natural (1.5) code for this like:

for (StackFrame frame : task.getStackTrace()) { ... }

Of course there are several possiblities here: Task could implement
Iterable (1.5 addition) itself (though this makes it harder to iterate
in reverse order).  StackFrame could itself implement Iterator (and
even Iterable, simply returning 'this').

Finally, it would be very handy if StackFrame had a toString method
to format the frame in a user-friendly way.  That way code could
simply print the frame object...