<h1>Besoin, cas d'utilisation</h1>
<ul>
<li><p>Limiter l'accès des prototypes `low_level' aux seuls prototypes des dossiers
parents. Interdire leur utilisation ailleurs</p></li>
<li><p>Pouvoir classer des prototypes dans des dossiers sans pour autant limiter leur
portée. Il doit être possible d'utiliser un prototype très profond dans la
hierarchie si cela a été prévu.</p></li>
<li><p>Permettre de limiter l'accès de certains prototypes au projet uniquement (par
exemple limiter l'utilisation des prototypes à la lib uniquement) sans
contrainte sur leur chemin complet</p></li>
<li><p>Lorsque deux prototypes ont le même nom, le prototype le plus proche dans
l'arborescence doit être choisi.</p></li>
<li><p>Lorsque deux prototypes ont le même nom mais que l'un est dans le même projet
et l'autre en dehors, le prototype à l'intérieur du projet doit être choisi.</p></li>
<li><p>Interdire l'utilisation d'un prototype d'un autre projet sauf si celui-ci est
explicitement importé.</p></li>
</ul>
<h1>Exemple</h1>
<p>Voici un exemple de hierarchie de dossier pour la bibliothèque standard. Pour
chaque dossier sont définis des règles d'accès idéales.</p>
<pre><code>lib accès en dehors du projet
|
|__ collection accès en dehors du projet
| |__ interface accès en dehors du projet
| |__ low_level accès à : lib/collection/*/*.li
| |__ very_low_level accès à : lib/collection/low_level/*/*.li
|
|__ numeric accès en dehors du projet
| |__ low_level accès à : lib/numeric/*/*.li
|
|__ tools accès aux prototypes du projet uniquement
</code></pre>
<h1>Proposition</h1>
<h2>Règles déduites de l'exemple</h2>
<p>A partir de notre exemple, on peut voir trois types de règles d'accès :</p>
<ul>
<li><p><strong>Public</strong> : accès en dehors du projet</p></li>
<li><p><strong>Projet</strong> : accès à tous les prototypes du même projet. Utilisé dans notre
exemple par `lib/tools' qui contient des prototypes utiles à tous les autres
prototypes du projet sans distinction de leur catégorie (numeric, collection,
...)</p></li>
<li><p><strong>Privé</strong> : accès uniquement au répertoire parent et ses sous répertoires. Par
exemple, lib/collection/low_level doit pouvoir être accédé par lib/collection
et lib/collection/interface.</p></li>
</ul>
<h2>Formellement</h2>
<ul>
<li><p><strong>Règle de base</strong> : Les règles des sous dossiers ne peuvent qu'être plus
restrictives que les règles des dossiers parents. Il n'est pas possible
d'accéder à un sous dossier si on ne peux pas accéder à son dossier parent.</p></li>
<li><p><strong>Public : Pas de limitation</strong>.</p>
<p>Les prototypes d'un dossier Public sont accessibles partout où les prototypes
du dossier parent sont accessibles.</p></li>
<li><p><strong>Project : Limite au projet</strong></p>
<p>Les prototypes d'un dossier Project sont accessibles partout où les prototypes
du dossier parent sont accessibles, mais limité au même projet.</p></li>
<li><p><strong>Privé : Limite au dossier parent et ses sous dossiers</strong></p>
<p>Les prototypes d'un dossier Privé sont accessibles au dossier parent et à tous
les sous-dossiers du dossier parent.</p></li>
</ul>
<h1>Mise en œuvre</h1>
<p>Ces idées de mise en œuvre ne sont que des idées et vous êtes encouragés à les
améliorer.</p>
<h2>Hierarchie des dossiers</h2>
<ul>
<li><p>Chaque dossier peux contenir un fichier <code>section.txt</code> qui définira la règle à
appliquer au dossier.</p></li>
<li><p>Si un tel fichier n'est pas présent, le dossier est défini Public (pas plus de
restriction que le dossier parent)</p></li>
<li><p>Ce fichier peux contenir sur une ligne un des trois mot-clefs:</p>
<ul>
<li><code>Public</code></li>
<li><code>Project</code></li>
<li><code>Private</code></li>
</ul></li>
</ul>
<h2>Fichier LIP</h2>
<h3>Description d'un projet</h3>
<ul>
<li><p>Chaque projet serait associé à un fichier LIP.</p></li>
<li><p>Ce fichier serait courament appelé <code>make.lip</code> et serait placé dans le dossier
de plus haut niveau contenant les prototypes du projet.</p></li>
<li><p>Il serait possible de définir des chemins comme on le fait à présent avec le
slot <code>path</code>. Par exemple:</p>
<pre><code>- front_end <-
(
path "lib/*";
(target = "unix").if {
path "lib_os/unix/*";
}
// ...
);
</code></pre></li>
<li><p>Si aucun chemin n'est spécifié, il sera automatiquement ajouté le répertoire
dans lequel se trouve le fichier <code>make.lip</code> et ses sous-répertoires.</p></li>
<li><p>Avant la compilation, le slot <code>front_end</code> est exécuté et après la compilation,
<code>back_end</code> est exécuté.</p></li>
</ul>
<h3>Utilisation d'une bibliothèque externe</h3>
<ul>
<li><p>une bibliothèque externe peux être spécifiée de deux manières :</p>
<ul>
<li><p>son nom : utile pour les bibliothèque standard installées au niveau du
système</p></li>
<li><p>le chemin de son fichier .lip : utile pour séparer un projet en différents
composants. Le chemin est relatif au fichier .lip courant.</p></li>
</ul></li>
<li><p>la première manière de référencer une bibliothèque nécessite d'avoir une liste
de chemins de recherche. Pour chaque chemin de recherche, le fichier
<code>{CHEMIN}/{NOMLIB}/make.lip</code> est cherché. Le premier .lip trouvé est utilisé.</p></li>
<li><p>Les chemins de recherche sont glaubaux pour toute l'application (à débattre).
Ils ne dépendent pas du projet qui fait la recherche.</p></li>
<li><p>Ces chemins sont définis dans les fichiers LIP. En particulier le LIP
principal.</p></li>
<li><p>Cette liste peut être augmentée en utilisant une variable d'environnement (par
exemple <code>LISAAC_LIBPATH</code>). Les chemins dans cette variable seront plus
prioritaires que les chemins du make.lip principal.</p></li>
</ul>
<h3>Syntaxe d'utilisation d'une bibliothèque externe</h3>
<ul>
<li><p>La syntaxe pour importer une bibliothèque en fonction du chemin de son fichier
.lip est la suivante :</p>
<pre><code>import_lip "./subdir/lib/make.lip";
</code></pre></li>
<li><p>La syntaxe pour importer une bibliothèque en fonction de son nom est :</p>
<pre><code>import "stdlib";
</code></pre></li>
<li><p>La syntaxe pour ajouter un chemin de recherche :</p>
<pre><code>libpath "/usr/share/lisaac";
</code></pre></li>
</ul>
<h1>Idées supplémentaires</h1>
<p>Il est possible d'imaginer que le fichier <code>section.txt</code> puisse contenir <em>en
plus</em> du mot clef, une liste de prototypes. Cela limiterait d'avantage
l'utilisation des prototypes de ce dossier aux prototypes listés.</p>