Marcel Taeumel uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-mt.534.mcz ==================== Summary ==================== Name: Tools-mt.534 Author: mt Time: 27 February 2015, 2:20:38.006 pm UUID: 32d3e256-db49-0d41-93f1-a9fa25c8d623 Ancestors: Tools-topa.533 Auto-sort message category list in System Browser. Does not affect internal order of categories in class organization. Only a view thing. Makes 'alphabetize' in the menu somewhat obsolete for this column. Saves some mouse clicks. However, hides insertion order of message categories. Not that important, right? :-) =============== Diff against Tools-topa.533 =============== Item was changed: ----- Method: Browser>>messageCategoryList (in category 'message category list') ----- messageCategoryList "Answer the selected category of messages." self hasClassSelected + ifTrue: [^ (Array with: ClassOrganizer allCategory), self classOrMetaClassOrganizer categories sorted] - ifTrue: [^ (Array with: ClassOrganizer allCategory), self classOrMetaClassOrganizer categories] ifFalse: [^ Array new]! |
On Fri, 27 Feb 2015, [hidden email] wrote:
> Marcel Taeumel uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-mt.534.mcz > > ==================== Summary ==================== > > Name: Tools-mt.534 > Author: mt > Time: 27 February 2015, 2:20:38.006 pm > UUID: 32d3e256-db49-0d41-93f1-a9fa25c8d623 > Ancestors: Tools-topa.533 > > Auto-sort message category list in System Browser. Does not affect internal order of categories in class organization. Only a view thing. Makes 'alphabetize' in the menu somewhat obsolete for this column. Saves some mouse clicks. > > However, hides insertion order of message categories. Not that important, right? :-) Some people prefer to see the order they defined. Levente > > =============== Diff against Tools-topa.533 =============== > > Item was changed: > ----- Method: Browser>>messageCategoryList (in category 'message category list') ----- > messageCategoryList > "Answer the selected category of messages." > > self hasClassSelected > + ifTrue: [^ (Array with: ClassOrganizer allCategory), self classOrMetaClassOrganizer categories sorted] > - ifTrue: [^ (Array with: ClassOrganizer allCategory), self classOrMetaClassOrganizer categories] > ifFalse: [^ Array new]! > > > |
In reply to this post by commits-2
On 27.02.2015, at 13:20, [hidden email] wrote: > Marcel Taeumel uploaded a new version of Tools to project The Trunk: > http://source.squeak.org/trunk/Tools-mt.534.mcz > > ==================== Summary ==================== > > Name: Tools-mt.534 > Author: mt > Time: 27 February 2015, 2:20:38.006 pm > UUID: 32d3e256-db49-0d41-93f1-a9fa25c8d623 > Ancestors: Tools-topa.533 > > Auto-sort message category list in System Browser. Does not affect internal order of categories in class organization. Only a view thing. Makes 'alphabetize' in the menu somewhat obsolete for this column. Saves some mouse clicks. > > However, hides insertion order of message categories. Not that important, right? :-) I think there are people that care over the message category order? Why force alphabetic? Best -Tobias |
I prefer to have common category such as "accessing" at the top. Particular orders are single-developer only. Team development gets difficult, I guess. Doing linear search in each and every class is hard and annoying. :-)
We could make it a preference then, but I vote for enabling it by default. What would developers want to bother sorting method categories on their own? Encoding some secret path through the code? I suppose it is hardly discoverable by other developers. Sorting things alphabetically is a common thing and lets you as a user perform binary search quickly. Best, Marcel |
At the moment, programmers can do three things with message categories:
1. Define their name. 2. Define their content. 3. Define their order. Naming is already difficult. Finding the right place for a message can be challenging, too. The thing is that order gets messed up pretty quickly. For example, extension categories just popup somewhere in between depending on the projects you have installed. My general impression is often that those categories just have *some* order and *want* to be alphabetized to make any sense out of it. I am not sure but w/o describing the intent of an order, it may just appear bogus to a programmer. Personally, I am really happy with anything that I do not have to organize or care for. Message category orders are such a thing. :-) But don't get me wrong: I don't want to push my personal expriences onto everybody. Let's discuss it here. ;-) Best, Marcel |
On 2/27/15, 3:02 PM, "Marcel Taeumel" <[hidden email]> wrote: > At the moment, programmers can do three things with message categories: > > 1. Define their name. > 2. Define their content. > 3. Define their order. > > Naming is already difficult. Finding the right place for a message can be > challenging, too. > > The thing is that order gets messed up pretty quickly. For example, > extension categories just popup somewhere in between depending on the > projects you have installed. > > My general impression is often that those categories just have *some* order > and *want* to be alphabetized to make any sense out of it. >I am not sure but > w/o describing the intent of an order, it may just appear bogus to a > programmer. > > Personally, I am really happy with anything that I do not have to organize > or care for. Message category orders are such a thing. :-) > > But don't get me wrong: I don't want to push my personal expriences onto > everybody. Let's discuss it here. ;-) > > Best, > Marcel vote ? Edgar |
In reply to this post by marcel.taeumel (old)
I didn't realize this was for method categories too because you said
the "System Browser", which I almost never use.. This actually affects every browser with a message-category list. The type of ordering I like to do for message protocols is "usage order". For example: setup build summarize private In this object, you have to do a "setup" before you can "build". You have to "build" before you can "summarize". Alphabetical order blows that up and now puts private in the middle instead of at the bottom, where I prefer it to be.. Marcel, I hope you'll forgive me for saying, this type of thing which affect others' daily development are good to negotiate from the Inbox instead of trunk because going straight to trunk guarantees a lot more "trial" or "interim" versions in our trunk history instead of only "finished" versions (reducing the density of the historical record). > I prefer to have common category such as "accessing" at the top. That's what "alphabetize" is for. :) > Particular > orders are single-developer only. Team development gets difficult, > I guess. > Doing linear search in each and every class is hard and annoying. :-) No list in Squeak ever needs to be linearly-scanned by ones eyes if you simply type a few letters of the list entry you want right in the list. The Filter feature remember? That's what I use all the time regardless if a list is already alphabetized, because it also performs the navigation for me. Alphabetizing a list does very little to improve my access to it, thanks to the list-Filtering feature. > We could make it a preference then, but I vote for enabling it by default. I vote for disabled by default. Because not only would "alphabetize" be rendered obsolete I guess "reorganize" as well..? > What would developers want to bother sorting method categories on their own? > Encoding some secret path through the code? I suppose it is hardly > discoverable by other developers. My above example helps me with my *own* code which I wrote years ago. I come into a class I wrote years ago, I see the order of the message categories, and I have an immediate "summary" of how this kind of object is supposed to be used. The order conveys information about usage, I love it. > Sorting things alphabetically is a common thing and lets you as a user > perform binary search quickly. Which is still much slower and more laborious than simply using the Filter feature. Disabled by default please. :) |
In reply to this post by marcel.taeumel (old)
On Sat, Feb 28, 2015 at 08:50:33AM -0800, Marcel Taeumel wrote:
> Let's try it then: http://vote.pollcode.com/82581991 > > Best, > Marcel > Ha! I just voted, and it looks like the number of different opinions exactly matches the number of people who have voted so far. If we could get one more person to vote, then stop the election, we would have a decision ;-) Joking aside, there is something to be said for taking of poll to find out what most people want, without regard for who has the loudest opinion. So folks - if you have an opinion on this topic, please follow the link above and click on your preference. Dave |
On 2/28/15, 3:17 PM, "David T. Lewis" <[hidden email]> wrote: > On Sat, Feb 28, 2015 at 08:50:33AM -0800, Marcel Taeumel wrote: >> Let's try it then: http://vote.pollcode.com/82581991 >> >> Best, >> Marcel >> > > Ha! I just voted, and it looks like the number of different opinions > exactly matches the number of people who have voted so far. > > If we could get one more person to vote, then stop the election, we > would have a decision ;-) > > Joking aside, there is something to be said for taking of poll to find > out what most people want, without regard for who has the loudest opinion. > > So folks - if you have an opinion on this topic, please follow the link > above and click on your preference. > > Dave Edgar |
On Sat, Feb 28, 2015 at 03:53:47PM -0300, Edgar J. De Cleene wrote:
> > On 2/28/15, 3:17 PM, "David T. Lewis" <[hidden email]> wrote: > > > On Sat, Feb 28, 2015 at 08:50:33AM -0800, Marcel Taeumel wrote: > >> Let's try it then: http://vote.pollcode.com/82581991 > >> > >> Best, > >> Marcel > >> > > > > Ha! I just voted, and it looks like the number of different opinions > > exactly matches the number of people who have voted so far. > > > > If we could get one more person to vote, then stop the election, we > > would have a decision ;-) > > > > Joking aside, there is something to be said for taking of poll to find > > out what most people want, without regard for who has the loudest opinion. > > > > So folks - if you have an opinion on this topic, please follow the link > > above and click on your preference. > > > > Dave > Just voted. Maybe 8 members on this list are still alive... :) > > Edgar > We old people have to vote early, just in case ;-) Dave |
In reply to this post by marcel.taeumel (old)
> What would developers want to bother sorting method categories on their own?
The desire to auto-sort them is understandable when thinking about Squeak as an eclipse-style IDE for teams of Developers. But there is another way to think about Squeak: as a system for presenting naked-objects applications to Users. The goal of Maui is to expose as much of a Smalltalk code-model as possible, as an "application" to a User actor. It generates a default panel for any object suitable for a User actor to interact with its behaviors. The "tabs" of this default panel are simply the message categories in the order of their Organization in the system. So being able to see and customize that order affords the Developer actor another channel, right within her own IDE, for customizing the default panel UI. I hope you are convinced there are use-cases for both sorting and not sorting. I don't think we can get away without a preference. maui-example.png (30K) Download Attachment |
In reply to this post by Chris Muller-3
I know and support this scenario. To avoid messing up such an order, you could/should prepend "1 - ...", "2 - ..." etc. to your categories. Otherwise this is quite unstable. I guess. :) See RBParser, for example. They do it with A/B/C for documenting categories. I will make it a preference and disable it by default. Best, Marcel |
In reply to this post by Chris Muller-3
On 28.02.2015, at 09:58, Chris Muller <[hidden email]> wrote:
> > The type of ordering I like to do for message protocols is "usage > order". For example: > > setup > build > summarize > private > > In this object, you have to do a "setup" before you can "build". You > have to "build" before you can "summarize". Alphabetical order blows > that up and now puts private in the middle instead of at the bottom, > where I prefer it to be.. We do have a problem with Monticello, which often messes up the order. I agree with Marcel that alphabetic is better than random, but a careful manual order is much better than alphabetic. You may need to have worked in a pre MC image for a while to appreciate that. - Bert - smime.p7s (8K) Download Attachment |
In reply to this post by marcel.taeumel (old)
Hi Marcel,
On Fri, Feb 27, 2015 at 10:02 AM, Marcel Taeumel <[hidden email]> wrote: At the moment, programmers can do three things with message categories: Personally I find ordering of protocols really helpful for productivity, especially with complex classes such as the VM's interpreter classes. These are >100 method classes. I do things like put all the bytecode protocols, stack bytecodes, send bytecodes, return bytecodes, etc, next to each other (which of course doesn't work with alphabetization unless one rewrites to bytecodes-stack etc). I was /mortified/ the first time I loaded VMMaker into a clean image because Monticello *does not record protocols order*. I wish this would be fixed. I find myself alphabetising and then, for certain classes, such as the interpreter, carefully putting things in order. This is wasted effort. Monticello really should preserve order. I have no objection to a preference that tells the browser to display protocols alphabetically. Please don't make it the default. When we did this for VisualWorks (I think it was Vassili Bykov) we ordered initialize protocols at the top, private protocols at the bottom, and everything else in the middle.
best,
Eliot |
On Mon, Mar 02, 2015 at 09:22:14PM -0800, Eliot Miranda wrote:
> Hi Marcel, > > On Fri, Feb 27, 2015 at 10:02 AM, Marcel Taeumel < > [hidden email]> wrote: > > > At the moment, programmers can do three things with message categories: > > > > 1. Define their name. > > 2. Define their content. > > 3. Define their order. > > > > Naming is already difficult. Finding the right place for a message can be > > challenging, too. > > > > The thing is that order gets messed up pretty quickly. For example, > > extension categories just popup somewhere in between depending on the > > projects you have installed. > > > > My general impression is often that those categories just have *some* order > > and *want* to be alphabetized to make any sense out of it. I am not sure but > > w/o describing the intent of an order, it may just appear bogus to a > > programmer. > > > > Personally, I am really happy with anything that I do not have to organize > > or care for. Message category orders are such a thing. :-) > > > > But don't get me wrong: I don't want to push my personal expriences onto > > everybody. Let's discuss it here. ;-) > > > > Personally I find ordering of protocols really helpful for productivity, > especially with complex classes such as the VM's interpreter classes. > These are >100 method classes. I do things like put all the > bytecode protocols, stack bytecodes, send bytecodes, return bytecodes, etc, > next to each other (which of course doesn't work with alphabetization > unless one rewrites to bytecodes-stack etc). I was /mortified/ the first > time I loaded VMMaker into a clean image because Monticello *does not > record protocols order*. I wish this would be fixed. This does seem like something we should fix. But is it a Monticello issue? If I file out a class, the only thing in that fileout that seems to define the order of the protocols is the order in which the methods were filed out. If I alphabetize the protocols, and file that same class out again, there is no explicit declaration of the order of the protocols. The methods just appear in the fileout in whatever order they had been organized in the image. I am guessing that what we would want is some kind of ClassChangeRecord that declares a reorganization of the protocols, and that appears in change sets, fileouts, and Monticello updates. I am not sure if it is practical to do this in a backward compatible manner, but at first glance this seems to be the missing piece that would be needed to support declarative protocol organizations that could be preserved in Monticello. Dave |
Free forum by Nabble | Edit this page |