Squeaking up for "'click' sound play"
Locked
Squeaking up for "'click' sound play"
 
|
Hi laza, hi all,
I was hoping to get this adopted quietly. The gatekeepers are asking me to show support for this feature. If you are in favor of this let it be heard. In: 7497: [FIX][Enh] Sound that name. http://bugs.squeak.org/view.php?id=7497 laza has written: Also I guess you will need to mobilize more supporters for your idea on squeak-dev to make this happen. Just to say, that I wouldn't like the String class to be "polluted" with such "convenience" methods. There would be no end ... String image String morph String fileContent ... To which I have replied: My take is that in squeak everything is an object. This means that basic classes such as number and string serve as objects. It leads to the following problem: The number or name of something acts as a modifier, yet if you use the number or name first in squeak it is a receiver. To have a worthwhile language which resembles my speaking language I choose to allow my modifiers to be receivers. It is stupid IMO to invent classes inorder to use modifiers as argument parameters. In squeak modifiers sometimes belong in the position of receivers. In this case the problem is the invented and arbitrary class that takes the sound name as an argument was deprecated and nuked. Leaving broken code behind it. The easy and English sounding way to avoid this is to give the modifier it's rightful place as the receiver of the message. 'click' sound play. Is IMHO the right way to say lets play a click like sound. It sounds right when you speak it. I feel very strongly about this. Any other solution I could propose would involve arbitrary invention and would not be as general. Who wants to remember what class is responsible for playing a click sound when programming an application? This solution is elegant. Remember the old class used was Object. So you could say: self beep: 'click' and aviod looking up the sound making class or creating a new object just to play your sound. Conversion methods are used all the time. While I have seen some warning against using them too readily I have not seen any more elegant solutions. So I am stating that all strings should be able to make a sound if they so wish. The #sound method is in charge of knowing what that sound should be. Playing a library sound if one exists or a default sound if one does not. It doesn't belong to the String package it belongs to the Sound package along with the class that keeps the Sound Library. It extends the String classes. The programmer should be having fun using squeak not a frustrating time trying to find the missing word. Sorry for the rant. I feel quite strongly about this and dislike the additional hurdles being put in the way of an elegant solution. Rantingly, --Jerome Peace |
Re: Squeaking up for "'click' sound play"
|
|
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 On 4/13/2010 6:25 PM, Jerome Peace wrote: > Hi laza, hi all, > > > I was hoping to get this adopted quietly. The gatekeepers are asking me to show support for this feature. If you are in favor of this let it be heard. > > In: > 7497: [FIX][Enh] Sound that name. > http://bugs.squeak.org/view.php?id=7497 > > laza has written: > > Also I guess you will need to mobilize more supporters for your idea on squeak-dev to make this happen. > > Just to say, that I wouldn't like the String class to be "polluted" with such "convenience" methods. There would be no end ... > > String image > String morph > String fileContent > ... > > To which I have replied: > > > My take is that in squeak everything is an object. This means that basic classes such as number and string serve as objects. It leads to the following problem: > > The number or name of something acts as a modifier, yet if you use the number or name first in squeak it is a receiver. To have a worthwhile language which resembles my speaking language I choose to allow my modifiers to be receivers. > > It is stupid IMO to invent classes inorder to use modifiers as argument parameters. In squeak modifiers sometimes belong in the position of receivers. > > In this case the problem is the invented and arbitrary class that takes the sound name as an argument was deprecated and nuked. Leaving broken code behind it. > > The easy and English sounding way to avoid this is to give the modifier it's rightful place as the receiver of the message. > > 'click' sound play. > > Is IMHO the right way to say lets play a click like sound. It sounds right when you speak it. > > I feel very strongly about this. > > Any other solution I could propose would involve arbitrary invention and would not be as general. > > Who wants to remember what class is responsible for playing a click sound when programming an application? This solution is elegant. > > Remember the old class used was Object. > > So you could say: > > self beep: 'click' > and aviod looking up the sound making class or creating a new object just to play your sound. > > Conversion methods are used all the time. While I have seen some warning against using them too readily I have not seen any more elegant solutions. > > So I am stating that all strings should be able to make a sound if they so wish. > > The #sound method is in charge of knowing what that sound should be. Playing a library sound if one exists or a default sound if one does not. It doesn't belong to the String package it belongs to the Sound package along with the class that keeps the Sound Library. It extends the String classes. > > The programmer should be having fun using squeak not a frustrating time trying to find the missing word. > > Sorry for the rant. I feel quite strongly about this and dislike the additional hurdles being put in the way of an elegant solution. > > Rantingly, --Jerome Peace > > > > > > > |
Re: Squeaking up for "'click' sound play"
|
|
In reply to this post by Jerome Peace
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> |
|
In reply to this post by Jerome Peace
Hi Jerome!
2010/4/14 Jerome Peace <[hidden email]>: > I was hoping to get this adopted quietly. The gatekeepers are asking me to show support for this feature. If you are in favor of this let it be heard. In general I think it is not the best way to promote something new for the core by creating an issue on mantis and waiting for "people" to pick it up. Marking it major or block with a high priority also will do little to this. It's more likely that the issue will rot on mantis forever. So I felt that I was actually helping you along with your idea by suggesting a better way to promote it and I had not the impression of putting up additional hurdles. So committing code to the Inbox, announcing it on squeak-dev, which at best sparks off some discussion where people express there take on it, sounds like a better way to me. And regardless what I think, if there is support for it, a core developer might adopt it and it will get into the core. Alex |
Re: Squeaking up for "'click' sound play"
|
|
In reply to this post by Jerome Peace
On 14.04.2010, at 03:25, Jerome Peace wrote:
> > Hi laza, hi all, > > > I was hoping to get this adopted quietly. The gatekeepers are asking me to show support for this feature. If you are in favor of this let it be heard. > > In: > 7497: [FIX][Enh] Sound that name. > http://bugs.squeak.org/view.php?id=7497 > > laza has written: >> >> Also I guess you will need to mobilize more supporters for your idea on squeak-dev to make this happen. >> >> Just to say, that I wouldn't like the String class to be "polluted" with such "convenience" methods. There would be no end ... >> >> String image >> String morph >> String fileContent >> ... >> > To which I have replied: > > > My take is that in squeak everything is an object. This means that basic classes such as number and string serve as objects. It leads to the following problem: > > The number or name of something acts as a modifier, yet if you use the number or name first in squeak it is a receiver. To have a worthwhile language which resembles my speaking language I choose to allow my modifiers to be receivers. > > It is stupid IMO to invent classes inorder to use modifiers as argument parameters. In squeak modifiers sometimes belong in the position of receivers. > > In this case the problem is the invented and arbitrary class that takes the sound name as an argument was deprecated and nuked. Leaving broken code behind it. > > The easy and English sounding way to avoid this is to give the modifier it's rightful place as the receiver of the message. > > 'click' sound play. > > Is IMHO the right way to say lets play a click like sound. It sounds right when you speak it. > > I feel very strongly about this. > > Any other solution I could propose would involve arbitrary invention and would not be as general. > > Who wants to remember what class is responsible for playing a click sound when programming an application? This solution is elegant. > > Remember the old class used was Object. > > So you could say: > > self beep: 'click' > and aviod looking up the sound making class or creating a new object just to play your sound. > > Conversion methods are used all the time. While I have seen some warning against using them too readily I have not seen any more elegant solutions. > > So I am stating that all strings should be able to make a sound if they so wish. > > The #sound method is in charge of knowing what that sound should be. Playing a library sound if one exists or a default sound if one does not. It doesn't belong to the String package it belongs to the Sound package along with the class that keeps the Sound Library. It extends the String classes. > > The programmer should be having fun using squeak not a frustrating time trying to find the missing word. > > Sorry for the rant. I feel quite strongly about this and dislike the additional hurdles being put in the way of an elegant solution. > > Rantingly, --Jerome Peace I follow your reasoning. However, conversion methods usually follow the asXYZ pattern. With #asSound I would have less problems. #asSampledSound would be even more correct, since I guess you would map it to "^SampledSound soundNamed: self", right? #sound to me is not intention-revealing enough for inclusion in the base system. - Bert - |
Re: Squeaking up for "'click' sound play"
|
|
> I follow your reasoning. However, conversion methods usually follow the
> asXYZ pattern. > > With #asSound I would have less problems. #asSampledSound would be even more > correct, since I guess you would map it to "^SampledSound soundNamed: self", > right? +1 I am used to this coding pattern as well. > #sound to me is not intention-revealing enough for inclusion in the base > system. The same thing for me. > - Bert - > > Hannes |
Re: Squeaking up for "'click' sound play"
|
|
In reply to this post by Jerome Peace
On Wednesday 14 April 2010 06:55:04 am Jerome Peace wrote:
> The number or name of something acts as a modifier, yet if you use the > number or name first in squeak it is a receiver. To have a worthwhile > language which resembles my speaking language I choose to allow my > modifiers to be receivers. > > It is stupid IMO to invent classes inorder to use modifiers as argument > parameters. In squeak modifiers sometimes belong in the position of > receivers. Please consider all implications of your proposal. Tokens like 'click', #click or 23 are not modifiers. They are just abstract indices. They don't mean anything by themselves. A context is needed to impart meaning to them. You are suggesting that we embed this context into the String class. But the same logic may lead others to patching Symbol and Number classes too. The scheme will blow up in multilingual situations. How do you handle language variants - 'hello', 'allo', 'hola' and so on. Take another example, say 'bark'. I may want to generate a 'bow wow' sound in a particular context and 'woof woof' in another context. I would rather have this logic put into Sound class rather spread it amongst basic classes. Would you extend the same reasoning to 1005 asPlatformName ^Smalltalk current getSystemAttribute: self. Subbu |
Re: Squeaking up for "'click' sound play"
|
|
In reply to this post by Bert Freudenberg
On 4/14/2010 7:24 AM, Bert Freudenberg wrote:
> I follow your reasoning. However, conversion methods usually follow the asXYZ pattern. > > With #asSound I would have less problems. #asSampledSound would be even more correct, since I guess you would map it to "^SampledSound soundNamed: self", right? > > #sound to me is not intention-revealing enough for inclusion in the base system. Moreover, as a verb "to sound" implies that the sound is being played already. In other words I'd kinda expect that "'boink' sound" does the same as "'boink' asSound play". Cheers, - Andreas |
|
|
In reply to this post by K. K. Subramaniam
2010/4/14 K. K. Subramaniam <[hidden email]>:
> Please consider all implications of your proposal. +1 |
Re: Squeaking up for "'click' sound play"
|
|
In reply to this post by Jerome Peace
--- On Wed, 4/14/10, K. K. Subramaniam <[hidden email]> wrote:
> From: K. K. Subramaniam <[hidden email]> > Subject: Re: [squeak-dev] Squeaking up for "'click' sound play" > To: [hidden email] > Cc: "Jerome Peace" <[hidden email]> > Date: Wednesday, April 14, 2010, 11:00 AM > On Wednesday 14 April 2010 06:55:04 > am Jerome Peace wrote: > > The number or name of something acts as a modifier, > yet if you use the > > number or name first in squeak it is a receiver. To > have a worthwhile > > language which resembles my speaking language I choose > to allow my > > modifiers to be receivers. > > > > It is stupid IMO to invent classes inorder to use > modifiers as argument > > parameters. In squeak modifiers sometimes belong in > the position of > > receivers. > Please consider all implications of your proposal. > > Tokens like 'click', #click or 23 are not modifiers. They > are just abstract > indices. They don't mean anything by themselves. A context > is needed to impart > meaning to them. > > You are suggesting that we embed this context into the > String class. But the > same logic may lead others to patching Symbol and Number > classes too. > > The scheme will blow up in multilingual situations. How do > you handle language > variants - 'hello', 'allo', 'hola' and so on. How would you? I would add the words to the sound library. Either connected to their particular sounds or redefining the sound I want them to refer to. Even if I did nothing "'allo' sound play." would make the default sound. > > Take another example, say 'bark'. I may want to generate a > 'bow wow' sound in > a particular context and 'woof woof' in another context. Suppose you did. How would you want to do it? bark := 'bow wow' . bark sound play. bark := 'woof woof' bark sound play. or bark := 'bow wow' sound . bark := 'woof woof' sound . bark play . Though in the latter case I might use barkSound instead of bark as the variable. > I > would rather have > this logic put into Sound class rather spread it amongst > basic classes. > Hmmm. In packaging the selector has been put in an extention so that it is packaged with Sound Library. In protocol it belongs as an instance method for String class and subclasses. > Would you extend the same reasoning to > 1005 asPlatformName > ^Smalltalk current getSystemAttribute: self. You mean instead of "SmalltalkImage current platformName" ? No, because 1005 asPlatformName has no meaning for me. It certainly would make code reading more mysterious. When I went to read it again I would not remember why 1005 was to be associated with anything let alone PlatformName. It also seems a very straw man like example. In that case its not the programmer who should be remembering the specific index. The principles involved here is to form the language to 1) Write intention revealing code. 2) Create as little dissonance with the language the programmer already has in his head.* Smalltalk gives you the chance to have programming language that sounds like natural talk. That's important to use. Yours in curiosity and service, --Jerome Peace *Currently this is biased towards English/American. > > Subbu > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |