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

Tue May 17 10:40:16 PDT 2022

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/02d821e5/attachment-0001.htm>