Re: [Moose-dev] Re: XML Parser / Pastell

> I wanted to rename some of the handler messages in SAXHandler so  
> they would be more consistent with each other (note, for example,  
> the different argument order between  
> #startElement:namespaceURI:namesapce- and  
> #endElement:namespace:namespaceURI-) and also with other parts of  
> the API (-attributeList: vs. -atttributes:). Unfortunately, there is  
> no easy way to deprecate such messages. Users do not send them;  
> instead they override them in subclasses and expect the overridden  
> versions to be invoked by SAXDriver. Another problem is that the  
> handlers must degrade in a specific order, with each form invoking  
> the one taking the most arguments after it until the one taking the  
> fewest arguments (e.g., #startElement:attributes:) is reached.
>
> That unusual #forwardToDeprecatedHandler:withArgumentOrder:orTo:  
> message you discovered is the ad hoc solution. In renamed handlers  
> it checks to see if the old, deprecated version is implemented in  
> the class of the receiver and if it is, warns that it has been  
> deprecated and suggests using the new form--the caller--prior to  
> invoking the old form with the caller's arguments (reordered if  
> needed). If the deprecated version is not present, then it either  
> degrades in the normal fashion, invoking the version taking next-
> most arguments after itself (which may also check for a deprecated  
> version of itself) or do nothing if no other handler needs to be  
> invoked.
>
>>>
>>> The most recent version is completely string-based. The performance
>>> of the symbol-based predecessors was erratic; it would be terribly
>>> slow at first in a clean image and improve only after saving the
>>> image at least once. Even then my tests indicated that a purely
>>> string-based version would be faster. This is likely due to the
>>> initial overhead of interning symbols and then the subsequent
>>> overhead of looking them up. I did honestly prefer the #symbol
>>> syntax for naming things, but considering that the things so-named
>>> and the names themselves all begin life (from the tokenizer) as
>>> strings, it makes more sense (and requires less code) to keep them
>>> that way. It is also more portable, as we no longer need assume that
>>> Symbol is a subclass of String. I don't think this will cause issues
>>> in Squeak/Pharo code, as both systems (for now) assume #name =
>>> 'name'. Hopefully it will not cause too much trouble for Norbert.
>>>
>>> Alexandre, you should see an improvement in your benchmarks now.
>>
>> Indeed!
>> Cool!
>>
>> Alexandre
>>
>>>
>>>>>>> anElement attributes class (I wrote species but that will fail  
>>>>>>> in
>>>>>>> gemstone too I guess. Hell!)
>>>>>>
>>>>>> I just committed with species. Let me know. This is easy to  
>>>>>> adjust.
>>>>>>
>>>>> Ok.
>>>>>
>>>>>>>>> The gemstone XML Parser decides somehow to use
>>>>>>>>> IdentityDictionary internally. I think this should be  
>>>>>>>>> allowed. I
>>>>>>>>> just changed Dictionary to IdentityDictionary so the = test
>>>>>>>>> reflects the right type. If you change it it is clear that it
>>>>>>>>> fails. Because pharo uses Dictionary internally. So you might
>>>>>>>>> see that it is not a question of using Dictionary or
>>>>>>>>> IdentityDictionary but a question of the wrongness of using =
>>>>>>>>
>>>>>>>> How the XMLNodeTest should look like to accommodate your
>>>>>>>> situation?
>>>>>>>>
>>>>>>> I need to recheck this. The problem is really that the XML  
>>>>>>> Parser
>>>>>>> creatios instances of class Association but { #key->'value' }
>>>>>>> creates an instance of class SymbolAssociation. That means I  
>>>>>>> would
>>>>>>> know how to fix the test but I want to understand the  
>>>>>>> implications
>>>>>>> of all of this. I'll get to you if I know anything new.
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>> My mail to the gemstone list led to a ticket about removing class
>>>>> checks from Association. That would be easing the handling a lot.
>>>>>
>>>>> Norbert
>>>>>>>
>>>>>>>
>>>>>>>> Alexandre
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Here there is an assumption about the allAttributes  
>>>>>>>>>>> collection
>>>>>>>>>>> while using = as comparsion. But there is also an assumption
>>>>>>>>>>> about the order of the content. I changed this to
>>>>>>>>>>>
>>>>>>>>>>> self assert: (firstPerson allAttributes includesAllOf:
>>>>>>>>>>> #(#'first-name' #'employee-number' #'family-name')).
>>>>>>>>>>> self assert: (firstPerson allAttributeAssociations asArray
>>>>>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'-
>>>>>>>>>>>> 'A0000'). (#'family-name'->'Gates')}).
>>>>>>>>>>
>>>>>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do
>>>>>>>>>> the thing? Do you not test the size of the array.
>>>>>>>>>>
>>>>>>>>>>> This is not the best way to do because the check is only in
>>>>>>>>>>> one direction but for this test it is ok. Somehow the second
>>>>>>>>>>> assert fails and I have to check what is going on here.
>>>>>>>>>>
>>>>>>>>>> Yeah, my mistake. Sorry. The elements may be differently
>>>>>>>>>> ordered. Would a asSortedCollection help?
>>>>>>>>>>
>>>>>>>>>> I have now granted you an access to the repository. You  
>>>>>>>>>> should
>>>>>>>>>> be able to directly commit in it.
>>>>>>>>>>
>>>>>>>>>> Jaayer, what is your Squeaksource account?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Alexandre
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> thanks for now. I did a first merge attempt. It will be
>>>>>>>>>>>>> quite a bit of work. For me the xml parser is an important
>>>>>>>>>>>>> component. With the newest changes it became biased  
>>>>>>>>>>>>> towards
>>>>>>>>>>>>> pharo. There are things like ClassTestCase, Unicode
>>>>>>>>>>>>> CharacterSet. These are for sure improvements/changes in
>>>>>>>>>>>>> pharo you like to use. But they make porting a lot more
>>>>>>>>>>>>> difficult. I would be glad if we could find some way to
>>>>>>>>>>>>> lower the porting barrier. The necessary class I could put
>>>>>>>>>>>>> in the squeak compat package in gemstone. But then the xml
>>>>>>>>>>>>> parser will depend on the squeak package which I don't  
>>>>>>>>>>>>> like.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Norbert,
>>>>>>>>>>>>
>>>>>>>>>>>> XMLParser effectively depends on Squeak specific classes. I
>>>>>>>>>>>> wrote a small script that identify the squeak classes  
>>>>>>>>>>>> used in
>>>>>>>>>>>> XML-Support. Here is the list: LanguageEnvironment,  
>>>>>>>>>>>> Unicode,
>>>>>>>>>>>> LocaleID, CharacterSet
>>>>>>>>>>>>
>>>>>>>>>>>> I guess that porting the whole multilingual support may not
>>>>>>>>>>>> be that easy. The tag xml:lang is used to select the proper
>>>>>>>>>>>> support. It should be easy for you to ignore it I guess.
>>>>>>>>>>>>
>>>>>>>>>>>> CharacterSet seems to be one that has to be ported. It is  
>>>>>>>>>>>> not
>>>>>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure
>>>>>>>>>>>> whether this is useful in your case however.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Alexandre
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev