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 < marcel.taeumel@student.hpi.uni-potsdam.de> wrote:
At the moment, programmers can do three things with message categories:
- Define their name.
- Define their content.
- 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