Category:Smalltalk: Difference between revisions

 
(5 intermediate revisions by the same user not shown)
Line 480:
(knowing that the "ifXX"-methods send <tt>"value"</tt> to the corresponding arg and return that)
 
In this style, all of Smalltalk's control structures, loops, enumeration, stream readers and event- theor exception handling constructs are built. And since every class is open for extension, you can easily add additional convenient control functions (which is one place, where dialects differ, so very often, one has to transport some of those when porting apps from one dialect to another).
 
The following is only a tiny subset - there are virtually hundreds or thousands of uses of blocks for control structures in the system.
Line 492:
[ loop code . condition expression ] whileTrue.
[ loop code ] doWhile:[ condition ].
[ loop code ] doUntil:[ condition ].
 
n timesRepeat:[ block to be looped over ] "n being an integer"
Line 507 ⟶ 508:
 
=== Return from a Block ===
it should be noted that a " ˆ " (return) inside a block will return from the enclosing method, NOT only from the block. And that this is an essential semantic property of the return (technically, it may be a long return from a deeply nested call hierarchy, possibly involving unwind actions).
 
This makes it possible to pass a block to eg. collections to enumerate elements up-to and until some condition is met. For example, if we need a helper method, which searches the first element in a dataset to some condition and evaluate an action on it, we can write:
Line 541 ⟶ 542:
 
<lang smalltalk>[ try block to be evaluated ] on:exception do:[:ex | handler code ]</lang>
where '<I>exception</I>' is an Exception class or Signal instance and the '<I>ex</I>' argument provides detail information (where and why) to the hander and also allows control of how to continue afterwards (proceed, return, restart, reject).
<br>The handler basically has the following options:
* ex return - return out of the try block
Line 581 ⟶ 582:
Some implementations support source-to-source compilation to C, JavaScript or Java. These may or may not show some limitations in the support for dynamic changes at execution time. Typically, the full dynamic bytecode is used for development, followed by a compilation phase for deployment/packaging.
 
All Smalltalks use and depend on garbage collection for automatic reclamation of unused objects, and most implementations use modern algorithms such as generation scavenging, incremental background mark&sweepcollectors, weak references and finalization support. Imprecise conservative collectors are typically not used. Reference counting was abandoned in the 70s.
 
As message send performance is critical in Smalltalk, highly tuned cache mechanisms have been invented and are used: inline caches, polymorph inline caches, dynamic recompilation based on receiver and/or argument types etc.
Line 638 ⟶ 639:
ifTrue:[1]
ifFalse:[ self * (self-1) factorial ]</lang>
(here '<I>self</I>' is the Integer receiver object, and " ˆ " returns a value from the message send).
 
To get the factorial value, we'd evaluate in a workspace:<lang>10 factorial</lang>
Line 649 ⟶ 650:
 
a) is somewhat inconvenient if the code example consists of multiple methods, possibly in multiple classes.
<br>b) comes with the additional trouble that fileIn formats are different (chunk file, vs. XML file, vs. Monticello, vs. GNU-ST etc.).
 
For example, for export/import, GNU-ST uses a ''private format'', (which has the advantage of not needing the chunk format's bangs and especially the ugly bang doubling inside code and the empty chunk at the end):
<lang smalltalk>Number extend [
my_factorial [
Anonymous user