# A Catalog of Misconceptions in Pharo

Stéphane Ducasse, Christopher Fuhrman

► To cite this version:

Stéphane Ducasse, Christopher Fuhrman. A Catalog of Misconceptions in Pharo. RT-0523, Inria & Université de Lille. 2024. [hal-05044617](https://hal.science/hal-05044617v1)

HAL Id: hal-05044617

https://hal.science/hal-05044617v1

Submitted on 23 Apr 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Ínria

A Catalog of
Misconceptions in Pharo

Stéphane Ducasse, Christopher Fuhrman

RESEARCH
REPORT

Nº 0523

December 2024

Project-Team EVREF
<figure><img src="image_2.png" /></figure>
<figure><img src="image_3.png" /></figure>

# A Catalog of Misconceptions in Pharo

Stéphane Ducasse*, Christopher Fuhrman†

Project-Team EVREF

Research Report n° 0523 — December 2024 — 17 pages

**Abstract:** A misconception is a wrong perception of a concept. This report presents a catalog of misconceptions in Pharo. It is the result of (1) an informal survey with 57 software developers at ESUG23 to identify common misconceptions, (2) the contents of some books, and (3) the experience of object-oriented programming and design teachers. We discuss the implications of these findings for teaching and learning Pharo and more generally object-oriented concepts (since many misconceptions are related to misunderstanding of essential aspects of object-oriented programming).

**Key-words:** Object-Oriented Design, Misconceptions, Pharo, Smalltalk, Object-Oriented Programming

RESEARCH CENTRE
Centre Inria de l'Université de Lille

Parc scientifique de la Haute-Borne
40 avenue Halley - Bât A - Park Plaza
59650 Villeneuve d'Ascq

<footnote>* Inria - Evref - France - stephane.ducasse@inria.fr</footnote>

<footnote>† ETS Montreal - Canada - christopher.fuhrman@gmail.com</footnote>
Un catalogue de misconceptions en Pharo

**Résumé** : Une idée fausse (misconception) est une perception erronée d'un concept. Ce rapport présente un catalogue des idées fausses dans le Pharo. Il est le résultat (1) d'une enquête informelle auprès de développeurs de logiciels de la conférence ESUG23 pour identifier les idées fausses les plus courantes, (2) du contenu de certains livres, et (3) de l'expérience des professeurs de programmation et de conception orientées objet. Nous discutons des implications de ces résultats pour l'enseignement et l'apprentissage du langage Pharo et autre langages à objets.

**Mots-clés** : Object-Oriented Design, Misconceptions, Pharo, Smalltalk, Object-Oriented Programming
# Contents

<table><tr><td>1</td><td>Introduction</td><td>4</td></tr><tr><td>2</td><td>Background</td><td>4</td></tr><tr><td>3</td><td>A Misconception Catalog</td><td>5</td></tr><tr><td>4</td><td>Conceptual object-oriented misconceptions</td><td>6</td></tr><tr><td>4.1</td><td>super is the superclass</td><td>7</td></tr><tr><td>4.2</td><td>super is an instance of the superclass</td><td>7</td></tr><tr><td>4.3</td><td>super starts the lookup in the superclass of the class of receiver</td><td>7</td></tr><tr><td>4.4</td><td>The definition of a lambda expression is its execution</td><td>8</td></tr><tr><td>4.5</td><td>A datastructure is an object</td><td>8</td></tr><tr><td>5</td><td>Pharo object model-specific misconceptions</td><td>9</td></tr><tr><td>5.1</td><td>By default a method does not return a value</td><td>9</td></tr><tr><td>5.2</td><td>Class side initialize method must invoke super initialize</td><td>9</td></tr><tr><td>5.3</td><td>A class method is a static method</td><td>10</td></tr><tr><td>5.4</td><td>self in a class method refers an instance of the class</td><td>10</td></tr><tr><td>5.5</td><td>A shared variable (classVariable) is the same as a metaclass instance variable</td><td>11</td></tr><tr><td>5.6</td><td>A class must be written in a file</td><td>11</td></tr><tr><td>5.7</td><td>There must be a main function</td><td>12</td></tr><tr><td>6</td><td>Pharo syntactic misconceptions</td><td>12</td></tr><tr><td>6.1</td><td>"is" is a string</td><td>12</td></tr><tr><td>6.2</td><td>Equals symbol is an assignment</td><td>12</td></tr><tr><td>6.3</td><td>Equals symbol is an operator</td><td>13</td></tr><tr><td>6.4</td><td>A keyword is a sequence of messages</td><td>13</td></tr><tr><td>6.5</td><td>True represents the boolean true</td><td>14</td></tr><tr><td>6.6</td><td>False represents the boolean false</td><td>14</td></tr><tr><td>7</td><td>Pharo library misconceptions</td><td>14</td></tr><tr><td>7.1</td><td>Collections start at zero</td><td>14</td></tr><tr><td>7.2</td><td>add: returns the receiver</td><td>15</td></tr><tr><td>8</td><td>Infrastructure</td><td>15</td></tr><tr><td>8.1</td><td>An image is not a code versioning system</td><td>15</td></tr><tr><td>9</td><td>Conclusion</td><td>16</td></tr></table>
# 1 Introduction

A misconception is the wrong perception of a concept. This report presents a catalog of misconceptions in Pharo. It is the result of (1) an informal survey with 57 software developers at ESUG23 to identify common misconceptions, (2) the contents of some books, and (3) the experience of object-oriented programming and design teachers. We discuss the implications of these findings for teaching and learning Pharo and more generally object-oriented concepts (since many misconceptions are related to misunderstanding of essential aspects of object-oriented programming).

# 2 Background

Concept inventories started in the domain of Newtonian physics [HWS92]. The Force Concept Inventory [SS02] is a multiple-choice test designed to measure students’ understanding of kinematics. It has proven to be a powerful tool for improving teaching and learning of mechanics.

An important step in identifying a concept inventory is identifying misconceptions, which are essentially common misunderstandings. A good example of a misconception is the common belief that the seasons on Earth are caused by the change in distance between the Earth and the Sun during the year.

**Misconceptions in OOP.** While object-oriented concepts are well-known today, it is still surprising to read books with wrong programs or leading to programs that endlessly loop. If the supposed experts are making important conceptual errors and that the publishing industry is not in capacity to publish books without garbage, there is a definitive need for misconception definition in our field. This one of the key motivation for the misconceptions presented in this article.

The goal of identifying a concept inventory in object-oriented (OO) and agile development is to improve the learning and teaching of concepts in agile development in the domain of software engineering and software development. OO software development is a popular development approach today in the industry.

Agile methods have been taught in universities for at least 20 years [BF01]. They are popular in industry because of how they manage complexity and risk, compared to traditional strategies (e.g., so-called waterfall methodology). Agile includes test-driven development and iterative and incremental design. These approaches are very popular today in industry, especially with continuous integration (CI) and continuous deployment (CD) allowing companies to deliver robust with frequent new functionalities. It is pertinent that students grasp these concepts and be able to meet the needs of industry.

Concept inventories have been applied to computer science [TZP+14, CFBSA19, SSW+21]. Work in identifying misconceptions in programming languages has been done, e.g., by Caceffo et al. [CFBSA19]. The added value of concept inventories in physics has been shown, but in computer science more work needs to be done. The domain presents challenges, because - unlike physics - computing methodologies, languages, tools and technologies can evolve relatively quickly. Universities struggle to maintain their quality course offerings in the face of constant modernization, to focus on and keep the core essential elements, but also to be sure they are being properly taught using modern languages and environments.

**About Pharo.** Pharo is a modern reflective dynamically typed object-oriented language [BDN+09, DRK+22] inspired by Smalltalk [?]. It follows the purity and elegance of its ancestor: the full
syntax fits on half of postcard and the model simple. Everything is an object instance of a class (including classes). Fields are protected, methods are all virtual and public. A class singly inherits from their superclass, it can be composed out of traits (groups of methods sharing optional state). Lexical closures are first-class citizen. Aside of messages, the constructs are local variable declaration, assignment, return, sequence.

# 3 A Misconception Catalog

**Categories.** Other work on misconceptions in computer science reported the following categories:

* **Incorrect Syntax and Semantics.**

Misconceptions may involve learners misunderstanding or misusing the syntax (the structure and rules for writing code) and semantics (the meaning and behavior of code) of the programming language. This could include errors in variable declarations, function calls, control structures, or data manipulation.

* **Flawed Problem-Solving Approaches.**

Learners might hold misconceptions about the best practices and algorithms for solving programming problems. For example, they might use inefficient or incorrect algorithms due to a misunderstanding of the language's capabilities or limitations.

* **Overgeneralization.**

Learners may generalize their understanding of one programming language to another, assuming that concepts and syntax are identical across languages when they are not. This can lead to incorrect usage of language-specific features.

* **Incomplete or Outdated Information.**

Misconceptions can also arise from outdated or incomplete learning resources. Programming languages evolve over time, and learners who rely on outdated tutorials or documentation may acquire incorrect information.

* **Misunderstanding Language Features.**

Some learners may misunderstand the purpose and behavior of specific language features, leading to the inappropriate use or avoidance of those features in their code.

* **Poor Problem Solving Habits.**

Misconceptions can result in poor problem-solving habits, such as reliance on code snippets found online without understanding their underlying principles.

* **Debugging and Troubleshooting Errors.**

Misconceptions can make it challenging for learners to debug and troubleshoot their code effectively, as they may be looking in the wrong places for errors or making incorrect assumptions about the cause of issues.

* **Interference from Previous Programming Languages.**

Learners who have experience with one programming language may carry over assumptions and practices from that language to a new language they are learning. This can result in misconceptions when the new language follows different conventions or has different rules.
For example, transitioning from a 0-based array indexing language like C to a 1-based indexing language like Pharo could lead to misconceptions about array handling, indexing, and looping constructs.

**Categories for object-oriented misconceptions.** In the context of this report we identified several families of misconceptions:

* **Conceptual object-oriented misconceptions.** Such misconceptions are not linked to a given object-oriented language. They are universal in the sense that they apply to any object-oriented language supporting the feature that is the source of misunderstanding.

* **Pharo object model-specific misconceptions.** Such misconceptions are related to misconceptions related to Pharo specific aspects such as metaclasses or reflective properties.

* **Pharo syntactic misconceptions.** Such misconceptions are linked to specific language constructs of Pharo.

* **Pharo library misconceptions.** Such misconceptions are related to the API of the libraries of Pharo.

* **Pharo infrastructure misconceptions.** Such misconceptions are related to the understanding of some runtime artefact of Pharo.

**Catalog entry.** The following catalog is structured around catalog entries. A catalog entry represents a misconception and it is defined by the following elements:

* a name (often a sentence) describing the misconception.

* followed by one sentence describing the *correct* concept.

* a small example and explanation.

**About misconception title.** The authors of the present report followed the naming of misconceptions as promoted in literature [CFBSA19]. But the first author has a fundamental disagreement about promoting the name of a wrong concept. As an author of patterns [DDN02] and given that patterns are about the creation of a common vocabulary, he is against spreading bad concepts. This is similar to the definition of AntiPatterns [BMMM98] vs. Design Patterns [GHJV95, BMR$^+$96, ABW98] or Reengineering patterns [DDN02, SSS16]. We believe that using the true concept would be more effective in the sense that remembering the correct concept is better than a mistake.

# 4 Conceptual object-oriented misconceptions

Many of the following misconceptions are not specific to Pharo but related to the concepts of object-oriented programming and design. Some of these misconceptions (around the semantics of *super*) are so strong that even authors of published books in computer science repeat them.
## 4.1 super is the superclass

**Misconception** ⚠ The pseudo-variable **super** is the superclass of the class of the receiver.

**Correct** 💡 The pseudo-variable **super** is the receiver of the message.

**Correction** 🤷

The following code snippet checks that the identity of the object referred to by the pseudo variable **super** is the same as the one referred to by the pseudo-variable **self**. The message **==** returns if the pointers of the receiver and argument are the same.

Listing 1: **super** is the receiver of the message.

```ruby
A >> test
    ^ super == self

---
A new test
> true
```

## 4.2 super is an instance of the superclass

**Misconception** ⚠ The pseudo-variable **super** is an instance of the superclass.

**Correct** 💡 The pseudo-variable **super** is the receiver of the message.

**Correction** 🤷 The following code snippet checks that the identity of the object referred to by the pseudo variable **super** is the same as the one referred to by the pseudo-variable **self**. The message **==** returns if the pointers of the receiver and argument are the same.

Listing 2: **super** is the receiver of the message.

```ruby
A >> test
    ^ super == self

---
A new test
> true
```

## 4.3 super starts the lookup in the superclass of the class of receiver

**Misconception** ⚠ The pseudo-variable **super** is an instance of the superclass.

**Correct** 💡 The lookup of the method to a message sent to the **super** pseudo-variable starts in the superclass of the class containing the expression (**super**).

**Correction** 🤷

The following example defines three classes: A, B, and C. Class C does not define a method m. The execution of the expression C new m returns 52. It illustrates that looking for the method m in the expression **super** m is not looked up in the superclass of the class of the receiver. Indeed using this semantics makes C new m endlessly loop. The reader of the present article can decompose step by step the method lookup using the misconception. It should be noted that the misconception works when executed on two classes but loops as soon as the class hierarchy has more than two classes.
Listing 3: super lookup starts in the superclass of the class containing the expression.

```
A subclass: #B
B subclass: #C

A >> m
    ^ 42

B >> m
    ^ super m + 10

---
C new m
    > 52
```

## 4.4 The definition of a lambda expression is its execution

**Misconception** ⚠ The definition of a lambda expression is its execution

**Correct** 💡 Defining a lambda just defines it. To execute it we should explicitly send the message value to a definition.

**Correction** 🤷

The following snippet shows that the definition of a lambda returns a lambda. Here `[ 10 / 0 ]` does not raise an error because the lambda is not executed. It raises an error when defined and executed as in the expression `[ 10 / 0 ]` value

Listing 4: Lambda definition vs. execution.

```
[ 10 + 1 ]
> [ 10 + 1 ]

[ 10 / 0 ]
> [ 10 / 0 ]

[ 10 + 1 ] value
> 11

[ 10 / 0 ] value
> Error
```

## 4.5 A datastructure is an object

**Misconception** ⚠ A datastructure is an object.

**Correct** 💡 An object should have a rich API and not be just a set of getters and setters.

**Correction** 🤷 We cannot simply illustrate this point within a couple of lines of code. We suggest the reader to compare the API of the class `Point` in Java and the class `Point` in Pharo. In Java the class offers a couple of setters and getters and one method to translate the receiver. The Pharo implementation of the class `Point` defines 104 methods (once remove the accessors) grouped in the following categories: arithmetic, comparing, converting, transforming, truncation and round off, rectangle creation, point functions, copying, extent functions, interpolating, testing, self evaluating, printing, geometry.
<caption>Listing 5: Java API for Point.</caption>

```java
Point ReportsLocation()
void setLocation(double x, double y)
void setLocation(int x, int y)
void setLocation(Point p)
double_X()
double_Y()
boolean equals(Object obj)
void move(int x, int y)
void translate(int dx, int dy)
String toString()
int distance()
Point clone()
```

# 5 Pharo object model-specific misconceptions

The misconceptions of this section are about the specific object-oriented aspects of Pharo such as the default value returned by a class, the use of metaclasses.

## 5.1 By default a method does not return a value

**Misconception** ⚠ By default a method does not return a value.

**Correct** 🤔 A method can answer any result, any object. By default, it returns the receiver.

**Correction** 👤 The following snippet shows the definition of a method. The method does not contain an explicit return therefore the compiler adds a return expression returning the receiver.

Sending the message `foo` to an instance of `A` returns such instance.

<caption>Listing 6: By default a method return the receiver.</caption>

```ruby
A >> foo
| t |
t := 42

is in fact

A >> foo
| t |
t := 42.
~ self

----
aA := A new.
aA foo
> aA
```

## 5.2 Class side initialize method must invoke super initialize

**Misconception** ⚠ Class side initialize must contain super initialize.
**Correct** 🔧 Class side initialize method may optional invoke their overridden method via super initialize.

**Correction** 👷 When invoking super initialize, a class side method of the superclass may reinitialize the state of the superclass and lose changes that could have been made. Therefore invoking the superclass class initialize method (using super initialize) is optional.

This is not mandatory to invoke superclass class initialize methods. It depends on the logic of the application. Developers should pay attention that superclasses may have stored additional contents that is not the same as the original initialization. Blindly invoking the initialize class method of a superclass may reinitialize their state (losing state that may have been redefined after the initialization of the class variables).

## 5.3 A class method is a static method

**Misconception** ⚙️ A class method is a static method.

**Correct** 🔧 A class method is **not** a static method in the sense that it is dynamically looked up as any method of the system.

**Correction** 👷 In Pharo there is no concept of static method or constructor in the sense of Java. Any method is dynamically looked up. This is true for instance but also class methods. In fact, the underlying execution engine does not make any difference (and does not distinguish between class and instance methods).

Listing 7: Class methods are not static but dynamically looked up as instance methods.

```
Object subclass: #A.
A subclass: #B.
B subclass: #C.

A class >> m
    ~ 42

---
C m
> 42
```

## 5.4 `self` in a class method refers an instance of the class

**Misconception** ⚙️ The pseudo-variable self in a class method refers to the class itself.

**Correct** 🔧 The pseudo-variable self in a class method refers to the class. In it refers to the receiver of the method and since the method is a class method, it is a method that is executed when a message is sent to a class.

**Correction** 👷 In the example below, self in the class method foo refers to the receiver of the message `x foo`. When sending the message `Box foo`, self in class method `foo` refers to the class `Box`. Imagine a subclass of `Box` named `SubBox`, when sending the message `SubBox foo`, self in class method `foo` refers to the class `SubBox`.

Listing 8: When message `Box foo`, in method `foo` self is class `Box`

```
Box class >> foo

    ^ self new setText: 'tintin'
```
## 5.5 A shared variable (classVariable) is the same as a metaclass instance variable

**Misconception** ⚠ A shared variable (classVariable) is the same as a metaclass instance variable.

**Correct** ❧ A shared variable is **shared** (named classVariable in Smalltalk) amongst all the subclasses and it is accessible from both the instance and class side. This is totally different for an instance variable of a class which is specific to a class (as a value of the variable x is private to a given point object).

An instance variable of a class describes the value of an instance that happens to be a class. Therefore, each subclass of a class defining a class instance variable has its own value for such a variable. A class instance variable is similar to an instance variable in terms of scope and visibility. It is just an instance variable of an object that is a class.

**Correction** 🤷 The book Pharo by example [DRK+22] page 137 explains the fact that class instance variables are not shared between instances or classes but are private to the class itself. We reuse here the example: the class Dog has a class instance variable named count. It is initialized to zero and the new method is redefined to increase this counter.

Now each subclass has its own count value.

```
Object subclass: #Dog
Dog class
    instanceVariableNames: 'count'
Dog class >> initialize
    count := 0.
Dog class >> new
    count := count +1.
    ^ super new
Dog subclass: #Hyena
```

---

```
Dog initialize.
Hyena initialize.
Dog count
> 0
```

```
| aDog |
aDog := Dog new.
```

```
Dog count
> 1 "Incremented"
```

```
Hyena count
> 0 "Still the same"
```

## 5.6 A class must be written in a file

**Misconception** ⚠ A class must be written in a file in a folder on a hard disc
**Correct** 🔧 Nothing in object-oriented programming concepts enforces the notion that code should be in a file. This constraint has been pushed by Java but each language is free to define how programming concepts (classes, methods...) should be physically stored. A class definition does not have to be defined in a file. A file is a physical support.

**Correction** 👷 In Pharo, classes are objects: they exist in memory. A class definition is an expression that by side effect creates an object representing the class. This definition does not have to be placed in a file as in Java. Class definitions can be saved in a file as a form of serialization but this is not mandatory. Classes can be saved in binary format in databases or any format. By default, Pharo supports Git format or simple textual file format but the class definition could be stored in a database similar to what VisualWorks is doing with the Store product.

## 5.7 There must be a main function

**Misconception** ⚙️ A program must define a main function to be able to execute.

**Correct** 🔧 In object-oriented programming, there is no need for a main function. This is a legacy from C procedural programming that has been pushed by Java. Accessing a class and sending a message is enough to launch program execution. In Pharo, there is no need for a main function. A message sent to a class is enough to start a program.

**Correction** 👷 In Pharo, programs with a user interface are often launched by asking an application to run.

# 6 Pharo syntactic misconceptions

The misconceptions of this section are about the specific syntactical aspects of Pharo.

## 6.1 "is" is a string

**Misconception** ⚙️ "is" is a string

**Correct** 🔧 Double quotes delimit comments. A string is delimited with a single quote.

**Correction** 👷

As shown by the following examples: single quotes delimit literal string in Pharo while double quotes delimit a comment.

<caption>Listing 9: A string is delimited by a single quote</caption>

```
'is a string'
"I'm a comment"
```

## 6.2 Equals symbol is an assignment

**Misconception** ⚙️ The equals symbol = is an assignment operator in Pharo.

**Correct** 🔧 The equals symbol = is a message to check object equality; it is not an assignment operator. The assignment operator in Pharo is expressed using :=.

**Correction** 👷 To assign a value to a variable in Pharo, use the assignment operator := instead of the equals symbol =.
Listing 10: Assignment using `:=` and equality check using `=`

```
| x y |
x := 5.
y := 5.
x = y. "true"
```

## 6.3 Equals symbol is an operator

**Misconception** ⚠ The equals symbol `=` is an operator in Pharo.

**Correct** 💡 The equals symbol `=` is a predicate message that checks the equality between the receiver and the argument. As such, every class in the system may define it to have a specialized behavior for evaluating equality. The `==` message is a predicate message that checks the identity between the receiver and the argument.

**Correction** 🤷 To verify object equality in Pharo, use the equals message `=`. Remember that every class in the system may override (specialize) this message. If you do override it, make sure to also override the hash message.

Although you should override `=` and `hash` together, you should *never* override `==`. The semantics of object identity is the same for all the classes. Message `==` is a primitive method of `ProtoObject`. By default object equality is object identity until a class redefines it.

Listing 11: The `=` message is checking that two objects are equals

```
12 = 13
> false
```

```
12 = 12
> true
```

## 6.4 A keyword is a sequence of messages

**Misconception** ⚠ A keyword is a sequence of messages.

**Correct** 💡 A keyword-based message is a **single** message. Its name is composed of parts. For example, `between:and:` is a single message and not two messages but it is composed of the parts `|ctbetween:` and `and:`.

**Correction** 🤷

Listing 12: Keywords and messages

```
"The message between:and: is sent
to the number 7 with two arguments 5 and 10."
```

```
7 between: 5 and: 10
```

```
"The message between: is sent to 7 with 5.
The message and: is sent to the result of the previous
expression with argument 10. "
```

```
(7 between: 5) and: 10
```
## 6.5 True represents the boolean true

**Misconception** ⚠ True represents the boolean true.

**Correct** 🔧 True is a class. It inherits from the class Boolean. It has a unique instance called true.

**Correction** 👤 True and False are classes. The names start with an uppercase has any class or global variable. true and false are two pseudo variables defined by the runtime. true refers to the unique instance of the class True. false is the unique instance of the class False.

Listing 13: true is the boolean True

```false
true ifTrue: [ 2 ]
> 2
```

## 6.6 False represents the boolean false

**Misconception** ⚠ False represents the boolean false. **Correct** 🔧 False is a class. It inherits from the class Boolean. It has a unique instance called false.

**Correction** 👤 True and False are classes. The names start with an uppercase has any class or global variable. true and false are two pseudo variables defined by the runtime. true refers to the unique instance of the class True. false is the unique instance of the class False.

Listing 14: false is the boolean False

```false
false ifFalse: [ 2 ]
> 2
```

# 7 Pharo library misconceptions

This section lists some misconceptions that are related to the design of certain APIs.

## 7.1 Collections start at zero

**Misconception** ⚠ Collections start at zero.

**Correct** 🔧 In Pharo, following the design of Smalltalk [?], the first element of a collection is stored at the first index. Collections are 1-based.

**Correction** 👤 Smalltalk was invented to teach programming to kids. For them, it is natural that the first element of a collection starts at index 1. Pharo follows its design. The following shows that element 11 (the first element of the array) is at index 1.

Listing 15: Collections first index is at 1.

```pharo
#( 11 21 31 ) at: 1
> 11
```
## 7.2 add: returns the receiver

**Misconception** ⚠ The message add: returns the receiver of the message

**Correct** 💡 The message add: defined on Collection classes always returns its argument.

**Correction** 👷 This is a design choice that is probably based on the fact that there is a good chance that the collection will be referenced from the state of an object, while the argument may be the result of a message. Deciding that add: returns the argument allows the developer to access the argument without being forced to store it before passing it to the message add:

The idiom then is to use the message **yourself** to access the receiving collection.

<caption>Listing 16: add: message usage.</caption>

```
| col |
col := OrderedCollection new.
col add: 55.
col add: 66
> 66
```

The following two code snippets are equivalent.

<caption>Listing 17: add: message usage.</caption>

```
| col |
col := OrderedCollection new.
col add: 55.
col add: 66
col
```

OrderedCollection new
    add: 55;
    add: 66;
    yourself

# 8 Infrastructure

## 8.1 An image is not a code versioning system

**Misconception** ⚠ In Pharo, an image refers to a memory dump of all the objects represented in the heap of the system. Here are two sentences reflecting the wrong perception of what is an image. "When I want to share my code, I can send you my image." "I can add my Pharo image into Git."

**Correct** 💡 An image is a memory dump, and as such it contains all the objects of the system, including classes and methods. It is really powerful since we can produce snapshots and rerun them later on with exactly the same objects at the same place. Nevertheless, an image is not an artifact to version and share code. Code should be stored using systems such as Git or other versioning systems.

**Correction** 👷 Define an account on any Git services such as Gitlab or Github. Publish your code there and share the repository with others.
# 9 Conclusion

This report identified some key misconceptions both at the level of object-oriented concepts and the Pharo meta model or infrastructure. It is a guide for future teachers to understand what students misunderstand.

# References

[ABW98] Sherman R. Alpert, Kyle Brown, and Bobby Woolf. *The Design Patterns Smalltalk Companion*. Addison Wesley, Boston, MA, USA, 1998.

[BDN+09] Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker. *Pharo by Example*. Square Bracket Associates, Kehrsatz, Switzerland, 2009.

[BF01] Kent Beck and Martin Fowler. *Planning Extreme Programming*. Addison Wesley, 2001.

[BMMM98] William J. Brown, Raphael C. Malveau, Hays W. McCormick, III, and Thomas J. Mowbray. *AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis*. John Wiley Press, 1998.

[BMR+96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stad. *Pattern-Oriented Software Architecture — A System of Patterns*. John Wiley Press, 1996.

[CFBSA19] Ricardo Caceffo, Pablo Frank-Bolton, Renan Souza, and Rodolfo Azevedo. Identifying and validating java misconceptions toward a cs1 concept inventory. In *Proceedings of the 2019 ACM Conference on Innovation and Technology in Computer Science Education*, pages 23–29, 2019.

[DDN02] Serge Demeyer, Stéphane Ducasse, and Oscar Nierstrasz. *Object-Oriented Reengineering Patterns*. Morgan Kaufmann, 2002.

[DRK+22] Stéphane Ducasse, Gordana Rakic, Sebastijan Kaplar, Quentin Ducasse. Originally written by A. Black, S. Ducasse, O. Nierstrasz, D. Pollet with D. Cassou, and M. Denker. *Pharo 9 by Example*. Book on Demand – Keepers of the lighthouse, 2022.

[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. *Design Patterns: Elements of Reusable Object-Oriented Software*. Addison-Wesley, 1995.

[HWS92] David Hestenes, Malcolm Wells, and Gregg Swackhamer. Force concept inventory. *The physics teacher*, 30(3):141–158, 1992.

[SS02] Antti Savinainen and Philip Scott. The force concept inventory: a tool for monitoring student learning. *Physics education*, 37(1):45, 2002.

[SSS16] Ganesh Samarthyam, Girish Suryanarayana, and Tushar Sharma. Refactoring for software architecture smells. In *Proceedings of the 1st International Workshop on Software Refactoring*, pages 1–4, 2016.
[SSW$^{+21}$] Yang Shi, Krupal Shah, Wengran Wang, Samiha Marwan, Poorvaja Penmetsa, and Thomas Price. Toward Semi-Automatic Misconception Discovery Using Code Embeddings. In *LAK21: 11th International Learning Analytics and Knowledge Conference*, LAK21, pages 606–612. Association for Computing Machinery, April 2021.

[TZP$^{+14}$] Cynthia Taylor, Daniel Zingaro, Leo Porter, Kevin C Webb, Cynthia Bailey Lee, and Mike Clancy. Computer science concept inventories: past and future. *Computer Science Education*, 24(4):253–276, 2014.
Inria

RESEARCH CENTRE
Centre Inria de l'Université de Lille

Parc scientifique de la Haute-Borne
40 avenue Halley - Bât A - Park Plaza
59650 Villeneuve d'Ascq

Publisher
Inria
Domaine de Voluceau - Rocquencourt
BP 105 - 78153 Le Chesnay Cedex
inria.fr

ISSN 0249-6399