Discussion:
[squeak-dev] The Trunk: Tools-mt.534.mcz
c***@source.squeak.org
0000-03-03 19:11:21 UTC
Permalink
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]!
Levente Uzonyi
2015-02-27 13:32:13 UTC
Permalink
Post by c***@source.squeak.org
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
Post by c***@source.squeak.org
=============== Diff against Tools-topa.533 ===============
----- 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]!
Tobias Pape
2015-02-27 16:03:19 UTC
Permalink
Post by c***@source.squeak.org
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
Marcel Taeumel
2015-02-27 17:35:21 UTC
Permalink
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



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-534-mcz-tp4808262p4808402.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
Marcel Taeumel
2015-02-27 18:02:24 UTC
Permalink
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



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-534-mcz-tp4808262p4808408.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
Eliot Miranda
2015-03-03 05:22:14 UTC
Permalink
Hi Marcel,

On Fri, Feb 27, 2015 at 10:02 AM, Marcel Taeumel <
Post by Marcel Taeumel
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. 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.
Post by Marcel Taeumel
Best,
Marcel
--
http://forum.world.st/The-Trunk-Tools-mt-534-mcz-tp4808262p4808408.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
--
best,
Eliot
David T. Lewis
2015-03-04 00:45:05 UTC
Permalink
Post by Eliot Miranda
Hi Marcel,
On Fri, Feb 27, 2015 at 10:02 AM, Marcel Taeumel <
Post by Marcel Taeumel
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

Chris Muller
2015-02-28 17:58:29 UTC
Permalink
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).
Post by Marcel Taeumel
I prefer to have common category such as "accessing" at the top.
That's what "alphabetize" is for. :)
Post by Marcel Taeumel
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.
Post by Marcel Taeumel
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..?
Post by Marcel Taeumel
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.
Post by Marcel Taeumel
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. :)
Marcel Taeumel
2015-03-01 09:16:20 UTC
Permalink
Post by Chris Muller
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
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..
...
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



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-534-mcz-tp4808262p4808631.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
Bert Freudenberg
2015-03-01 18:02:10 UTC
Permalink
Post by Chris Muller
The type of ordering I like to do for message protocols is "usage
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..
+1

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 -
Chris Muller
2015-02-28 20:34:45 UTC
Permalink
Post by Marcel Taeumel
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.
Edgar J. De Cleene
2015-02-28 05:50:44 UTC
Permalink
On 2/27/15, 3:02 PM, "Marcel Taeumel"
Post by Marcel Taeumel
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.
+1
Post by Marcel Taeumel
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
If the question is if we need some preference for this, why do not a quick
vote ?
Edgar
Marcel Taeumel
2015-02-28 16:50:33 UTC
Permalink
Let's try it then: http://vote.pollcode.com/82581991

Best,
Marcel



--
View this message in context: http://forum.world.st/The-Trunk-Tools-mt-534-mcz-tp4808262p4808545.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
David T. Lewis
2015-02-28 18:17:26 UTC
Permalink
Post by Marcel Taeumel
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 J. De Cleene
2015-02-28 18:53:47 UTC
Permalink
Post by David T. Lewis
Post by Marcel Taeumel
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
David T. Lewis
2015-02-28 19:00:42 UTC
Permalink
Post by Edgar J. De Cleene
Post by David T. Lewis
Post by Marcel Taeumel
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
Loading...