Re^7: Informal Poll: Traits (Long Post Warning!)

Yeah, I read that part in A12 as well, I think it is flat out insanity myself :) Nuff said.

I'd just like to point out that the passage you're quoting has almost nothing to do with standard dispatch. It's just syntactic relief for alternate dispatchers, selected by the caller. That last bit is important. Once you commit to a particular dispatcher, you're stuck with it. If you use the ordinary dispatcher syntax, you get the ordinary dispatcher. There's no extra overhead there. In fact, you probably use the ordinary fast dispatcher to get to the alternate dispatcher, as if it were just an ordinary method call. The rest is just syntax.

Comment on Re^7: Informal Poll: Traits (Long Post Warning!)

Replies are listed 'Best First'.
Re^8: Informal Poll: Traits (Long Post Warning!) by stvn (Monsignor) on Nov 21, 2005 at 01:11 UTC
That last bit is important. Once you commit to a particular dispatcher, you're stuck with it. So if I understand correctly, if I chose for a particular method call to use breadth-first, instead of the canonical C3, then it will apply for that particular method call only. That is still insane, but not as bad as I originally thought :) -stvn	[reply]
Re^9: Informal Poll: Traits (Long Post Warning!) by TimToady (Parson) on Nov 21, 2005 at 02:27 UTC
We are trying to unify MRO generators regardless of the call-one vs call-all semantics of the eventual dispatch. And we know that the desired order for construction and destruction are opposite to each other, so they can't be exactly the same dispatcher, though they might use the same MRO in opposite orders. We're just trying to generalize, and in particular keep the done-vs-try-again distinction orthogonal to MRO determination. And as long as the syntax allows us to plug in a different one without an additional level of indirection, we've made no commitments to which ones run fast and which ones run slow. In other words, yes, it's insane. Crazy like a fox, if you will... `:-)`	[reply]