Today's Smalltalk 4 You goesback to Polymorphism in Smalltalk for some more discussion. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
We've gone over a basic polymorphism example, but one point needs to be made: when you decide to add polymorphic behavior to your own objects, the API you need to cover is typically small. What if you need to cover a system class - like, say, Collection?
In the simple example we covered here, there was one method to create in each object: #currentValue. If you intend to cover something larger, you'll have more work to do.
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
Today's Smalltalk 4 You looks at one of the changes - keyboard shortcuts - you'll run into when upgrading from an older rev of VisualWorks to the latest. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
Today's Smalltalk 4 You looks at the standard development process using VA Smalltalk and ENVY. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
We've gone over a sketch of a Case Statement object in Smalltalk, but most of the time, polymorphism is the better answer. Today we'll give a simple example. Consider three classes that hold financial data:
Each object calculates their value differently, but the idea is, we can send #currentValue to each, without needing to know the way they function internally (for an example in the base libraries, consider all of the objects that respond to #next). Here's the three implementations of #currentValue:
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
Today's Smalltalk 4 You goes back to the CaseStatement sketch we did recently, and goes over when such a construct might be useful in Smalltalk. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
Having looked at a Case Statement sketch and at polymorphism, we'll turn back to the Case Statement idea - when might such a thing be useful in Smalltalk? There are times when you end up with a long section of #ifTrue:ifFalse: blocks - when dealing with keyboard shortcuts, or possibly return values from an external application. Consider this simple example:
"imagine that val is the return value from some external application"
| val cases |
val := ((EsRandom new next) * 10) rounded.
cases := CaseStatement case: 1 do: [Transcript show: '1'; cr].
cases
case: 2 do: [Transcript show: '2'; cr];
case: 3 do: [Transcript show: '3'; cr];
case: 4 do: [Transcript show: '4'; cr];
case: 5 do: [Transcript show: '5'; cr];
case: 6 do: [Transcript show: '6'; cr];
case: 7 do: [Transcript show: '7'; cr];
case: 8 do: [Transcript show: '8'; cr];
case: 9 do: [Transcript show: '9'; cr].
cases switch: val default: [Transcript show: 'Not Found: ', val printString; cr].
Instead of a random number generator, imagine that the code coming back is from an external system call, and we need to do different things based on what came back. We could set up a polymorphic caller, using a dictionary matching numbers to symbols, and then performing the symbols - but that might actually be less clear than the code above. It's not often that you'll need a case statement in Smalltalk, but it does come up from time to time.
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
Today's Smalltalk 4 You looks at a small change in the way VW works against Oracle (as of VW 7.9). If you're upgrading from an older rev of the product, you might run into this. There's a code example in this post, and you should probably be aware that Cincom has classified this as a bug, for which they'll be issuing a resolution. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
Today's Smalltalk 4 You sketches out a case statement object in Smalltalk. Not because this is a great idea; generally, you want to use Polymorphism. However, having been asked about such a thing, we have a sketch of how to do it. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
Recently, I was asked about Case Statements and Smalltalk - Smalltalk does not have one (nor does it need one, for the most part) - but it makes for a small, interesting example. I had created one of these in VisualWorks years ago, but it ported pretty cleanly into VA Smalltalk (the only real difference being that #new in VA does not send #initialize to the newly created instance). I have verification that the code works as-is in GNU Smalltalk as well - not a surprise, as it's pretty basic stuff. Here's the class definition:
There's a convenience method to create the first case, and the collection of cases is a collection of associations (where the key is the case, the value is the execution block for that case):
case: aCondition do: aBlock
"answer a new instance with initial condition"
^self new case: aCondition do: aBlock
There are a few instance methods to hook up the machinery:
switch: aCondition
"execute block previously stored"
self switch: aCondition default: [self error: 'No Default Found']
switch: aCondition default: aBlock
"execute block previously stored"
| association |
association := self findOnKey: aCondition.
association notNil
ifTrue: [(self findValue: association) value]
ifFalse: [aBlock value]
findOnKey: aCondition
"answer association or nil"
^cases detect: [:each | each key = aCondition] ifNone: [nil]
findValue: anAssociation
"answer the value"
^anAssociation value
Try that out and see what happens. You can find the code in VRGoodies (Contributed) in VisualWorks, and that code will port cleanly to at least VA and GNU (and I expect Pharo or Squeak as well).
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
Today's Smalltalk 4 You looks at a small behavior difference in the way things work in VA Smalltalk, Pharo, and VisualWorks, involving strings and IdentityDictionary. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
Today we'll look at IdentityDictionary to point out a small difference in how things work in VA, Pharo, and VisualWorks. Consider the following code:
In Pharo and VA, you get back 1 - the literals are apparently reused, making them safe as keys in an IdentityDictionary. In VisualWorks, on the other hand, you get a KeyNotFound exception. In VisualWorks, the literals are not reused (and, since the introduction of immutability a few releases ago, that behavior is guaranteed).
If you are working on a project that is maintaining code across multiple Smalltalk implementations, this is a useful thing to know.
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
Today's Smalltalk 4 You looks at the system reporter in Pharo. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
Today's Smalltalk 4 You looks at using Streams to write collections (not Strings). If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
Today we'll have a look at writing arbitrary collections via streams. In Smalltalk, streams can be used to write collections of objects (not just strings). For example: here we set up a ByteArray, and then write to it:
Inspecting the results will give you the collection #('one' (1/3)) - the last object, if you look in the inspector, is a fraction.
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
Today's Smalltalk 4 You looks at readng objects from collections in Smalltalk - streams are hardly limited to strings. If you have trouble viewing it here in the browser, you can also navigate directly to YouTube. To watch now, click on the image below:
If you have trouble viewing that directly, you can click here to download the video directly. If you need the video in a Windows Media format, then download that here.
You can also watch it on YouTube:
Today we'll have a look at reading arbitrary collections via streams. In Smalltalk, streams can be used to read any collection (not just strings). For example: here we set up a ByteArray, and then read from it:
Inspecting the results will give you the collection #('one' 16.2). Next time, we'll look at writing collections using streams.
Need more help? There's a screencast for other topics like this which you may want to watch. Questions? Try the "Chat with James" Google gadget over in the sidebar.
.
.
.
.
.
.
