The Pharo community uses specific vocabulary to designate object oriented concepts, Pharo concepts and Pharo tools.
This page aims to provide disambiguation for the words belonging to this vocabulary.
The character a. In Pharo strings are composed of characters, a character starts with a $. For unprintable characters such as tab, just send the message to the class e.g., Character tab.
A binary message is a message composed of special character(s) where two objects are involved (the receiver and one argument), which is the reason it is call binary. This is mostly used for arithmetic, comparison, and logical operations. For example, + is a binary message involving the receiver and the argument in parameter.
According to wikipedia,
"Bootstrapping usually refers to a self-starting process that is supposed to proceed without external input."
In the case of Pharo, images are bootstrapped from the sources. Anyone can download the sources and create their own custom Pharo image. The Pharo continuous integration server launch the bootstrap process each time a pull-request is merged into pharo repository. This seems to be a natural process but one has to know that up to Pharo 7.0, images were not bootstrapped. This means that, each version of Pharo was in fact a copy of the previous image with some additional changes.
The browser is the tool for browsing and editing packages, classes and methods. In Pharo 6.1 and greater, the browser is called Calypso.
In the context of a method-call the candidates are the potential classes in the system that can receive the call. This list is computed from a static analysis of the source code.
The changesfile logs all source code modifications (especially all the changes you did while programming) since the sources file was generated. This facilitates a per-method history for diffs or reverting. It means that even if you did not manage to save the image file on a crash or you just forgot to, you can recover your changes from this file. A changes file is always coupled with an image file. They work as a pair.
Note: Since Pharo 5, a project called Epicea implementing a new logging system has been introduced in the system. The long term goal of Epicea is to replace the changes file, but this objective has not been reached yet.
The class-side of a class refers to its meta-class. This meta-class contains methods that can be sent to the class directly.
For example, #x:y: method (which creates an instance of Point with arbitrary x and y coordinates) is held by the meta-class of Point.
In Pharo, both Class and Metaclass understand #classSide method.
For example:
Point classSide. "Point class"
Point class classSide. "Point class"
Point includesSelector: #x:y:. "false"
Point class includesSelector: #x:y:. "true"The best way to understand what the class-side is, is to have a look at #classSide methods implementations:
Class>>#classSide
^ self classMetaclass>>#classSide
^ selfCog is the name of the virtual machine used by Pharo. It is also used by other programming languages such as Squeak, Newspeak and Cuis.
A Context represent a program execution. It will store, for example, the CompiledMethod being currently executed, the receiver and arguments of the message that invoked this CompiledMethod, the temporary variables, the stack of calls until the moment of the execution, ...
In Pharo, you can use the keyword thisContext to interact with the current context of your code. It will return the Context object at the moment of the execution. This object is different on each method call.
The Debugger is a tool opened by the system when an exception is raised and never got caught. This tool allows the developer to interact with the execution context that raised the error and its previous contexts. It lets the users inspect the objects present in this context and updates the code to fix the bug using the execution information as help.
Dispatch is a technique used in object-oriented programming to delegate behavior using polymorphism. The goal is to define a concept that will change depending on the context. For example we can have an application with commands. When we need to execute the commands, instead of creating a switch/case, each object will implement its own behaviour on a method of the same name and we just need to call this method.
See DoesNotUnderstand.
This name is used to describe the error that arises when a message is sent to an object but the object does not understand it. It also happens that people use the "DNU" shortcut.
Iceberg is git client integrated in the system since Pharo 7 (Pharo 6.1 contained a technical preview of the tool). It is a set of tools that allows one to handle git repositories directly from a Pharo image. Iceberg is the default repository manager for Pharo, allowing for smoother and faster integration of contributions, as well as better branch and version management.
A Pharo image is a snapshot of Pharo memory at any given moment. This is the file where all objects are stored and as such, it’s a cross platform format. An image file contains the live state of all objects of the system (including classes and compiled methods, since they are objects too) at a given point. It can bee seen as a virtual object container.
For a given selector in the system, implementors are classes that have a method with this selector (they implement the selector). For example the implementors of the method #banana are all the classes containing a method named #banana.
The Inspector is a Pharo tool which allows one to inspect objects, see their current state, interact with them and display specific information depending on the object. It offers multiple views and it uses a Finder as a navigation. One particular feature is that you can use the evaluator tab to enter code, and evaluating it results in the opening of another pane to the right.
An instance is a concrete realisation of a class. One can send messages to an instance. These messages correspond to methods defined by the class related to the instance. All instances of a class share the behaviour (methods) and structure (slots) defined by the class but two instances can hold different data in their slots.
The instance-side of a meta-class refers to its class. This class contains methods that can be sent to its instances.
For example, #x method (which returns the x coordinate of a point) is held by the class Point.
In Pharo, both Class and Metaclass understand #instanceSide method.
For example:
Point instanceSide. "Point"
Point class instanceSide. "Point"
Point includesSelector: #x. "true"
Point class includesSelector: #x. "false"The best way to understand what the instance-side is, is to have a look at #instanceSide methods implementations:
Class>>#instanceSide
^ selfMetaclass>>#instanceSide
^ self soleInstanceSee slot.
A keyword message is a message where two or more objects are involved (the receiver and the arguments). A message is composed of alphanumeric characters. The arguments are injected inside the message selector and must be preceded by a colon (:). For example, between:and: is a keyword message with a receiver and two arguments. It can be used like this: 13 between: 12 and: 14.
Late binding (or dynamic binding) is a general mechanism in which methods or functions called are looked up at run-time. This mechanism is the opposite of early binding that does the lookup at compilation-time and fixes all types of variables during that time. More concretely, it means that in Pharo, when you send a message to an object, the lookup of the method to execute is performed and then the method found by the lookup is executed. This simplifies the use of reflectivity since the user can invoke new methods without recompiling the whole application.
Method lookup is the name of the technique Pharo uses to find the method to execute when an object receives a message. It proceeds as follows: When a message is sent, methods in the receiver's class are searched for a matching method. If no match is found, the superclass is searched, and so on up the class chain. In the end, if no method is found, the object calls the method #doesNotUnderstand: with the message as a parameter.
A message represents an interaction between two objects. A sender sends a message to a receiver which will start a lookup. A message is composed of two elements: the selector, which is the name of the method to lookup, and argument values which are the values of each argument of the method to execute once found by the lookup. Three kinds of messages exists: unary messages, binary messages and keyword messages.
Monticello is a distributed versioning system for Squeak and Pharo code. It was the main versioning system until Pharo 6. It is now recommended to use Iceberg.
The word object is used to refer to a particular instance of a class. "Object" and "instance" words are synonyms.
The playground / workspace designate a code editor allowing one to run Smalltalk code that is not contained in a method.
This tool is useful to run small scripts that can be thrown after the execution.
If one needs to write a script that needs to be kept for a long time, it is better to right it as a class-method with the <script> pragma.
Pragmas are annotations on methods. They are used to attach additional properties to the methods to make those methods easily collectable through reflectivity and to ease the creation of special handlings. A page dedicated to pragmas is available here.
A primitive is a method for which the source code is not written in Smalltalk but directly in C code. From the inside of the image, those methods contain a <primitive:> pragma.
Some methods holding this primitive pragma also contain source code written in Smalltalk. For these methods, first the C version of the method is tried but if the implementation in C is not provided by the VM for some reason, Pharo falls back to the Smalltalk implementation.
In Pharo, each method belongs to a protocol. A protocol has a name and allows one to group methods that are related. For example, the protocol accessing is widely used in the system to hold accessor and mutator methods.
The receiver of a message send is the instance of a class implementing the method corresponding to the message sent receiving this message.
A selector corresponds to the signature of a method in the system. Since Pharo is not statically typed, the selector of a method is simply a Symbol. On a CompiledMethod, it is possible to send the #selector message to retrieve this Symbol.
Self is the receiver of a message an object sends to itself. This means that the lookup of a method send will start by the sender of this message then, if not found, it will proceed with its superclass.
The sender of a message is the object that will send a message to another object. In case the receiver of a message is self, then the sender is equal to the receiver.
For a given selector in the system, senders are the methods sending a message with this selector. For example, the senders of the method #banana are all the methods sending the message #banana in their code.
Sista is the name of a virtual machine with adaptive optimisations such as speculative inlining (meaning that the Virtual machine tries to guess the type of receiver and the arguments. Based on this, it heavily optimises the code at runtime, in case of a wrong guess it de-optimises the code). It showed better performance but is still currently under development. It is not yet production-ready.
The term "Slang" refers to a subset of the Smalltalk language that can be translated to C (or other language, such as Javascript). It is mainly used to develop the Cog virtual machine. It allows one to develop the virtual machine using Pharo tools and generates C.
Instance variables are reified in Pharo, which means they are real objects that can be manipulated just like any other object.
Because of that, the name slot has been given to the general concept of an instance variable in Pharo.
In practice, most of the slots in classes of the system are InstanceVariableSlot.
One can create a new kind of slot by subclassing Slot class (see this blogpost as an example).
Smalltalk is an object-oriented, dynamically typed reflective programming language with multiple implementations. Some implemenations include Squeak, VisualWorks, Gemstone, VA Smalltalk and many others. Pharo started as an implementation of Smalltalk and is still very close to it.
The sources file contains source code of Pharo. Sources file is important because the image file format stores only objects including compiled methods and their bytecode and not their source code. Originally, a new sources file was generated once per major release of Pharo. Now, Pharo changed its production mechanism to be bootstraped and generates a new sources file for each Pharo image produced.
Spur is the name of the current object representation in memory of Pharo used by the virtual machine. This representation is used since Pharo 5 and was introduced to improve performances (by 30% compared to the previous implementation) and prepare Pharo to run in 64bits.
Squeak is a dialect of Smalltalk. Pharo started as a fork of Squeak and both still share the same virtual machine.
Super is the receiver of a message an object send to itself, but on the contrary of self, the method lookup will start in the superclass of a receiver. Super is a unique way for the class to add behavior to the inherited methods and not just replace them.
Traits are pure units of behavior that can be composed to form classes or other traits. The trait composition mechanism is an alternative to multiple or mixin inheritance in which the composer has full control over the trait composition. It enables more reuse than single inheritance without introducing the drawbacks of multiple or mixin inheritance. A page dedicated to traits is available here.
An unary message is a message where only the receiver of the message will be required, which is the reason it is called unary. This means that the message will have no argument. For example, #factorial is an unary message that will only require the number receiving the message.
See virtual machine.
The virtual machine of Pharo is the execution engine. It takes Pharo bytecode that is generated each time the user compiles a piece of code, converts it to machine code and executes it. The VM is different for each platform running Pharo (windows, OSX, linux, arm, 32/64bits) and allows the other part of Pharo to be platform independent.
Workspace is the previous name of the Playground.