Traits: Experience with a Language Feature

Total Page:16

File Type:pdf, Size:1020Kb

Traits: Experience with a Language Feature 7UDLWV([SHULHQFHZLWKD/DQJXDJH)HDWXUH (PHUVRQ50XUSK\+LOO $QGUHZ3%ODFN 7KH(YHUJUHHQ6WDWH&ROOHJH 2*,6FKRRORI6FLHQFH1(QJLQHHULQJ$ (YHUJUHHQ3DUNZD\1: 2UHJRQ+HDOWKDQG6FLHQFH8QLYHUVLW\ 2O\PSLD$:$ 1::DONHU5G PXUHPH#HYHUJUHHQHGX %HDYHUWRQ$25 EODFN#FVHRJLHGX ABSTRACT the desired semantics of that method changes, or if a bug is This paper reports our experiences using traits, collections of found, the programmer must track down and fix every copy. By pure methods designed to promote reuse and understandability reusing a method, behavior can be defined and maintained in in object-oriented programs. Traits had previously been used to one place. refactor the Smalltalk collection hierarchy, but only by the crea- tors of traits themselves. This experience report represents the In object-oriented programming, inheritance is the normal way first independent test of these language features. Murphy-Hill of reusing methods—classes inherit methods from other classes. implemented a substantial multi-class data structure called ropes Single inheritance is the most basic and most widespread type of that makes significant use of traits. We found that traits im- inheritance. It allows methods to be shared among classes in an proved understandability and reduced the number of methods elegant and efficient way, but does not always allow for maxi- that needed to be written by 46%. mum reuse. Consider a small example. In Squeak [7], a dialect of Smalltalk, Categories and Subject Descriptors the class &ROOHFWLRQ is the superclass of all the classes that $UUD\ +HDS D.2.3 [Programming Languages]: Coding Tools and Tech- implement collection data structures, including , , 6HW niques - object-oriented programming and . The property of being empty is common to many ob- jects—it simply requires that the object have a size method, and D.3.3 [Programming Languages]: Language Constructs and that the method returns zero. Since all collections have a size, it Features – classes and objects, inheritance makes sense that the method isEmpty should be defined for all collection classes. Because Squeak uses single inheritance, by General Terms defining isEmpty in the class &ROOHFWLRQ, all subclasses of &RO OHFWLRQ Design, Languages inherit the isEmpty method. However, a problem arises with classes outside the collection Keywords hierarchy. Take the class &5'LFWLRQDU\, a part of the “Genie” Traits, Ropes, Reuse, Smalltalk, Inheritance handwriting recognition system in Squeak. This class is not a subclass of &ROOHFWLRQ, but it does have a size and an isEmpty 1. INTRODUCTION method. The method isEmpty was written in exactly the same &ROOHFWLRQ &5'LFWLRQDU\ Reusability is a very important property of object-oriented pro- way twice; once in and once in . grams. With no reuse, all the methods that a class requires would need to be defined in the class itself. When two or more This may seem like a small problem—one repeated method is classes define the same method, code is duplicated. In addition not a lot of repeated code. But this problem is compounded by to being wasteful by taking up memory, duplicated code lowers several factors. First, the method isEmpty occurs in 24 classes, programmer productivity in two ways. Initially, the programmer often defined in a similar manner. Second, a number of similar must take the time to make a copy of a certain method. Later, if methods that rely exclusively on isEmpty are common, includ- ing notEmpty and ifEmpty:. Third, it is quite common to find The research described in this experience paper was conducted at the duplicated methods in unrelated classes in the class hierarchy. OGI School of Science & Engineering at OHSU by an undergraduate For example, the classes 5HFWDQJOH and 5HFWDQJOH0RUSK, student from The Evergreen State College. It was funded by NSF award have much common code that they cannot share because they CCR 0098323. are unrelated: their only common superclass is 2EMHFW [3]. How can we reuse code more effectively? Copyright is held by the author/owner(s). OOPSLA’04, Oct. 24–28, 2004, Vancouver, British Columbia, Canada. ACM 1-58113-833-4/04/0010. One workaround is simply to tolerate the missing methods, rather than dupliciating them. For example, the user of a &5'LFWLRQDU\ could be required to convert it into a 'LFWLRQDU\, 275 &5'LFWLRQDU\ could be required to convert it into a 'LFWLRQDU\, this manner. Using traits, we can define behavior in one place which is a subclass of &ROOHFWLRQ, and then send the isEmpty and have that behavior utilized in multiple places. In addition, message to the 'LFWLRQDU\, but this would be grossly inefficient the protocols of the classes that use traits tend to become more and exceedingly verbose. Another workaround would be to push uniform. For example, while 20 Squeak classes define isEmpty, the method isEmpty up the hierarchy into the 2EMHFW class, but only 2 also define notEmpty. However, if the methods had been isEmpty is inappropriate in subclasses of 2EMHFW that do not reused from the 7(PSW\QHVV trait, both methods would be have a size method. Multiple inheritance is another solution, but defined in all the classes. Readers wishing to learn more about it presents its own set of problems, such as the possibility of traits and the comparison between traits and other language conflicting variable and method names. No alternative to single features are referred to previous publications [3,5]. inheritance has gained widespread acceptance [8]. Small examples are acceptable illustrations of the possibilities 2. TRAITS of traits, but little is known about how useful traits are in a real- istic programming situation. Traits were tested by refactoring Traits are a new solution to the problem of code duplication the entire collections hierarchy [3], but the refactoring was done across unrelated classes [5]. A trait is a reusable building block by two of the creators of traits themselves—Andrew Black and from which programmers construct classes. Traits are collec- Nathanael Schärli. Emerson Murphy-Hill, a programmer famil- tions of pure methods, much like classes, except that they have iar with object-oriented programming but unfamiliar with traits, no superclass and no state. Traits have a set of methods that was assigned to evaluate traits in an independent manner, under define behavior, called the “provides set”, and another set of the gentle direction of Andrew Black. Murphy-Hill spent a methods that have yet to be defined, called the “requires set.” summer at OGI School of Science and Engineering with a Re- search Experience for Undergraduates grant from the National Suppose that we want to create a trait to solve the isEmpty prob- Science Foundation. At the beginning of the project, Murphy- lem. We define the method isEmpty in terms of size, but we Hill was unfamiliar with both Smalltalk and traits. While Black cannot yet define size, because it is often dependent on imple- assisted him in learning Smalltalk, Black did not provide guid- mentation. Furthermore, the methods notEmpty, ifEmpty:, and ance on how to use traits. Murphy-Hill learned about traits from ifNotEmpty: can be defined in terms of isEmpty. So isEmpty, some of the available papers [3,5,6], and utilized this knowledge notEmpty, ifEmpty:, and ifNotEmpty: are in the provides set and to write a significant, multi-class data structure called ropes. size is in the requires set. We now have a reusable building The entire design and implementation process took about one block that we will call 7(PSW\QHVV (see Figure 1). month, but certainly could have progressed faster if the pro- grammer had experience with Smalltalk prior to this experience. 7(PSW\QHVV can be incorporated into the &ROOHFWLRQ class, into the &5'LFWLRQDU\ class, and into any other class that de- fines size. To incorporate a trait into a class, the code in this 3. ROPES class has to be refactored so that old, repeated methods are re- Ropes are an alternative to strings originally developed by moved. Then, a trait should be made which defines these meth- Boehm, Atkinson, and Plass at Xerox PARC [4]. Strings are ods and the trait itself is used in the class. Each class that almost always implemented as fixed length arrays of characters, duplicates behavior defined by the trait should be refactored in which are not ideal for some of the most common string opera- tions. In particular, concatenation and substring selection are 7(PSW\QHVV common operations that strings perform slowly in traditional Provides Requires implementations because they require that large portions of the array be copied. Ropes make both concatenation and substring LV(PSW\ VL]H selection faster by introducing alternative data structures. Al- ↑ self size = 0 VHOIUHTXLUHPHQW though these data structures require ropes to be immutable, immutability can be considered an advantage in that it greatly QRW(PSW\ simplifies sharing of ropes between cooperating processes. ↑ self isEmpty not LI(PSW\D%ORFN 4. THE EXPERIMENT ↑ self isEmpty ifTrue: To see the effect of traits on the development process, we im- >D%ORFNYDOXH@ plemented ropes twice: once with traits, and once without. We based both versions on a Java implementation of ropes by An- LI1RW(PSW\D%ORFN drew Black, which utilized Aspects [2]. Black chose ropes as an ↑ self notEmpty ifTrue: application of traits for Murphy-Hill and let him develop ropes >D%ORFNYDOXH@ as he saw fit. )LJXUH7KHWUDLW7(PSW\QHVVZLWKWKHSURYLGHG PHWKRGVLQWKHOHIWFROXPQDQGWKHUHTXLUHG PHWKRGVLQWKHULJKWFROXPQ 276 Collection SequenceableCollection Rope ArrayedCollection String Concat Empty Flat Substring )LJXUH7KHSDUWLDO&ROOHFWLRQKLHUDUFK\#VKRZLQJWKH6WULQJFODVVDQGWKH5RSHFODVV 4.1. First Implementation: Ropes without Traits The first issue was where to put a Rope class so that it could To implement ropes, Murphy-Hill wrote four subclasses of reuse as much behavior from String as possible. To gain the Rope: Empty, Flat, Substring, and Concat, each with a different greatest amount of reuse, the Rope class should be a subclass of underlying data representation.
Recommended publications
  • The Future: the Story of Squeak, a Practical Smalltalk Written in Itself
    Back to the future: the story of Squeak, a practical Smalltalk written in itself Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [Also published in OOPSLA ’97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming, 1997, pp. 318-326.] VPRI Technical Report TR-1997-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 Back to the Future The Story of Squeak, A Practical Smalltalk Written in Itself by Dan Ingalls Ted Kaehler John Maloney Scott Wallace Alan Kay at Apple Computer while doing this work, now at Walt Disney Imagineering 1401 Flower Street P.O. Box 25020 Glendale, CA 91221 [email protected] Abstract Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks. Other noteworthy aspects of Squeak include: a compact object format that typically requires only a single word of overhead per object; a simple yet efficient incremental garbage collector for 32-bit direct pointers; efficient bulk- mutation of objects; extensions of BitBlt to handle color of any depth and anti-aliased image rotation and scaling; and real-time sound and music synthesis written entirely in Smalltalk. Overview Squeak is a modern implementation of Smalltalk-80 that is available for free via the Internet, at http://www.research.apple.com/research/proj/learning_concepts/squeak/ and other sites. It includes platform-independent support for color, sound, and image processing.
    [Show full text]
  • Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007
    Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007 Michael Haupt1, Robert Hirschfeld1, and Marcus Denker2 1 Software Architecture Group Hasso-Plattner-Institut University of Potsdam, Germany 2 Software Composition Group Institute of Computer Science and Applied Mathematics University of Berne, Switzerland michael.haupt,hirschfeld @hpi.uni-potsdam.de, [email protected] { } Abstract. This position paper proposes the exploitation of type feed- back mechanisms, or more precisely, polymorphic inline caches, for purely interpreting implementations of object-oriented programming languages. Using Squeak’s virtual machine as an example, polymorphic inline caches are discussed as an alternative to global caching. An implementation proposal for polymorphic inline caches in the Squeak virtual machine is presented, and possible future applications for online optimization are outlined. 1 Introduction Bytecode interpreters are small in size and comparatively easy to implement, but generally execute programs much less efficiently than just-in-time (JIT) compilers. Techniques like threaded interpretation [9, 11, 2] focus on speeding up bytecode interpretation itself, and caching [4, 5, 1] improves the performance of message sends—the most common operation in object-oriented software [7]. It is interesting to observe that, while threading mechanisms are used natu- rally to a varying degree in bytecode interpreter implementations, such systems usually employ only global caching to speed up dynamic method dispatch. A global cache is clearly beneficial with respect to overall performance. Still, it does not provide optimal support for polymorphic message send sites, and it does not allow for exploiting type information (we provide details on these issues in the following section). In our opinion, the employment of polymorphic inline caches (PICs) [5] instead can provide means for achieving significant speedups in bytecode interpreters while exhibiting only a moderate increase in memory footprint and implementation complexity.
    [Show full text]
  • Graphical Interface
    Appendix: How to program in Croquet Author: S.M. Wolff Project: Cell-Forum Project Table of Contents Table of Contents .............................................................................................................. 2 Graphical Interface ........................................................................................................... 6 Control structures .............................................................................................................. 9 Testing variables ............................................................................................................... 9 If then else ........................................................................................................................ 10 Switch ............................................................................................................................ 10 While .............................................................................................................................. 10 For .................................................................................................................................. 11 Data structures ............................................................................................................ 12 Ordered Collection ...................................................................................................... 12 Classes, Methods and Shared Variables .................................................................... 13 Packages .....................................................................................................................
    [Show full text]
  • The Cedar Programming Environment: a Midterm Report and Examination
    The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman t CSL-83-11 June 1984 [P83-00012] © Copyright 1984 Xerox Corporation. All rights reserved. CR Categories and Subject Descriptors: D.2_6 [Software Engineering]: Programming environments. Additional Keywords and Phrases: integrated programming environment, experimental programming, display oriented user interface, strongly typed programming language environment, personal computing. t The author's present address is: Sun Microsystems, Inc., 2550 Garcia Avenue, Mountain View, Ca. 94043. The work described here was performed while employed by Xerox Corporation. XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 1 Abstract: This collection of papers comprises a report on Cedar, a state-of-the-art programming system. Cedar combines in a single integrated environment: high-quality graphics, a sophisticated editor and document preparation facility, and a variety of tools for the programmer to use in the construction and debugging of his programs. The Cedar Programming Language is a strongly-typed, compiler-oriented language of the Pascal family. What is especially interesting about the Ce~ar project is that it is one of the few examples where an interactive, experimental programming environment has been built for this kind of language. In the past, such environments have been confined to dynamically typed languages like Lisp and Smalltalk. The first paper, "The Roots of Cedar," describes the conditions in 1978 in the Xerox Palo Alto Research Center's Computer Science Laboratory that led us to embark on the Cedar project and helped to define its objectives and goals.
    [Show full text]
  • 2008 Chevrolet Cobalt Owner Manual M
    2008 Chevrolet Cobalt Owner Manual M Seats and Restraint Systems ........................... 1-1 Driving Your Vehicle ....................................... 4-1 Front Seats ............................................... 1-2 Your Driving, the Road, and Your Vehicle ..... 4-2 Rear Seats ............................................... 1-9 Towing ................................................... 4-32 Safety Belts ............................................. 1-10 Service and Appearance Care .......................... 5-1 Child Restraints ....................................... 1-30 Service ..................................................... 5-3 Airbag System ......................................... 1-53 Fuel ......................................................... 5-5 Restraint System Check ............................ 1-68 Checking Things Under the Hood ............... 5-10 Features and Controls ..................................... 2-1 Headlamp Aiming ..................................... 5-39 Keys ........................................................ 2-3 Bulb Replacement .................................... 5-42 Doors and Locks ...................................... 2-10 Windshield Wiper Blade Replacement ......... 5-48 Windows ................................................. 2-15 Tires ...................................................... 5-49 Theft-Deterrent Systems ............................ 2-18 Appearance Care ..................................... 5-95 Starting and Operating Your Vehicle ........... 2-21 Vehicle Identification
    [Show full text]
  • MVC Revival on the Web
    MVC Revival on the Web Janko Mivšek [email protected] @mivsek @aidaweb ESUG 2013 Motivation 30 years of Smalltalk, 30 years of MVC 34 years exa!tly, sin!e "#$# %ot in JavaScri&t MVC frameworks 'or Sin(le)*age and +ealtime web a&&s ,e Smalltalkers s-ould respe!t and revive our &earls better Contents MVC e &lained %istory /sa(e in !.rrent JavaScri&t frameworks /sa(e in Smalltalk C.rrent and f.t.re MVC in 0ida/Web MVC Explained events Ar!hite!tural desi(n &attern - Model for domain s&e!ifi! data and logi! View updates Controller ) View for &resentation to t-e .ser ) Controller for intera!tions wit- t-e .ser UI and .&datin( domain model Domain changes Main benefit: actions observing ) se&aration of !on!erns Model MVC based on Observer pattern subscribe ) 3bserver looks at observee Observer changed - 3bservee is not aware of t-at s u 4e&enden!y me!-anism2 B t n - 3bserver is de&endent on 3bservee state e observing v - 3bservee m.st re&ort state !-an(es to 3bserver E b - *.b/S.b Event 6.s de!ou&les 3bservee from u S / 3bserver to &reserve its .nawarnes of observation b u changed P Observee Main benefit: (Observable) ) se&aration of !on!erns Multiple observers subscribe - M.lti&le observers of t-e same 3bservee Observer changed - 7n MVC an 3bservee is View and 3bservee is domain Model, t-erefore2 s u B t - many views of t-e same model n e observing v - many a&&s E b - many .sers u S / - mix of all t-ree !ases b u Observee changed P (Observable) Example: Counter demo in Aida/Web M.lti.ser realtime web !ounter exam&le -ttp://demo.aidaweb.si – !li!k Realtime on t-e left – !li!k De!rease or In!rease to c-an(e counter – !ounter is c-an(ed on all ot-er8s browsers History of MVC (1) 7nvented by 9rygve +eenska.g w-en -e worked in "#$:1$# wit- Alan ;ay's group on <ero *arc on Smalltalk and Dynabook – 'inal term Model)View)Controller !oined 10.
    [Show full text]
  • Smalltalk Idioms
    Smalltalk Idioms Farewell and a wood pile Kent Beck IT’S THE OBJECTS, STUPID If we parsed the string “@years”, the resulting picture S me awhile to see the obvious. Some- would look like Figure 6. When the BinaryFunction un- times even longer than that. Three or four times in the wraps its children, the right function will be in place. last month I’ve been confronted by problems I had a As I said, several times in the last month I’ve faced hard time solving. In each case, the answer became clear baffling problems that became easy when I asked myself when I asked myself the simple question, “How can I the question, “How could I make an object to solve this make an object to solve this problem for me?” You think problem for me?” Sometimes it was a method that just I’d have figured it out by now: got a problem? make an didn’t want to be simplified, so I created an object just for object for it. that method. Sometimes it was a question of adding Here’s an example: I had to write an editor for a tree features to an object for a particular purpose without clut- structure. There were several ways of viewing and editing tering the object (as in the editing example). I recommend the tree. On the left was a hierarchical list. On the top right that the next time you run into a problem that just doesn’t was a text editor on the currently selected node of the tree.
    [Show full text]
  • Dynamic Object-Oriented Programming with Smalltalk
    Dynamic Object-Oriented Programming with Smalltalk 1. Introduction Prof. O. Nierstrasz Autumn Semester 2009 LECTURE TITLE What is surprising about Smalltalk > Everything is an object > Everything happens by sending messages > All the source code is there all the time > You can't lose code > You can change everything > You can change things without restarting the system > The Debugger is your Friend © Oscar Nierstrasz 2 ST — Introduction Why Smalltalk? > Pure object-oriented language and environment — “Everything is an object” > Origin of many innovations in OO development — RDD, IDE, MVC, XUnit … > Improves on many of its successors — Fully interactive and dynamic © Oscar Nierstrasz 1.3 ST — Introduction What is Smalltalk? > Pure OO language — Single inheritance — Dynamically typed > Language and environment — Guiding principle: “Everything is an Object” — Class browser, debugger, inspector, … — Mature class library and tools > Virtual machine — Objects exist in a persistent image [+ changes] — Incremental compilation © Oscar Nierstrasz 1.4 ST — Introduction Smalltalk vs. C++ vs. Java Smalltalk C++ Java Object model Pure Hybrid Hybrid Garbage collection Automatic Manual Automatic Inheritance Single Multiple Single Types Dynamic Static Static Reflection Fully reflective Introspection Introspection Semaphores, Some libraries Monitors Concurrency Monitors Categories, Namespaces Packages Modules namespaces © Oscar Nierstrasz 1.5 ST — Introduction Smalltalk: a State of Mind > Small and uniform language — Syntax fits on one sheet of paper >
    [Show full text]
  • Smalltalk Tutorial for Java Programmers!
    SmallTalk Tutorial for Java Programmers! SmallTalk Tutorial for Java Programmers! Giovanni Giorgi <[email protected]> Jan 2002 A small paper to teach yourself the incredible Smalltalk language! It's so easy, it's so fun! 1. Introduction ● 1.1 Revision history ● 1.2 Conventions used in this paper ● 1.3 Distribution Policy ● 1.4 Why Smalltalk? ● 1.5 Background Required 2. Why Smalltalk is so strange? (or a brief history of Smalltalk) ● 2.1 Download Right Now! ● 2.2 Hello world in Smalltalk ● 2.3 Big Numbers ● 2.4 Code Blocks ● 2.5 The while loop 3. Main Differences between Java and Smalltalk http://daitanmarks.sourceforge.net/or/squeak/squeak_tutorial.html (1 of 2) [1/7/2002 20:44:13] SmallTalk Tutorial for Java Programmers! ● 3.1 Java Versus Smalltalk ● 3.2 Types? No thank you!! ● 3.3 The Squeak base library compared with Java ● 3.4 The Smalltalk Code database ● 3.5 Multiple-Inheritance 4. Ending Words ● 4.1 Going on ● 4.2 Commercial and free products list ● 4.3 References http://daitanmarks.sourceforge.net/or/squeak/squeak_tutorial.html (2 of 2) [1/7/2002 20:44:13] SmallTalk Tutorial for Java Programmers!: Introduction 1. Introduction This paper will teach you the basics of Smalltalk80 language. This tutorial suites the needs of C and Java programmers. But the tutorial can be understanded by everyone knowing a bit of C and/or OOP concepts, as we'll see. Because I will refer a lot to other books and use a lot of technical terms, I'll try to enjoy you while reading.
    [Show full text]
  • Nested Class Modularity in Squeak/Smalltalk
    Springer, Nested Class Modularity in Squeak/Smalltalk Nested Class Modularity in Squeak/Smalltalk Modularität mit geschachtelten Klassen in Squeak/Smalltalk by Matthias Springer A thesis submitted to the Hasso Plattner Institute at the University of Potsdam, Germany in partial fulfillment of the requirements for the degree of Master of Science in ITSystems Engineering Supervisor Prof. Dr. Robert Hirschfeld Software Architecture Group Hasso Plattner Institute University of Potsdam, Germany August 17, 2015 Abstract We present the concept, the implementation, and an evaluation of Matriona, a module system for and written in Squeak/Smalltalk. Matriona is inspired by Newspeak and based on class nesting: classes are members of other classes, similarly to class instance variables. Top-level classes (modules) are globals and nested classes can be accessed using message sends to the corresponding enclosing class. Class nesting effec- tively establishes a global and hierarchical namespace, and allows for modular decomposition, resulting in better understandability, if applied properly. Classes can be parameterized, allowing for external configuration of classes, a form of dependency management. Furthermore, parameterized classes go hand in hand with mixin modularity. Mixins are a form of inter-class code reuse and based on single inheritance. We show how Matriona can be used to solve the problem of duplicate classes in different modules, to provide a versioning and dependency management mech- anism, and to improve understandability through hierarchical decomposition. v Zusammenfassung Diese Arbeit beschreibt das Konzept, die Implementierung und die Evaluierung von Matriona, einem Modulsystem für und entwickelt in Squeak/Smalltalk. Ma- triona ist an Newspeak angelehnt und basiert auf geschachtelten Klassen: Klassen, die, wie zum Beispiel auch klassenseitige Instanzvariablen, zu anderen Klassen gehören.
    [Show full text]
  • ECOOP Squeak Tutorial Worksheet 1A 2001.04.24 11:07
    ECOOP 2001 Tutorial Squeak: An Open Source Smalltalk for the 21st Century ECOOP 2001 — Budapest Squeak: An Open Source Smalltalk for the 21st Century! Andrew P. Black Professor, Oregon Graduate Institute OREGON GRADUATE INSTITUTE Squeak: An Open Source Smalltalk 1 of 44 — OF — SCIENCE &TECHNOLOGY What is Squeak? • An “Open Source” Smalltalk • A pure Object-Oriented language for research, experimentation, prototyping, building applications • Support for e-mail, web, sound, video, 3-D modeling, scripting, presentations... • An active community of people who are getting excited about programming again! • A “place” to experiment with objects OREGON GRADUATE INSTITUTE Squeak: An Open Source Smalltalk 2 of 44 — OF — SCIENCE &TECHNOLOGY What we won’t do this afternoon… • Listen to a 3-hour lecture telling you everything about Squeak Why? • I don’t know everything about Squeak! • Even if I did, I couldn’t tell you everything in 3 week, let alone 3-hours!! • What you learn would be out of date in a month anyway!!! OREGON GRADUATE INSTITUTE Squeak: An Open Source Smalltalk 3 of 44 — OF — SCIENCE &TECHNOLOGY What we will do: Learn how to learn about Squeak • Focus on showing you how to find out more • Explore objects • Explore source code • Try things out — learn by doing • Know to use the Swiki and the mailing list OREGON GRADUATE INSTITUTE Squeak: An Open Source Smalltalk 4 of 44 — OF — SCIENCE &TECHNOLOGY Outline 14:00 —Introduction 14:30 —Basic Smalltalk (Worksheet 1) – Worksheet on Squeak syntax, creating and browsing classes, instances and
    [Show full text]
  • Effective STL
    Effective STL Author: Scott Meyers E-version is made by: Strangecat@epubcn Thanks is given to j1foo@epubcn, who has helped to revise this e-book. Content Containers........................................................................................1 Item 1. Choose your containers with care........................................................... 1 Item 2. Beware the illusion of container-independent code................................ 4 Item 3. Make copying cheap and correct for objects in containers..................... 9 Item 4. Call empty instead of checking size() against zero. ............................. 11 Item 5. Prefer range member functions to their single-element counterparts... 12 Item 6. Be alert for C++'s most vexing parse................................................... 20 Item 7. When using containers of newed pointers, remember to delete the pointers before the container is destroyed. ........................................................... 22 Item 8. Never create containers of auto_ptrs. ................................................... 27 Item 9. Choose carefully among erasing options.............................................. 29 Item 10. Be aware of allocator conventions and restrictions. ......................... 34 Item 11. Understand the legitimate uses of custom allocators........................ 40 Item 12. Have realistic expectations about the thread safety of STL containers. 43 vector and string............................................................................48 Item 13. Prefer vector
    [Show full text]