Compréhension CAP

[Jocelyn Batton]

Bonjour à tous,

Je me permets de rebondir directement sur le sujet lancé par Victorien concernant "attached/detached" : https://groups.google.com/forum/#!topic/groupe_eiffelistes_francophones/E0ZbDx63YKg

Voici une explication du concept CAP (Certified Attachment Patterns)

Je pars de la doc ici : http://docs.eiffel.com/book/method/void-safety-background-definition-and-tools

"It is important to understand that in this example (and with other CAPs), x is allowed to be a local variable or formal argument only. That is, x may not be an attribute or general expression (with one exception which we will see below). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later section, we well see that this is not quite such a limitations as it may appear at this point."

Le point que je ne saisis pas a priori est le fait que l'on ne rencontre pas de problème avec une variable locale alors qu'avec une attribut de classe si. Voici l'extrait de code :

 if x /= Void then
--              ... Any other instructions here that do not assign to x
                x.f (a)
            end

Il me semble qu'après le "x /= Void", on peut tout à fait mettre à Void la variable x de la même façon que pour un attribut et ceci avec un exemple "idiot" : 

 if x /= Void then
--              ... Any other instructions here that do not assign to x
                x := Void
                x.f (a)
end

J'ai du passer totalement à coté de l'explication fournie dans la doc...Merci d'avance pour vos lumières.

Jocelyn B.

[Jocelyn Fiat]

Bonjour Jocelyn B.

Je confirme que tu es passé a coté de qq chose ;)

Avec une local `x'
Le code suivant compile

   if x /= Void then

       x.do_something
   end

Mais celui-ci ne compile pas

   if x /= Void then

       x := Void

       x.do_something
   end

Car "x := Void" va changer le status de x de attached a detachable ...

Dans le cas ou `att' est un attribut
le code suivant ne compile pas
   if att /= Void then
       att.do_something
   end

Pour la simple raison qu'avec la concurrence (Thread, ...) il est tout a fait possible qu'un autre thread affecte Void à cet attribut

obj.set_att (v)

Ce qui est impossible avec une variable local .. dont la "reference" reste local a la routine.

Est-ce que cela repond a tes interrogations?

-- Jocelyn

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Groupe des Eiffelistes Francophones.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse groupe_eiffelistes_fr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[Jocelyn Batton]

Non, ça n'a pas répondu car en fait là je pars du fait que les concepts "attached/detachable" n'existe pas comme dans le paragraphe suivant (je l'ai mis en gras (trop) gros, merci google :p...):

Elements of the void-safe strategy

Here are the tools of void-safe trade. They will each be addressed in more detail throughout the documentation that follows. As you look at these elements it helps to try to think about things from the compiler's viewpoint ... after all, it is the compiler that we expect to give us the guarantee that our code is indeed void-safe.

First let's look at a couple of approaches that won't work.

It might occur to us that we could enforce compliance with the target rule by simply eliminating the concept of void references. But this would not be practical. Void is a valuable abstraction that is useful in many situations, such as providing void links in structures. So, we must keep void ... but we want to keep it under control.

Another thought might be that we could just have the compiler do all the work for us. But would be impossibly time consuming for the compiler to investigate every conceivable execution path available to a system to make certain that every possible feature call was made on an attached reference.

So, all of this boils down to the fact that we have to take some actions that help the compiler along. That's what the following are about.

Certified Attachment Patterns (CAPs)

We know that in the context of certain code patterns, it is clear that it would be impossible for a reference to be void. These patterns are identified and we call them CAPs, short for Certified Attachment Patterns. Here is a very straightforward example expressed in a syntax that should be familiar to all Eiffel developers:

            if x /= Void then
--              ... Any other instructions here that do not assign to x
                x.f (a)
            end

Here a check is made to ensure x is not void. Then as long as no assignments to x are made in the interim, a feature f can be applied to x with the certainty that x will be attached at the time ... and importantly, this can be determined at compile time. So, we say that this code pattern is a CAP for x.

It is important to understand that in this example (and with other CAPs), x is allowed to be a local variable or formal argument only. That is, x may not be an attribute or general expression (with one exception which we will see below). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later section, we well see that this is not quite such a limitations as it may appear at this point.

Ce que je ne comprends pas c'est donc (sans les notions "attached/detachable" puisque ce raisonnement doit amener à la construction du concept) quelle différence entre un attribut de classe et variable locale avec l'exemple de base "if x /= Void" ?

Merci d'avance.

Jocelyn B.

[Jocelyn Fiat]

Je ne te suis plus trop en cette presque fin de semaine.

Pour moi une variable local .. dans le contexte d'une routine , on sait exactement si la reference est changée ou non, car le scope est local.

Pour un attribut ... on n'en sait pas grand chose  (enfin on ne sait pas le prouver facilement tant est que c'est possible) du fait de la concurrency.

En ignorant l'aspect concurrency .. on pourrait le prouver si on est que l'implementation  ne va pas mettre Void sans l'attribut, mais encore une fois
1: if x /= Void then

2:       foobar

3:       x.do_something

Sur  la ligne 3 ... si x est une local on est sur que ce n'est pas Void, si x est un attribut ... juste avec ce code on n'en sait rien .. `foobar' peut tres bien changer l'attribut `x' et assigner Void

Avec l'aspect concurrency ... c'est encore plus vrai, car on ne sait vraiment pas si un autre thread ne change pas cet attribute  (avec un setter, ou meme via des appels runtime ... plus sournois)

Mais j'ai peur de ne pas saisir tout a fait ta question.

-- Jocelyn F.

[Jocelyn Batton]

En en discutant je comprends mieux.

Ce que je voulais juste dire c'est que la variable locale peut être settée à vide sans que l'on s'en rende compte de manière statique. La ligne 3 que tu mentionnes n'est pas sécurisée, vu que dans foobar on peut avoir un x := Void caché indétectable à la compilation (si x est en paramètre d'une routine). Evidemment, on peut dire que cela n'arrive pas dans des "best pratice" mais le but étant que cela soit automatisé car même avec les meilleurs intentions du monde, l'erreur est humaine...

Mais j'oublie peut-être quelque chose ?

2013/4/11 Jocelyn Fiat <jocely...@gmail.com>

[Paul G. Crismer]

Bonjour,

 Je ne comprends pas le sens de cette discussion. L’affectation avec un “Void caché”…

 Dans l’extrait de documentation sur les CAP, vous avez copié/collé  ceci notamment :

 

            if x /= Void then

--              ... Any other instructions here that do not assign to x

                x.f (a)

            end

 

Selon le commentaire, les instructions après le then ne contiennent aucune affectation de x.
Le commentaire en dit long… et répond à votre question. N’est-ce pas ?

 Cordialement,

Paul G. Crismer

[Jocelyn Batton]

Bonjour,

Effectivement en relisant les différentes réponses (et surtout le commentaire que j'ai copié...), j'ai la réponse à mes questions. J'ai même appris le readonly sur les paramètres de routine :)

Je mets ça sur le compte de la fatigue de fin de semaine...et en m'excusant platement ;)

Merci pour votre aide.

Jocelyn B.

--

[Victorien Elvinger]

Je me suis posé exactement les mêmes questions quand j’ai rencontré Eiffel Void-safe.

Pour moi le test sur les attributs ne pose pas problème si l’on utilise SCOOP ...

Cependant une procédure modifiant l’attribut par la valeur vide peut être appelée après le test d’attachement. Cette vérification générerait un coût non négligeable en terme de temps de compilation, d'où ce choix.

Je trouve le mécanisme des CAPs assez complexe, mais il a certainement été introduit pour limiter les changements des anciens programmes.

Pour de nouveaux programmes, je pense qu’il est préférable d’utiliser une sémantique plus stricte du type détachable :

- (Aucune opération n’est applicable sur une variable de type détachable)

- Une variable demeure détachable même après un test d'attachement

Ainsi seul le patron d’attachement (CAP-able expression) est applicable, les CAP ne sont plus utilisés.

Je trouve que la règle est beaucoup plus simple, systématique.

Elle évite la "transformation locale" d'une variable mutable détachable à une variable en lecture seule et attachée. Elle évite aussi de se poser les questions sur la différence entre un attribut détachable et une variable locale détachable.

Invalide :

local

x: detachable A

do

-- ...

if attached x then

x.something

end

end

Valide :

local

x: detachable A

do

-- ...

if attached x as new_x then

new_x.something

end

end

--
Victorien ELVINGER