Les classes sont remplacées par des patterns (PATTERN)
Etant donné l'orientation prototypes du nouveau paradigme par objets, il est incorrecte de conserver la notion de classes. En effet, les classes sont indiquées dans la cadre du typage statique d'objets qui ne peuvent pas être étendus dynamiquement.
Or, Abstrasy permet d'étendre et même de 'sous-classer' dynamiquement les objets, c-à-d leur faire hériter d'autres objets parents indépendamment de leur instanciation.
Il convient donc de supprimer la notion de classe.
Par contre, il reste intéressant de disposer d'une représentation abstraite du constructeur d'un certain type d'objets. Nous appellerons cela : pattern (comme en langage BETA).
Le pattern est, en Abstrasy, une sorte de plan, un modèle abstrait qui sert à construire un objet (dans cet aspect, la notion de pattern rejoint celle d'une classe). Toutefois, à la différence d'une classe, le pattern n'est pas le type de l'objet. C'est un patron, un modèle ou un plan de fabrication.
Le pattern fournit également (du moins partiellement pour l'instant) le cahier des charges (ou le contrat) de l'objet à fabriquer. Ainsi, le type primaire doit être déclaré dans le pattern. Si la fabrique ne retourne pas un objet de ce type primaire, une erreur des déclenchée.
Blueprint information
- Status:
- Complete
- Approver:
- Luc Bruninx
- Priority:
- Essential
- Drafter:
- Luc Bruninx
- Direction:
- Approved
- Assignee:
- Luc Bruninx
- Definition:
- Approved
- Series goal:
- Accepted for 1.0
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Luc Bruninx
- Completed by
- Luc Bruninx
Related branches
Related bugs
Sprints
Whiteboard
Le paradigme de programmation par objet en Abstrasy est complètement dynamique. Les objets peuvent être modifiés et étendu à n'importe quel moment. La notion de classe ne s'applique donc pas à ce type de langage.
En effet, la notion de classe implique un système de types statique. Lorsqu'un objet est fabriqué à partir d'une classe, il ne peut plus être modifié (sinon, il ne répond tout simplement plus aux spécifications de la classe à laquelle il appartient). De ce fait, les classes peuvent être utilisées comme des types immuables (un objet instancié à partir d'une classe ne peut pas en changer par la suite).
Or, Abstrasy est beaucoup plus souple à ce niveau. Les objets peuvent complètement muter.
Même l'interface d'un objet peut évoluer très facilement. L'interface d'un objet n'est rien d'autre qu'un sous-ensemble des propriétés de cet objet.
Un pattern est donc un modèle, ou un plan de fabrication d'un objet. L'intérêt principal des pattern consiste dans la réutilisation du code et non dans la mise en oeuvre d'un système de types.
Bien entendu, un pattern peut être utilisé comme une propriété particulière d'un certain type d'objet, mais à la différence d'une classe, le pattern d'un objet ne devrait pas en constituer le type.
Enfin, le pattern est nettement mieux adapté à un haut niveau de généricité que la classe. Bien qu'on puisse définir des classes dites génériques dans des langages avec un système de types
statique, il n'en demeure pas moins nécessaire de fournir un type spécifique à un moment ou à un autre du traitement. Par exemple, en Java, une ArrayList est effectivement un conteneur générique, toutefois, une bonne pratique impose de stipuler le type du contenu. Ainsi, par exemple, ArrayList<Integer> précise que le conteneur générique contient des élément dont le type est fixé à l'avance, il s'agit du type Integer. Donc, en conclusion, on reste enfermé dans un système de types statiques même s'il est partiellement générique. En comparaison, les listes d'Abstrasy peuvent recevoir des données de n'importe quel type. Les listes Abstrasy sont complètement génériques.
DONE : pattern (modèle)
DONE : pattern? (prédicat est-ce un modèle)
DONE : root (retourne l'objet fournit comme modèle à l'opérateur new).
Work Items
Dependency tree
* Blueprints in grey have been implemented.
