On 8/9/07, <b class="gmail_sendername">Keith Hodges</b> <<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>If someone wants to do this then let em, its an open source project, if<br>it works then great, if not then good luck to them. Its not our job to<br>be the censors as to what someone may or may not do with squeak in the
<br>future.</blockquote><div><br><br>No one is stopping them. From doing it to their own image or fork. But to the base image?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes it takes more thought to refactor and tidy up that it did to put it<br>in in the first place, there are often more factors to be considered.<br>Having a bigger armory of techniques is not a bad thing.</blockquote><div>
<br><br>To a point. But not all techniques fit. I think you would agree that e.g. pointers are a technique we don't need.<br><br>I mean by this that simply saying "this is another technique" isn't a get in free card. It still has be accepted by the right people, and if it isn't that isn't necessarily a failing of the community.
<br></div><br>I still don't understand the problem with having this a package and let people use it that want it? Ok, so they can't use it on the Kernel, but most Squeak work done is in external projects, not the Kernel.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The use of innovations in that sentence is not referring to anything<br>specific, its a general point, so I am not pronouncing anything.
</blockquote><div><br>Then what innovations did you have in mind that were rejected?<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is pitting abstract versus concrete thinking. Adding a language<br>feature is an abstract concept, and provides benefits in terms of the<br>abstractions available for thinking about the problem etc. Concrete<br>thinking is demanding stats before the fact.
</blockquote><div><br>No, I'm talking about what works. Put the thing in your own personal image and use abstract thinking to make the image better and then you have something concrete to show people to get adoption.
<br><br>But is it possible that you are still seeing things through the lens of your previous language experience? Is it possible that the Null pattern is normally done some other way in Smalltalk and therefor isn't the hammer it was in Objective-C?
<br><br>I see a lot of places I feel that I could make more concise/clear code if we had Haskell/Erlang style pattern matching for functions, but that's not how Smalltalk works. Smalltalk has a Smalltalk way to solve that (
e.g. double dispatch). I would search out the Smalltalk way before trying to force pattern matching into the language.<br></div></div>