[Cuis-dev] Parser gets confused when using $| in binary selectors

Wed May 18 01:37:19 PDT 2022

Ah, of course inspectors and debugger don’t need this option, they use
‘self class parserClass’. But I wouldn’t add this option to the workspace,
it seems unnecessary, who would need to open several workspaces with
different parser settings?

I think it would be better to reach consensus on a reasonable default
(#st80?), and make it easy for people to change it if they want (in their
own packages, by subclassing Parser and implementing #parserClass for
example). Also, #parserClass would have to be saved first when saving
packages, I think Juan recently changed this in CodePackage to avoid losing
the ordering of message categories…

On Wed, 18 May 2022 at 12:40 AM Luciano Notarfrancesco <luchiano at gmail.com>
wrote:

> I think we can make it easy enough so that someone who wants to use a
> parser other than the default can do it, but without making more
> subclasses. Just move the preference to a class method in the parser, for
> example, so anyone can subclass it and reimplement that method and then
> implement #parserClass in their classes. About workspace, inspectors,
> debugger, etc, I wouldn’t add complexity for this particular issue, its
> easy enough to change the default parser to a new subclass if anyone wants
> to do it. IMHO.
>
>
> On Wed, 18 May 2022 at 12:29 AM Nicolás Papagna Maldonado via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>>
>>
>> On Tue, May 17, 2022 at 2:23 PM Hernan Wilkinson <
>> hernan.wilkinson at 10pines.com> wrote:
>>
>>> I like this idea better than the preferences... That is a good point. I
>>> would not work on the workspace though unless you subclass workspace and
>>> redefine the message to use the other parser... But I kind of like it more.
>>>
>>
>> In that case, we could have some UI component (a dropdown or something
>> like that) to allow users to select the parser for that particular
>> workspace instance.
>> What do you think?
>>
>>
>>>
>>> On Tue, May 17, 2022 at 1:31 PM Nicolás Papagna Maldonado via Cuis-dev <
>>> cuis-dev at lists.cuis.st> wrote:
>>>
>>>> Hi folks!
>>>>
>>>> I'm somewhat late to the party. I went through the discussion and what
>>>> worries me about the current proposal is that loading packages or filing in
>>>> code that was developed under a particular setting might break in other
>>>> images.
>>>> Also, this opens the door for creating other settings for the language,
>>>> making it more difficult to understand or extend (IMHO).
>>>>
>>>> My $0.02: how about using the machinery we already have, and letting
>>>> classes define their parser by overriding #parserClass?
>>>> That way, we can use any parser we want (and customize it to tailor our
>>>> needs) and it'll play nice (i think) with file outs and packages.
>>>>
>>>> Best,
>>>> Nico PM
>>>>
>>>> On Sat, May 14, 2022 at 12:50 PM Juan Vuletich via Cuis-dev <
>>>> cuis-dev at lists.cuis.st> wrote:
>>>>
>>>>> On 5/14/2022 4:13 AM, Hilaire Fernandes via Cuis-dev wrote:
>>>>>
>>>>> Yes it is fine.
>>>>>
>>>>> I am wondering: when executing "PreferenceNG initialize" in an image
>>>>> with vector graphics it seems to break the image. I guess a race condition.
>>>>>
>>>>> To avoid this situation, I suggest you edit this method as follow:
>>>>>
>>>>> PreferenceNG>>initialize
>>>>>     ThePreferences ifNil: [ThePreferences _ Dictionary new].
>>>>> ...
>>>>>
>>>>> It will allow to add the new preferences from the data array and reset
>>>>> the existing ones with the default values from the array (this what happen
>>>>> when requesting a new preference already in the system, it just updates the
>>>>> existing one). A few limitation:
>>>>>
>>>>>    - It will not migrate type of existing preference (should be done
>>>>>    by hand by inspecting the object or removing the whole preference and
>>>>>    initialize again), I prevent it by purpose so a user does not mess up with
>>>>>    the type.
>>>>>    - it will not remove deprecated preferences (the ones not anymore
>>>>>    in the data array). Should be removed by hand.
>>>>>
>>>>> Hilaire
>>>>> Le 13/05/2022 à 22:42, Juan Vuletich via Cuis-dev a écrit :
>>>>>
>>>>> Hilaire, please check that the use of Preference NG is reasonable.
>>>>>
>>>>> --
>>>>> GNU Dr. Geohttp://drgeo.euhttp://blog.drgeo.eu
>>>>>
>>>>>
>>>>> I think that #initialize should discard everything and start anew.
>>>>>
>>>>> Please review the attach. It creates a new dictionary, populates it,
>>>>> and only then installs it as the new ThePreferences. This is a pattern that
>>>>> has been used in Squeak/Cuis many times.
>>>>>
>>>>> BTW, I removed #select:, and renamed #all to #allPreferences. I think
>>>>> this makes the stuff easier to find with senders/implementors (by reducing
>>>>> false polymorphism). I kept your author initials, as this is essentially
>>>>> just some refactoring.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3https://independent.academia.edu/JuanVuletichhttps://www.researchgate.net/profile/Juan-Vuletichhttps://patents.justia.com/inventor/juan-manuel-vuletichhttps://twitter.com/JuanVuletich
>>>>>
>>>>> --
>>>>> Cuis-dev mailing list
>>>>> Cuis-dev at lists.cuis.st
>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Nicolás Papagna
>>>> --
>>>> Cuis-dev mailing list
>>>> Cuis-dev at lists.cuis.st
>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>
>>>
>>>
>>> --
>>> <https://10pines.com/>Hernán WilkinsonSoftware Developer & Coach
>>>
>>> Alem 896, Floor 6, Buenos Aires, Argentina
>>>
>>> +54 11 6091 3125
>>>
>>> @HernanWilkinson
>>>
>>
>>
>> --
>>
>> Nicolás Papagna
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220518/717f7ce4/attachment.htm>