An 3.9 image for developers

> You won't like it globally. Just do, when you need it,
>
>  aCollection removeAll: aCollection copy
>
> and let #removeAll as is.
>
> /Klaus

Why won't I like it globally?  Seems just a synonym for a common usage.
   #removeAll: aCollection is in Collection, so putting #removeAll there
seems natural as well.  Secondly, I didn't write the refractoring
browser, which is what calls #removeAll, I added the extension to make
it work, rather than changing the browser.

Hi Ramon,

on Sat, 16 Sep 2006 18:07:06 +0200, you wrote:
> Klaus wrote:
>> You won't like it globally. Just do, when you need it,
>>   aCollection removeAll: aCollection copy
>>  and let #removeAll as is.
>>  /Klaus
>
> Why won't I like it globally?  Seems just a synonym for a common usage.

Yes, but only on first sight.

>    #removeAll: aCollection is in Collection, so putting #removeAll there  
> seems natural as well.

Every Collection subclass has its own efficient algorithm for "remove'em  
all" (whether implemented or not).

OrderedCollection for example, has indices for first and last element, so  
why copy an OrderedCollection in #removeAll and waste memory and time?

And, have you tested (#(1) removeAll) or (#(1) removeAll: #(1)), they are  
Collections. How are these potential bugs avoided.

> Secondly, I didn't write the refractoring browser, which is what calls  
> #removeAll, I added the extension to make it work, rather than changing  
> the browser.

Sure, I understand your position. So the quesion is, which of the two  
possible solutions must yield.

/Klaus

> Every Collection subclass has its own efficient algorithm for
> "remove'em  all" (whether implemented or not).

I hadn't considered subclass implementations, very good point, however,
if they had an existing #removeAll, putting one in Collection wouldn't
affect them.  A quick check of my image shows only SkipList overriding
my default #removeAll.

> OrderedCollection for example, has indices for first and last element,
> so  why copy an OrderedCollection in #removeAll and waste memory and time?

OrderedCollection has no #removeAll, if a more efficient one can be
implemented in it via it's indices, it could simply override the default
implementation.  This doesn't seem a reason for a superclass not to
provide a default implementation, if it can.

> And, have you tested (#(1) removeAll) or (#(1) removeAll: #(1)), they
> are  Collections. How are these potential bugs avoided.

This is a very good point, I had considered this, but consider...

#(1) add: 3

Since collection has #add: and #remove:, and Array overrides them as
inappropriate messages, this seems more a problem of Array having the
wrong superclass, or more specifically, a problem of single inheritance
being used to share the implementation.  Array is breaking the Liskov
Substitution Principle.  Seems traits would be the fix here.  If a
#removeAll method is ever appropriate, should it not be in the same
class as #add:, #remove:, and #removeAll:, efficiency aside?  Not to
mention that #removeAll: already exists on Collection, so these bugs
already exist, adding a #removeAll doesn't create them.

> Sure, I understand your position. So the quesion is, which of the two  
> possible solutions must yield.
>
> /Klaus

It's definitely something to think about, for now, I'll leave it, it's
been in my image quite a while, and only SkipList overrides it with a
more specific implementation.  I'm still using 3.8, it'll be interesting
to see how 3.9 and it's traits refactorings on the collections affect this.

Hi Ramon,

on Sat, 16 Sep 2006 21:26:07 +0200, you wrote:
> Klaus wrote:
>> OrderedCollection for example, has indices for first and last element,  
>> so  why copy an OrderedCollection in #removeAll and waste memory and  
>> time?
>
> OrderedCollection has no #removeAll, if a more efficient one can be  
> implemented in it via it's indices, it could simply override the default  
> implementation.  This doesn't seem a reason for a superclass not to  
> provide a default implementation, if it can.

Right you are, always do it the object oriented way. Thank you for the  
reminder :)

/Klaus

Ramon Leon a écrit :
> It's definitely something to think about, for now, I'll leave it, it's
> been in my image quite a while, and only SkipList overrides it with a
> more specific implementation.  I'm still using 3.8, it'll be interesting
> to see how 3.9 and it's traits refactorings on the collections affect this.

I don't think 3.9 contains collection refactoring. Maybe for 3.10 ?


--
Damien Cassou

>
> It's definitely something to think about, for now, I'll leave it,  
> it's been in my image quite a while, and only SkipList overrides it  
> with a more specific implementation.  I'm still using 3.8, it'll be  
> interesting to see how 3.9 and it's traits refactorings on the  
> collections affect this.

there is no refactoring of collection in 3.9.
I think that what would be nice is to regularly add some tests to the  
collections to that at the end we get a really good coverage.
This could be a success factor if one day someone wants to refactor  
them.

stef

> there is no refactoring of collection in 3.9.
> I think that what would be nice is to regularly add some tests to the  
> collections to that at the end we get a really good coverage.
> This could be a success factor if one day someone wants to refactor  them.
>
> stef

My bad, I thought the refactorings from the traits paper, were included
in the first release with traits.  Though, that'd be mighty risky, not
sure why I thought it was the case.

Lukas Renggli a écrit :
Can someone explain me how to do that please ?

--
Damien Cassou

Damien Cassou a écrit :
Solved :-)

--
Damien Cassou

Sorry for the late entry...I can't keep up with squeak-dev these days.
Keymapping and KeyBinder try to achieve similar goals but Keymapping
has some features which I believe are absent from KeyBinder:

- shortcuts can be assigned to any morph instance or class
- shortcuts can be assigned to categories and shared across multiple
morphs or morph classes
- shortcuts can be blocks, class methods sends or paragraph editor
shortcuts (you can use Keymapping to redefine the "text" keyboard
shortcuts).
- shortcuts can be triggered by arbitrary sequences of keystrokes (they
don't have to be simple alt-Key or control-Key combinations)
- shortcuts can be exported and imported into another image (w/
limitations on shortcuts which execute blocks).

My goal with Keymapping was to make it possible for developers to
specify default keyboard shortcuts for their menu operations and global
services and for users to be able to re-assign them.  I took this "all
the way" in Squeak 3.7 and migrated all of the built-in tools to have
re-assignable keyboard shortcuts.  I haven't done this for 3.8 or 3.9.
I can't maintain that effort...although I could do it one or two more
times to a limited set of "base" tools.  If you load Keymapping into a
3.8 or 3.9 image you will likely be frustrated that pressing alt-B is
caught by the world "browse it" shortcut since the browsers haven't been
hacked to specify their shortcuts to Keymapping.  The net effect is
pressing alt-B in a browser window may raise a browser but with no class
selected (rather than the browser's behavior or raising a browser with
the current class selected).  The actual effect depends on your focus
settings and probably interactions with Romain's Services
framework...not sure about that one.


This is a bit off-topic but ultimately we need

1) a hook for key events that lets us do this without hacks...this has
already been mentioned in this thread
2) an abstract way for tools to specify possibly context-sensitive
keyboard actions as part of their description of context menus
3) an abstract way to specify application services and their
shortcuts...I believe that Romain has already solved this problem

I haven't looked at Services in a while but I don't think #2 has been
handled yet.  Suppose I wanted to have a "delete item" shortcut in a
list pane.  I don't want to provide that as a global service to other
applications.  Just a keyboard shortcut to trigger an action in the
current application when the cursor is over that pane.  Many
applications in Squeak do this and I don't think it always fits into the
"services" metaphor.

I'll bring this up in another thread...

David

Hi David,

please tell us when you have something ready to be included in 3.9. I
think Squeak really needs a better way to handle keyboard and keyboard
configuration.

Bye

--
Damien Cassou