> 	1. It's extremely easy to add registries when a need comes up.  Thus
> there is no hurry to do it.
But adding them individually right now means that code is repeated, and
tricks are not shared. I think the open menu now sorts its entries. Are
you sure the debugger registry do so too? 

Now that we have a couple of cases, and have learned from them, it might
be worth applying what we learned to a general system.

> 	2. Registries remove the chance for a human touch, and leave things to
> be organized by an algorithm.
Except an algorithm can be guided by a human touch... Theres nothing
preventing us from being a bit smarter about the orderings and groupings
possible, if we do it in one place. Do you want them sorted? do you want
the ability to specify that "this new menu item should be in the same
group as that old one"? maybe you want the user to be able to reorder
them as he wishes? all doable. First we need to decide what helps, and
then put it in the menu extension mechanism.

> 	3. Registries add inertia and make a lot of simple hacks more
> complicated.  Any code touching the registryized part of the system,
> must now work under more general assumptions.
I agree we should not make everything extendible - the things I've
mentioned are things that have caused me specifically some pain, and I'm
asking what things have hurt other people. And also I think we should
have a wider vocabulary and smarter mechanisms for extension, that cause
less of the kind of pain you're talking about.

Ideas?

[something good about somewhat fixed keybindings]
Ok, I think right now we're a little on the over rigid side here...
remember that just because something is extendible doesn't mean that it
*will* be changed all the time. EMACS is very extendible, but the
important keybindings are so fixed other systems can have an "emacs key
bindings" extension without embarrassing themselves...

Daniel

Lex Spoon <lex at cc.gatech.edu> wrote:
> Bijan Parsia <bparsia at email.unc.edu> wrote:
> > On Mon, 14 Jul 2003, Lex Spoon wrote:
> > 
> > > IMHO, we should add hooks sparingly and as we need them.  We don't
> > > really want everything to be customizable.
> > 
> > Piffle. What "we" can you possibly be talking about
> 
> We are all Borg.  The Bijan entity simply does not realize this yet. 
> Squeak and its users move forward as a unified whole, always taking the
> most logical step and never disagreeing.
> 
> 
> 
> > 
> > [snip]
> > > I don't see a good case for extensible key strokes in the text editor.
> > > There shouldn't be many extensions, because Squeak only has 1-character
> > > key combinations.
> > 
> > I've often wanted to change, augment, or override squeaks key commands for
> > specific projects/editors/etc. All the time, in fact. It's horrifically
> > painful as it stands.
> 
> Okay, I'm with you, but there's a big difference between adding
> keystrokes for your specific editor, and adding keystrokes system wide.
> 
> Just consider: when you write your application, wouldn't you like to
> know what keys are being used in the main, plain-vanilla text editor, so
> that you don't hide a useful keystroke with one of your custom ones?  
> Well, if you'd like to know this, then there had better not be people
> registering stuff in the system-wide keymap.
> 
> Maybe I just misunderstand the proposal.  Having app-specific keymaps is
> fine.  I wouldn't call that a registry, though.  Notice that the app
> writer will know exactly what keys are bound to what.
> 
> 
> > >  (Which seems fine, btw!  Do we really want multi-key
> > > combinations in Squeak's text editor?!)
> > 
> > Sure. Why not.
> 
> Ack!!  Well, they take a long time to learn, and they're almost always
> slower than menus.  They are a logical choice for emacs, but they seem
> quite silly for a thoroughly graphical system like Squeak.
> 
> 
> > > Let's be light on the hooks, *especially* in matters that pertain to the
> > > user interface.  Generalization comes with a penalty.
> > 
> > You've been pretty light on what the penalties could be, and pretty strong
> > on the idea that the only way to avoid them is to avoid improving things
> > on the programmatic side of things. I find this uncompelling.
> > 
> 
> Let me tie it together better.  Notice the following:
> 
> 	1. It's extremely easy to add registries when a need comes up.  Thus
> there is no hurry to do it.
> 
> 	2. Registries remove the chance for a human touch, and leave things to
> be organized by an algorithm.
> 
> 	3. Registries add inertia and make a lot of simple hacks more
> complicated.  Any code touching the registryized part of the system,
> must now work under more general assumptions.
> 
> Thus, registries add a moderate amount of definite badness, and putting
> them off costs nothing.
> 
> 
> I guess in general you could sum up my stance as anti-flexible Squeak. 
> :)  Don't get me wrong -- I'm glad that the sticky parts *are* getting
> greased, in particular the open menu and some of the flaps.  But I want
> the main Squeak release to only have generalizations that will actually
> be useful.  Besides, it is good to put our feet down about a decision
> every once in a while.  If we aren't going to make any decisions about
> what goes into Squeak, then why don't we just give up and release an
> empty file to the world?  Everyone can fill in the file with whatever
> they want.
> 
> 	http://c2.com/cgi/wiki?PrematureGeneralization
> 
> 
> Lex