On Sat, Oct 27, 2012 at 2:41 PM, Matthias Friedrich <[email protected]> wrote: > On Saturday, 2012-10-27, Josh Wills wrote: >> On Sat, Oct 27, 2012 at 12:49 PM, Gabriel Reid <[email protected]> >> wrote: > [...] >>> I'm on board with the moving of PType, PTypeFamily, and PTableType classes >>> to the base package (although it seems a shame because the package name >>> that they're in already got changed once). > >>> However, I'm less sure about moving Converter and OutputHandler, as I don't >>> really see these as core (external) abstractions. It kind of feels like >>> moving those >>> will just clutter up the base package. > >> +100 > > Could you be a bit more specific on what you agree on? :)
Ha-- I agreed w/everything Gabriel said. A lot. ;-) > > I'd like to avoid a CRUNCH-60 type of situation where I spend lots of > time playing through scenarios and planning changes that, as it turns > out, aren't welcome. That is *very* frustrating, to say the least, so > let's talk ;-) Yeah, that sucked, let's not do that again. I think my main concern is that I don't have visibility into the scope of API changes that come along with CRUNCH-60, so I don't really see what we're building towards. I want to know what the end state of the API looks like w/some amount of precision-- what will live where, etc., etc. I agree w/Gabriel that having PType and PTypeFamily in the base package feels right and that having stuff that is essentially implementation detail stuff like Converter and OutputHandler there feels wrong. It may be that the value of having PType and PTypeFamily in base outweighs the cost of having Converter and OutputHandler there as well, but since I don't see the big picture here, it feels like we're making a series of locally optimal decisions that don't necessarily lead to a globally optimal API, where I'm using "optimal" in the sense of one that is both cleanly separated as well as easy to understand and use. Making a series of locally optimal decisions is how I ended up coding into the cul-de-sac that necessitated the OutputHandler abstraction in the first place. If it's possible to spell out exactly what the APIs look like when this is done, let's do that; if we're not there yet but could spell out a set of principles that we would like to be true of the APIs, then let's do that and then start creating some strawman proposals for organization of code that satisfies them as closely as we can. Implementing the changes required to get to the goals may take longer than a single release cycle, but I wouldn't want it to take more than two releases, just because I'm loathe to be in a process of continually moving things around. I think that once we have a proposal we agree on, we should cut the 0.4.0 release and then devote the next release cycle to implementing the new API for 0.5.0. Josh > > Regards, > Matthias
