[squeak-dev] The Inbox: Tools-topa.556.mcz

Tobias Pape Das.Linux at gmx.de
Mon Mar 23 19:37:49 UTC 2015


On 23.03.2015, at 18:25, Levente Uzonyi <leves at elte.hu> wrote:

> The focus of this thread shifted towards performance, but that was just an advantage of using one "pragma" instead of two (or more).
> My question about the implementation was:
> 
>> Is there any advantage of using two "pragmas", instead of one?
> 
> You pointed out one such advantage: it keeps the simplest use case very simple.
> But do priorities add much complexity?
> For example: is <myMenu> - from the user's point of view - significantly simpler than <myMenu: 500> or <myMenu: nil> or <myMenu: #defaultPriority>?
> How common is this use case? How often will people not want to tweak the priority, but use the alphabetical sort order instead?
> 

My view is:
I just want to add a menu entry. I am out of control what else
goes into the menu in any case, so _typically_ I want my
menu entry (or submenu) just show up. And yes, just putting <messageListMenu> there
is imho significantly simpler than having to think about
	<myMenu: 500> or <myMenu: nil> or <myMenu: #defaultPriority> 
because that tries to convey two concerns with one message. it also
reads strange. What read better would be
	<myMenuWithPriority: 500> or <myMenuWithPriority: #default>
(I cannot transform you <myMenu: nil> to a better-reading version,
probably that is too low-level?)

Best
	-Tobias

> Levente
> 
> On Mon, 23 Mar 2015, Tobias Pape wrote:
> 
>> 
>> On 23.03.2015, at 11:43, Levente Uzonyi <leves at elte.hu> wrote:
>> 
>>> On Mon, 23 Mar 2015, Tobias Pape wrote:
>>> 
>>>> Hi Levente,
>>>> 
>>>> [Sorry for the late reply]
>>>> 
>>>> 
>>>> On 19.03.2015, at 23:39, Levente Uzonyi <leves at elte.hu> wrote:
>>>> 
>>>>> The implementation looks very similar to what Balázs did back in 2010 to the Docking Bar[1], even though his changes never made it into the Trunk.
>>>>> One main difference I see is that he used a single "pragma", instead of two separate "pragmas". Performance-wise a single "pragma" is better. Is there any advantage of using two "pragmas", instead of one?
>>>>> 
>>>> 
>>>> In spirit, these implementations indeed are similar. Balázs' code however
>>>> only deals with the World main docking bar while _this_ proposal deals
>>>> with context menus in tools like the browser.
>>> 
>>> That's exactly what I meant. My point is that the two should be quite similar.
>>> 
>>>> 
>>>> I don't understand what you mean by “Performance-wise a single "pragma" is better”.
>>>> Can you elaborate a bit?
>>> 
>>> Using two separate "pragmas" means that you have to look up the priority in a separate query for each entry. While using a single "pragma", the priority is available without these extra lookups.
>>> 
>> 
>> Ok, I thought you meant that.
>> The point is that I want to make the simple case (just a menu)
>> very simple:
>> 
>> 	• Create an instance of MenuMorph or similar.
>> 	• Create a method that should build the menu entries:
>> 		someMenu: aMenu
>> 		    <myMenu>
>> 		    ^ aMenu addList: #(
>> 		            ('use'      use)
>> 		            ('remove'   remove)
>> 		            ('copy'     copyName));
>> 		        yourself
>> 	• Send `self menu: aMorph for: #myMenu`
>> 
>> (that should be it) but complex cases possible nonetheless.
>> 
>> I don't want to bother the average tool writer with shifted states, priorities or whatnot.
>> I have seen Pragma>>allNamed:in:sortedByArgument:, but I cannot handle
>> default values with that.
>> 
>> Do you think performance is actually a bottleneck here?
>> 
>> Best
>> 	-Tobias
>> 
>> 
>>> Levente
>>> 
>>>> 
>>>> Best
>>>> 	-Tobias
>>>> 
>>>> 
>>>>> Levente
>>>>> 
>>>>> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/149345.html
>>>>> 
>>>>> On Wed, 18 Mar 2015, Tobias Pape wrote:




More information about the Squeak-dev mailing list