[Pharo-project] About ConfigurationOfXMLSupport
Hi guys I thought that XMLSupport was about parsing and XMLNode traversal. So why the configuration contains references to SIXX and Grease Core? Stef
Then I do not understand how a stable version can be defined as stable: spec <symbolicVersion: #'stable'> spec for: #'common' version: '1.2.1'. spec for: #'gemstone' version: '1.1.8'. Because I would really prefer to get stable: spec <symbolicVersion: #stable> spec for: #gemstone version: '1.5'. spec for: #'squeak' version: '1.4'. spec for: #'pharo1.0.x' version: '1.5'. spec for: #'pharo1.1.x' version: '1.5'. spec for: #'pharo1.2.x' version: #development. Because like that we can load it in different versions. Am'I wrong? Stef On Dec 29, 2011, at 11:04 PM, Stéphane Ducasse wrote:
Hi guys
I thought that XMLSupport was about parsing and XMLNode traversal. So why the configuration contains references to SIXX and Grease Core?
Stef
Stef, I think that the #stable spec that exists for that package is based on the bet guess at the time ... as better information comes along the #stable spec should be updated ... hopefully the developers themselves would eventually update and maintain the #stable spec ... Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Thursday, December 29, 2011 2:08:59 PM | Subject: Re: [Pharo-project] About ConfigurationOfXMLSupport | | Then I do not understand how a stable version can be defined as | | stable: spec | <symbolicVersion: #'stable'> | | spec for: #'common' version: '1.2.1'. | spec for: #'gemstone' version: '1.1.8'. | | | Because I would really prefer to get | | stable: spec | <symbolicVersion: #stable> | | spec for: #gemstone version: '1.5'. | spec for: #'squeak' version: '1.4'. | spec for: #'pharo1.0.x' version: '1.5'. | spec for: #'pharo1.1.x' version: '1.5'. | spec for: #'pharo1.2.x' version: #development. | | Because like that we can load it in different versions. | | Am'I wrong? | | Stef | On Dec 29, 2011, at 11:04 PM, Stéphane Ducasse wrote: | | > Hi guys | > | > I thought that XMLSupport was about parsing and XMLNode traversal. | > So why the configuration contains references to SIXX and Grease | > Core? | > | > Stef | > | | |
Am 29.12.2011 um 23:04 schrieb Stéphane Ducasse:
Hi guys
I thought that XMLSupport was about parsing and XMLNode traversal. So why the configuration contains references to SIXX and Grease Core?
It is called XMLSupport. So it combines xml support technologies (otherwise it should be named ConfigurationOfXMLParsersAndDOM). I think Michael just dropped the name in and nobody changed it. The presence of Sixx and the dependency of Grease is my duty (I'm intentionally not writing 'my faul't). I'm working a lot in GemStone and differences between the dialects are a real pain if you try to develop in pharo and deploy in GemStone. As we also need to exchange data we ported Sixx to GemStone. I've put Sixx in the configuration to keep the development of XML parser and Sixx close because Sixx relies on the interface of xml parser pretty much. As every module is a symbol there is no problem. And Sixx is not loaded by default. 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. 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
On Jan 4, 2012, at 3:59 PM, Norbert Hartl wrote:
Am 29.12.2011 um 23:04 schrieb Stéphane Ducasse:
Hi guys
I thought that XMLSupport was about parsing and XMLNode traversal. So why the configuration contains references to SIXX and Grease Core?
It is called XMLSupport. So it combines xml support technologies (otherwise it should be named ConfigurationOfXMLParsersAndDOM). I think Michael just dropped the name in and nobody changed it.
The presence of Sixx and the dependency of Grease is my duty (I'm intentionally not writing 'my faul't). I'm working a lot in GemStone and differences between the dialects are a real pain if you try to develop in pharo and deploy in GemStone. As we also need to exchange data we ported Sixx to GemStone. I've put Sixx in the configuration to keep the development of XML parser and Sixx close because Sixx relies on the interface of xml parser pretty much. As every module is a symbol there is no problem. And Sixx is not loaded by default.
I know what is SIXX but to me you should write a ConfigurationOfSixx, if each package move its clients close to him then we will end up in a mess.
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 :)
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
Am 05.01.2012 um 20:52 schrieb Stéphane Ducasse:
On Jan 4, 2012, at 3:59 PM, Norbert Hartl wrote:
Am 29.12.2011 um 23:04 schrieb Stéphane Ducasse:
Hi guys
I thought that XMLSupport was about parsing and XMLNode traversal. So why the configuration contains references to SIXX and Grease Core?
It is called XMLSupport. So it combines xml support technologies (otherwise it should be named ConfigurationOfXMLParsersAndDOM). I think Michael just dropped the name in and nobody changed it.
The presence of Sixx and the dependency of Grease is my duty (I'm intentionally not writing 'my faul't). I'm working a lot in GemStone and differences between the dialects are a real pain if you try to develop in pharo and deploy in GemStone. As we also need to exchange data we ported Sixx to GemStone. I've put Sixx in the configuration to keep the development of XML parser and Sixx close because Sixx relies on the interface of xml parser pretty much. As every module is a symbol there is no problem. And Sixx is not loaded by default.
I know what is SIXX but to me you should write a ConfigurationOfSixx, if each package move its clients close to him then we will end up in a mess.
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.
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 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. 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
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
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 :)
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. 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.
Believe me, nobody forces you to.
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.
If you load ConfigurationOfXMLSupport and use it _where_ do you see what is configured in there? 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! Norbert
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
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.
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 <stephane.ducasse@inria.fr
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.
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.
Am 06.01.2012 um 15:04 schrieb Stéphane Ducasse:
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.
Only if there is one guy per ConfigurationOf and we know that is not the case.
This is like switch vs polymorphism. Switch are cool because all the logic is in one place but we know the price.
Nice try! To me it appears to be more like having classes with only one method or make classes to do different things, e.g. have multiple methods. I can barely see something polymorphic in Configurations :)
Now if I want to have a jenkins system loading and running the tests of configurationOf then I prefer to have one per project.
Ah, you prefer?! Well, that's fine with me.
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.
That is my point. I don't defend a mechanic where too much things are in one configuration. But we are talking about having _two_ things in there with the ability to refactor it when time has come. But ok, we are (ok, I do) hairsplitting already and while we both have fun, everybody else might find this discussion ridiculous already. Let's wait for the next chance to have some fun! Norbert
participants (4)
-
Dale Henrichs -
Guillermo Polito -
Norbert Hartl -
Stéphane Ducasse