> > 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
probably. > > > > 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. > > > >
