Stef, Maybe a good distribution is to have one configuration per project and then configuration of xml support only gathers those projects as a facade... We are doing that in dbxtalk :P
On Fri, Jan 6, 2012 at 11:04 AM, Stéphane Ducasse <[email protected] > wrote: > > On Jan 6, 2012, at 2:36 PM, Norbert Hartl wrote: > > > > > Am 06.01.2012 um 14:13 schrieb Stéphane Ducasse: > > > >>> > >>> I disagree. There is more than one way to create a mess. One is what > you describe! The other one you get by over-engineering things. If you > create a configuration for every package that consist of one file only you > will get tons of configuration files with hard to maintain dependencies. A > bigger mess in my opinion (and experience). You always have to leverage the > use and effect of doing things. Configurations can have groups which is an > internal separation of things that belong together. > >>> As there are more ways to do it I have trouble understanding the "if > each package move its clients...". There is no need to have a single > approach. If it would be that way it would be good if pharo would just > follow ANSI. > >> > >> So then why not having a single one? > > > > You don't need to prove you are stubborn sometimes. I know it :) > > good :) > > > > >> I do not use Sixx. > >> But I use XMLParser. > >> > >> So do you think that I can maintain pastel, sixx versions that I do not > use? So do you think that having a large configuration > >> with parts that are unmaintained is good? > >> I do not think so. > >> > > Stef, what are you trying to tell? Of course, you can't maintain a > software you do not use. Nobody tells me you maintain the software _that > you_ use. But I can understand that you do not care about breaking clients > of the software that you use and maintain. > > no but this is distribution of responsibilities. > This is like switch vs polymorphism. Switch are cool because all the logic > is in one place but we know the price. > > Now if I want to have a jenkins system loading and running the tests of > configurationOf then I prefer to have one per project. > > > And so it is better to have even the smallest client in its own > configuration because if it would be in eye sight you might be forced to > think about to care about this package as well. Is it like that? > > > >> So I will create a ConfigurationOfXMLParser. > >> > > Yes, and create it for pharo only, so I do not need to care about it. > >> > >>>>> Sixx is a serializer/deserializer for XML and therefor is using > streams. Streams are one of those fine examples where platform differences > can drive you nuts. I couldn't understand all the fuzz of not using sport > and preferring grease for seaside but only for seaside etc. I had a hard > time dealing with platform subtleties for character encoding (yes, I care!) > and streams when it comes to dialects. So I decided to introduce grease and > made the GemStone port of Sixx depend on streams and character encoding > behaviour of grease (Please sue me!). Dale was so kind to make even > GemStone Core to depend on Grease to make Xml loadable by the core. > >>>> > >>>> But put that in ConfigurationOfSixx :) > >>>> > >>> Well, just do it. > >> > >> I do not use Sixx. > >> But I use XMLParser. > >> > > If you load ConfigurationOfXMLSupport and use it _where_ do you see what > is configured in there? > > If I use it then I have another configuration and I look at it to know > what I need to load. For example I want to run XMLParser tests together > with my tests. > > > Maybe we should proceed this discussion in spring. I understand that in > winter when the light is dim it is too easy to see the world in black and > white. Not your fault! > > No we have sun here. > I have to read configurationOfXMLSupport because I have other packages > that rely on it. > and the more complex it is the more painful for its clients. > > > >
