Hi Andreas,

Thank you for responding. I realize you are focused on the immediate deadline. I did not expect you to make an exception for this new selector. 

Beyond that deadline, I need to find out if my thinking is solid and can raise a consensus for including String>>sound as a method, technique and pattern for using squeak. I believe I have thought this through and come to a valid conclusion. My problem is that laza thinks otherwise and has asked me to get more support. That is what I am trying to do.

Squeak should be fun to use. The language IMO should make natural sense when you say-it/use-it.

I am focused on the future and patient in my hopes and expectations. So I am looking for those who would support the #sound selector as an extention of String. I am not trying to trip up your focus or timeline. I am just not willing to sit by silently as something I think wonderful is killed by lack of entusiasm or defending.

Yours in curiosity and service, --Jerome Peace

Hi Jerome -

I know this will be disappointing but it's too late to consider this 
change for the 4.1 release. At this point, the only changes worth 
considering are critically broken behavior and a new API like you're 
introducing is simply beyond the scope of changes that should be done at 
this point of the release.

The issues that I'm aware of that qualify for a last-minute change 
before 4.1 goes final are:

* A Unix VM update since there is reason to believe that Ian's latest 
update fixes both the sound issues as well as the UUID crashes.

* A fix for issue with SMDependencyTest if there's a quick fix; but if 
not we'll ship anyway and just document the behavior and the workaround.

Cheers,
   - Andreas

<rant snipped see original post 
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148688.html>