Spec -- Technical Report

This paper introduces the bases of Spec in two parts: (1) an example of implementation, reuse , and specialization of sub widgets, (2) the public API of the basic widgets.Ce papier présente les bases de Spec en deux parties: (1) un exemple d'implémentation, de réutilisation et de spécialisation de sous widgets, (2) l'API publique des widgets basiques

Spec: A Framework for the Specification and Reuse of UIs and their Models

International audienceImplementing UIs is often a tedious task. To address this, UI Builders have been proposed to support the description of widgets, their location, and their logic. A missing aspect of UI Builders is however the ability to reuse and compose widget logic. In our experience, this leads to a significant amount of duplication in UI code. To address this issue, we built Spec: a UIBuilder for Pharo with a focus on reuse. With Spec, widget properties are defined declaratively and attached to specific classes known as composable classes. A composable class defines its own widget description as well as the model-widget bridge and widget interaction logic. This paper presents Spec, showing how it enables seamless reuse of widgets and how these can be customized. After presenting Spec and its implementation, we discuss how its use in Pharo 2.0 has cut in half the amount of lines of code of six of its tools, mostly through reuse. This shows that Spec meets its goals of allowing reuse and composition of widget logic.La mise en œuvre des interfaces utilisateur est souvent une tâche fastidieuse. Pour y remédier, des UI Builder ont été proposées pour soutenir la description des widgets, leur emplacement et leur logique. Un aspect manquant des UI Builder est toutefois la possibilité de réutiliser la logique et composer les widgets. D'après notre expérience, cela conduit à une quantité importante de duplication dans le code d'interfaces utilisateur. Pour résoudre ce problème, nous avons construit Spec: un UI Builder pour Pharo en mettant l'accent sur ​​la réutilisation. Avec Spec, les propriétés du widget sont définies de manière déclarative et attachées à des classes spécifiques connues sous le nom des classes composables. Une classe composable définit sa description de widget ainsi que le lien entre le modèle et le widget ainsi que la logique d'interaction avec le widget. Cet article présente Spec, en montrant comment elle permet une réutilisation transparente des widgets et comment ceux-ci peuvent être personnalisés. Après avoir présenté Spec et sa mise en œuvre, nous discutons de la façon dont son utilisation dans Pharo 2.0 a réduit de moitié la quantité de lignes de code de six de ses outils, principalement grâce à la réutilisation. Cela montre que Spec atteint ses objectifs de permettre la réutilisation et la composition de la logique des widgets

Seamless Composition and Reuse of Customizable User Interfaces with Spec

International audienceImplementing UIs is often a tedious task. To address this, UI Builders have been proposed to support the description of widgets, their location, and their logic. A missing aspect of UI Builders is however the ability to reuse and compose widget logic. In our experience, this leads to a significant amount of duplication in UI code. To address this issue, we built Spec: a UIBuilder for Pharo with a focus on reuse. With Spec, widget properties are defined declaratively and attached to specific classes known as composable classes. A composable class defines its own widget description as well as the model-widget bridge and widget interaction logic. This paper presents Spec, showing how it enables seamless reuse of widgets and how these can be customized. After presenting Spec and its implementation, we discuss how its use in Pharo 2.0 has cut in half the amount of lines of code of six of its tools, mostly through reuse. This shows that Spec meets its goals of allowing reuse and composition of widget logic

Bootstrapping Reflective Systems: The Case of Pharo

International audienceBootstrapping is a technique commonly known by its usage in language definition by the introduction of a compiler written in the same language it compiles. This process is important to understand and modify the definition of a given language using the same language, taking benefit of the abstractions and expression power it provides. A bootstrap, then, supports the evolution of a language. However, the infrastructure of reflective systems like Smalltalk includes, in addition to a compiler, an environment with several self-references. A reflective system bootstrap should consider all its infrastructural components. In this paper, we propose a definition of bootstrap for object-oriented reflective systems, we describe the architecture and components it should contain and we analyze the challenges it has to overcome. Finally, we present a reference bootstrap process for a reflective system and Hazelnut, its implementation for bootstrapping the Pharo Smalltalk-inspired system

Bootstrapping a Smalltalk

International audienceSmalltalk is a reflective system. It means that it is defined in itself in a causally connected way. Traditionally, Smalltalk systems evolved by modifying and cloning what is called an image (a chunk of memory containing all the objects at a given point in time). During the evolution of the system, objects representing it are modified. However, such an image modification and cloning poses several problems: (1) There is no operational machine-executable algorithm that allows one to build a system from scratch. A system object may be modified but it may be difficult to reproduce its exact state before the changes. Therefore it is difficult to get a reproducible process. (2) As a consequence, certain classes may not have been initialized since years. (3) Finally, since the system acts as a living system, it is not simple to evolve the kernel for introducing new abstractions without performing some kind of brain surgery on oneself. There is a need to have a step by step process to build Smalltalk kernels from scratch. In this paper, after an analysis of past and current practices to mutate or generate kernels, we describe a kernel bootstrap process step-by-step. First the illusion of the existence of a kernel is created via stubs objects. Second the classes and meta-classes hierarchy are generated. Code is compiled and finally information needed by the virtual machine and execution are generated and installed