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?

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:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 18.03.2015, at 15:11, commits at source.squeak.org wrote:
>>>>>
>>>>>> A new version of Tools was added to project The Inbox:
>>>>>> http://source.squeak.org/inbox/Tools-topa.556.mcz
>>>>>>
>>>>>> ==================== Summary ====================
>>>>>>
>>>>>> Name: Tools-topa.556
>>>>>> Author: topa
>>>>>> Time: 18 March 2015, 4:09:54.221 pm
>>>>>> UUID: 563dd431-ffbf-43b8-b78f-79a7a55f924d
>>>>>> Ancestors: Tools-topa.555
>>>>>>
>>>>>> Pluggable Menus for many tools
>>>>>> ==============================
>>>>>>
>>>>>> A lot of tools, especially the Browser, rely on context menus
>>>>>> (aka yellow button menus). Dynamically extending these is possible
>>>>>> but requires a lot of care. The Pluggable Menus allow to add menu
>>>>>> entries easily via extension methods. The Services package serves
>>>>>> as example here.
>>>>>
>>>>> An easier to read version of the commit message is at https://gist.github.com/krono/5f7f5197df5f1d1da052.
>>>>>
>>>>> If nobody objects, I move this to trunk on friday :)
>>>>>
>>>>> Best
>>>>> 	-Tobias
>
>
>
>