Hi, Sorry for the slow reaction.
Indeed, we would like to encourage the packaging of GT extensions in the same project as the code they extend. So, in this case, GT-InspectorExtensions-XML would be better suited to be in the PharoExtras/XMLParser repository under XML-Parser-GT-InspectorExtensions. Actually, given that most of these extensions are not more complicated than a printOn:, I would even argue that in many cases it would be more suitable to have them in the same package as the class they extend. I know it sounds like bad dependency management, but the GT-Inspector is here to stay (and the API will likely remain compatible in the future), so the risk is minimal and I think in many situations you will this approach more pragmatic. So, Ben: could you push the package as you described (only call it please XML-Parser-GT-InspectorExtensions)? Cheers, Doru On Sun, May 3, 2015 at 4:30 PM, Ben Coman <b...@openinworld.com> wrote: > > > On Sun, May 3, 2015 at 4:28 AM, stepharo <steph...@free.fr> wrote: > >> Hi ben >> >> we could update the configurationOfXMLReader. >> But the right solution is to define a new configuration loading GT-Tools, >> XMLReader and your extensions. >> In pharo 40 we could consider that GT-Tools is loaded. >> Now I think that making the dependencies explicit is important. >> >> >> So what do you think of... >> * Updating ConfigurationOfXMLParser to automatically load the extensions >> for Pharo4. >> * Moving the package into the XML-Parser repository so it sits next to >> other compatibility packages like XML-Parser-GemstoneCompatability -- and >> possibly renaming it something like XML-Parser-GT-Extensions. >> >> The package I maintain with monty is in PharoExtras so I would prefer not >> to change its location. >> > > I meant moving GT-InspectorExtensions-XML..mcz from Smalltalkhub > Moose/GToolkit > to Smalltalkhub PharoExtras/XMLParser renamed > XML-Parser-GTExtensions..mcz , > but that might not suit the GT Team. > > Actually in off-list correspondence with monty I learnt of > XMLPluggableElementFactory, which seems to suit my need better than my > proposed GT extensions for XMLParser. > cheers -ben > > > >> >> Stef >> >> >> >> >>> I would prefer to qualify the extensions by the tool they refer to: >>> GT-InspectorExtensions-*, GT-SpotterExtensions-* etc. >>> >>> gtDisplayOn: should be more in the inspector, but probably some were >>> added mostly in the spotter so they ended up in the less optimal package. >>> >> >> okay. good to understand. >> cheers -ben >> >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Sun, Apr 26, 2015 at 8:30 PM, Ben Coman <b...@openinworld.com> wrote: >>> >>>> I happened to need to use and XML Parser for the first time and found >>>> inspecting the structure awkward, so I added some GTInspector extensions to >>>> XML-Parser. This is uploaded as XML-Parser-BenComan.304 to >>>> http://smalltalkhub.com/#!/~PharoExtras/XMLParser. Could someone who >>>> uses XML regularly check if these are reasonable? >>>> >>>> Now should these methods be packaged separately somehow, since they >>>> are likely not of interest to other Smalltalk flavours? >>>> >>>> btw I gave them a protocol of "GT-Extensions" - but I also considered >>>> "moldable-tools" and "tools-extensions". If there a preference? This will >>>> likely be a common occurrence across the community, so we should try for a >>>> consistent convention across the community for such extensions. >>>> >>>> btw2, I notice that #gtDisplayOn: implementors are fairly evenly >>>> split between [GT-InspectorExtensions-Core] and >>>> [GT-SpotterExtensions-Core]. Are they really separated like this in their >>>> use? >>>> >>>> cheers -ben >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"
