> Not that I can tell... it mostly seems to be stuff that either depends > on or is in lieu of unserialization, or maybe stuff that could be > moved to init() but just didn't get put there. Not that it's always > easy to tell by inspection. Be careful. I'm pretty sure it's come up, but it could easily have been in the tlaser code that was dropped.
> I'd argue that it is... it's just setting it programmatically rather > than from a stored checkpoint. My point is that __setstate__ in python is only called when you're unpickling. > Basically all the stuff that could appear in both versions of > setState() can also go in init() or in startup(). In this case, since > everything started out in startup(), I just left the common code in > startup(). I was still able to get rid of startup() for all the > Process and System classes (IIRC). I'm not sure what you're saying here. > As an aside, I'm going to get rid of the overloaded function names > (even though I like them) because this issue is giving me problems: > http://www2.research.att.com/~bs/bs_faq2.html#overloadderived Ah, yes. Of course. I always thought that was stupid, though Bjarne is probably smarter than I am. I can't say that in this case, I'm sorry. > The tricky part with trying to reduce the number of SimObject methods > too far is that it makes inheritance messier. You typically want to > write code like: I'm convinced. > Also from a practical perspective there are tons of functions called > init(), and it's a bit of a pain to identify the ones that are on > SimObject-derived classes and the ones that aren't. you mean from a grep perspective? Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
