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

Hernan Wilkinson hernan.wilkinson at 10pines.com
Tue May 17 10:22:52 PDT 2022


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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220517/12e7fb86/attachment-0001.htm>


More information about the Cuis-dev mailing list