--- Piers Cawley <[EMAIL PROTECTED]> wrote: > Definitely having some common methods becoming > available would be > great. Back when I was toying with writing YA > generic persistence > layer I kept butting up against the fact that > there's no (reliable) > way for finding out what fields an object has. And > it'd be *really* > nice if I had some mechanism for 'dirtying' objects > so I'd know > whether they need writing back to to the database, > but that's overkill > I think. But that might be better addressed by using > a > Class::MethodMaker like approach.
Guido (www.sf.net/projects/guido/) has benefitted from using a custom Class::DirtyMethodMaker, which simply inherits from MethodMaker and adds a dirty flag. It works great and is transparent to the programmer. > > - debugging: this one is hard, and i still > haven't figured > > out a really great general purpose way to handle > it. ideally > > the amount of debugging/trace output should be > able to be > > specified differently for each api or component. > > furthermore, debugging should be > removable/compilable > > out/whatever for production mode. > > Take a look at Aspect::Trace which has some very > neat tricks for > adding logging to 'random' methods. Using Aspect it > is, in theory > possible to write an advice set that logs the > passage of a single > object through a system... Guido has a similar approach with its tracing. We added the ability to trace various subsystems, as well, by passing in certain parameters. We also enabled a trace window rather than console output by allowing a "trace callback" to be used instead of always having the tracing facility actually do the output. I'd recommend providing as much flexibility as possible while also allowing a reasonable default for those who don't want to be bothered. > > finally, there should be some way of outputting > human readable > > representations of object attributes - maybe we > just count on a > > to_string method existing for each object in each > api, or maybe our > > debugging api includes a dump_object method. I think this would be extremely handy, but you have to be careful that you don't end up trying to achieve multiple purposes with a single method. Normally to_string implies that the object's primary data is converted to a string for display, but a good debug dump would do something more akin to Data::Dumper or the perl debugger's output. jpt __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
