> > 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? 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. So I will create a ConfigurationOfXMLParser. >>> 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. > I personally would put xml parser, sixx, pastell, other xpath libs and the > pull parser in a single configuration file. If someone likes to do XML stuff > he/she will be fine to find it maintained in a single place. All of the > mentioned libs are single packaged, tiny things. This would probably also > help to find an existing lib before implemented your own (search for xpath in > the mailing lists). > I understand you are looking for something "clean". Well, knock yourself off. > I'm more after usable units. No I'm looking for usable things too and when I load configurationOfXML to get the parser I'm not interested in the clients of XMLParser, else you should also put Soup and a couple of others. > > Norbert > >> >> >>> Later I recognized that in pharo terms this is not possible. I had a >>> discussion with Sven because I wanted to have a zinc port for gemstone. But >>> he was more interested to get zinc close to pharo. So the grease way was >>> not an option and the result is the port to gemstone is still incomplete >>> and hard to maintain. >>> >>> Sorry for the long answer but this is just another story of how hard it is >>> to have modular systems where all of the mentioned issues wouldn't be that >>> much of a problem. I would wish that we find a good solution to make >>> sources more interchangable between platforms. I don't mean get rid of the >>> dialect differences (because I don't think it will happen) but to design >>> code in a way that platform subtleties can be compensated in an object >>> oriented way. >>> >>> Norbert >>> >>> >> >> > >
