The Trunk: Tools-mt.534.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Tools-mt.534.mcz

commits-2
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]!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Levente Uzonyi-2
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]!
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Tobias Pape
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

marcel.taeumel (old)
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

marcel.taeumel (old)
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Edgar De Cleene



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.
+1

>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



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

marcel.taeumel (old)
Let's try it then: http://vote.pollcode.com/82581991

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Chris Muller-3
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.   :)

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

David T. Lewis
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
 

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Edgar De Cleene



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



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Chris Muller-3
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

marcel.taeumel (old)
In reply to this post by Chris Muller-3
Chris Muller-3 wrote
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..

...
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
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Bert Freudenberg
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..
+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 -


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Tools-mt.534.mcz

Eliot Miranda-2
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:

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.

 

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.




--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Protocols ordering (was: The Trunk: Tools-mt.534.mcz)

David T. Lewis
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