XML Parser updates
Locked
 
|
Hi,
I started to integrate the newest changes from squeaksource into the gemstone xml parser. Unfortunately the code is biased towards pharo now. It uses classes like Unicode, CharacterSet und ClassTestCase. I'm not sure what is the best way to deal with. I would really like to close the gap in between. I could add the classes to the pharo compat package but then the xml parser would depend on it and I don't like this. And I don't know if I like it better to alter the code so it isn't using the suspect classes. Any hints appreciated, Norbert |
|
|
2010/2/24 Norbert Hartl <[hidden email]>:
> Hi, > > I started to integrate the newest changes from squeaksource into the gemstone xml parser. Unfortunately the code is biased towards pharo now. It uses classes like Unicode, CharacterSet und ClassTestCase. I'm not sure what is the best way to deal with. > I would really like to close the gap in between. I could add the classes to the pharo compat package but then the xml parser would depend on it and I don't like this. And I don't know if I like it better to alter the code so it isn't using the suspect classes. Maybe I'm just not seeing the problem: - Unicode: just use Character instead - CharacterSet: just use a Set of Characters instead - ClassTestCase: just add it to SUnit on GemStone Cheers Philippe |
|
|
On 24.02.2010, at 19:19, Philippe Marschall wrote: Yes, I can modify all the code to make it run on gemstone. At this point it starts to become a fork. I'm interested in a solid base that an xml parser can evolve while being usable on different platforms. So I want to learn about ways how to leverage the dialect mismatches. There are many aspects to calculate into. And I'm interested to hear opinions. Thanks for yours! Norbert |
|
|
2010/2/24 Norbert Hartl <[hidden email]>:
> > On 24.02.2010, at 19:19, Philippe Marschall wrote: > > 2010/2/24 Norbert Hartl <[hidden email]>: > > Hi, > > I started to integrate the newest changes from squeaksource into the > gemstone xml parser. Unfortunately the code is biased towards pharo now. It > uses classes like Unicode, CharacterSet und ClassTestCase. I'm not sure what > is the best way to deal with. > > I would really like to close the gap in between. I could add the classes to > the pharo compat package but then the xml parser would depend on it and I > don't like this. And I don't know if I like it better to alter the code so > it isn't using the suspect classes. > > Maybe I'm just not seeing the problem: > - Unicode: just use Character instead > - CharacterSet: just use a Set of Characters instead > - ClassTestCase: just add it to SUnit on GemStone > > Yes, I can modify all the code to make it run on gemstone. At this point it > starts to become a fork. I'm interested in a solid base that an xml parser > can evolve while being usable on different platforms. So I want to learn > about ways how to leverage the dialect mismatches. There are many aspects to > calculate into. And I'm interested to hear opinions. Thanks for yours! > Norbert Yes it will be a fork but: - Changes will be minimal, at most a handful of methods. At least that's my impression from the Unicode and CharacterSet users. - Maintaining the fork is not that much work. More or less just hitting merge in Monticello. What would be interesting to know what the upstream developers of the XML parser think about GemStone compatibility. Cheers Philippe |
|
|
On 24.02.2010, at 20:51, Philippe Marschall wrote: > 2010/2/24 Norbert Hartl <[hidden email]>: >> >> On 24.02.2010, at 19:19, Philippe Marschall wrote: >> >> 2010/2/24 Norbert Hartl <[hidden email]>: >> >> Hi, >> >> I started to integrate the newest changes from squeaksource into the >> gemstone xml parser. Unfortunately the code is biased towards pharo now. It >> uses classes like Unicode, CharacterSet und ClassTestCase. I'm not sure what >> is the best way to deal with. >> >> I would really like to close the gap in between. I could add the classes to >> the pharo compat package but then the xml parser would depend on it and I >> don't like this. And I don't know if I like it better to alter the code so >> it isn't using the suspect classes. >> >> Maybe I'm just not seeing the problem: >> - Unicode: just use Character instead >> - CharacterSet: just use a Set of Characters instead >> - ClassTestCase: just add it to SUnit on GemStone >> >> Yes, I can modify all the code to make it run on gemstone. At this point it >> starts to become a fork. I'm interested in a solid base that an xml parser >> can evolve while being usable on different platforms. So I want to learn >> about ways how to leverage the dialect mismatches. There are many aspects to >> calculate into. And I'm interested to hear opinions. Thanks for yours! >> Norbert > > Yes it will be a fork but: > - Changes will be minimal, at most a handful of methods. At least > that's my impression from the Unicode and CharacterSet users. > - Maintaining the fork is not that much work. More or less just > hitting merge in Monticello. > > What would be interesting to know what the upstream developers of the > XML parser think about GemStone compatibility. > Me too, I wrote him an email a few hours ago. We'll see. Norbert |
|
|
I don't know this XML Parser, but I think I get the idea of the problem.
Hmmm... it may be necessary to modify parts of the XML Parser design to make it more 'portable'. It comes to my mind the Abstract Factory pattern by GOF. Maybe a few simple factories could do the trick: you could split the XML Parser package into two (the base code and the specific platform code).
In the specific platform package you can include your (let's say) Gemstone's XMLParserComponentsFactory class, which in the moment it loads and initialices sets somewhere in the XML Parser framework an instance of itself. Then, you can ask the factory (this instance that is auto-set) for the pieces you need to parse the XML and might change from platform to platform. I imagine some XMLParser package and GemstoneXMLParserComplement package, PharoXMLParserComplement package, etc... and you choose the one you need.
There would have to study the package and think about what is necessary to delegate to the factory. I guess it may be more of a design challenge than a "tecnology" challenge, and if I'm thinking right, it shouldn't be a tough challenge at all.
What do you think? Carla. On Wed, Feb 24, 2010 at 6:28 PM, Norbert Hartl <[hidden email]> wrote:
|
|
|
Hi Carla,
On 25.02.2010, at 03:27, Carla F. Griggio wrote: I don't know this XML Parser, but I think I get the idea of the problem.At the moment I think it is a communication challenge. The outcome of this is what the actual developers of the package agree upon. I find this most of the time more appropriate than to try to solve in a technical manner. Thanks for your input. As I stated the intention of my mail was to harvest opinions about the porting method. The differences in the code are as phillipe said quite minimal. It is most of the time a different class or a different method being used. The code surrounding this differences is the same. With abstract factory you can exchange whole class hierarchies for processing. I don't think this is needed here but I'm sure it would make the code unnecessarily complex. Therefor it would worsen the code. Btw. the abstract factory and factory patterns are popular in java where it is needed. In smalltalk where classes are objects and method calls are message sends I don't see much need for an abstract factory pattern. The factory pattern we use all the time without naming it. The popular factories in smalltalk are classes. If you want to solve this problem with patterns then I think template method and delegation are your friends. I thought about this. My best idea so far is to have separate methods for platform specific code. There could be a core package of the parser and platform specific packages that add the necessary methods through extensions. I'm quite sure it won't solve all of the problems. And then phillipe is right again. It would add more complexity and work then just to fork of the package. It is hard to decide and that was the reason for asking. thanks, Norbert
|
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |