API Consistency when managing bounds

[fhermeni]

Hi

To retrieve a bound on a variable 'x', we have 'x.getLB()' and 'x.getUB()'. It's short, it's simple, it's great.

To update a bound on 'x', we have to use 'x.updateLowerBound()' and 'x.updateUpperBound()'. This is soooo verbose and not aligned with the getters. I would enjoy to have 'x.setLB()' and 'x.setUB()'.

It's the same for the instantiation process. On one side, you have 'x.getValue()', on the other side, you have 'x.instantiateTo()'.

BR
Fabien.

[njussien]

mmmh je ne suis pas tout à fait d'accord pour setLB et setUB (on ne modifie pas la valeur de l'attribut au sens des accesseurs ; on met à jour la borne inférieure de la variable au sens "contrainte"). Je serais alors plutôt favorable à updateLB et updateUB que setLB et setUB

c'est la même chose pour les instantations : d'un côté tu consultes la valeur de la variable (getValue) de l'autre tu poses un acte "contrainte" : une instantation, tu ne modifies pas la valeur d'un attribut.

Il me semble utile de garder ces distinctions en tête (mais je suis peut-être trop vieux jeu). Qu'en pensent les autres ?

Naren

Le 10 nov. 2012 à 11:38, Fabien Hermenier a écrit :

Hi

To retrieve a bound on a variable 'x', we have 'x.getLB()' and 'x.getUB()'. It's short, it's simple, it's great.

To update a bound on 'x', we have to use 'x.updateLowerBound()' and 'x.updateUpperBound()'. This is soooo verbose and not aligned with the getters. I would enjoy to have 'x.setLB()' and 'x.setUB()'.

It's the same for the instantiation process. On one side, you have 'x.getValue()', on the other side, you have 'x.instantiateTo()'.

BR
Fabien.

—
Reply to this email directly or view it on GitHub.

[fhermeni]

C'est parti pour le français donc.

update* me va aussi dans le sens ou c'est consistent.

Charles m'avait aussi exprimé un point de vue similaire. Je pense que notre différence d'opinion vient du fait que tu penses modèle contrainte, avec la terminologie qui va avec et tu veux que l'API reflète cette terminologie.

De mon côté, je pense développement: choco c'est un framework comme un autre.
Je veux connaître la sémantique de ces méthodes avec des termes du domaine de la PPC dans la documentation, mais à chaque fois que je dois utiliser des noms de méthodes qui changent un peu par rapport à l'habitude, je perds mes repères par rapport aux "normes" de programmation existantes (mais je suis peut-être trop vieux jeu :D).

Fabien.

[njussien]

Je comprends bien ton point de vue :) C'est pour ça que je me trouvais vieux jeu. La vraie question, comme tu le pointes, est de savoir si on veut "cacher" la mécanique contrainte ou pas. Cela ne me choque pas forcément de la cacher dans cette optique "choco est un framework comme un autre" ... comme pour beaucoup de choses le risque est la perte de compréhension intime de ce qui se passe ... mais si je suis capable de conduire une voiture sans savoir comment ça fonctionne, on peut se dire la même chose de la ppc :)

J'attends les avis des autres.

Naren

Le 10 nov. 2012 à 12:19, Fabien Hermenier a écrit :

C'est parti pour le français donc.

update* me va aussi dans le sens ou c'est consistent.

Charles m'avait aussi exprimé un point de vue similaire. Je pense que notre différence d'opinion vient du fait que tu penses modèle contrainte, avec la terminologie qui va avec et tu veux que l'API reflète cette terminologie.

De mon côté, je pense développement: choco c'est un framework comme un autre.
Je veux connaître la sémantique de ces méthodes avec des termes du domaine de la PPC dans la documentation, mais à chaque fois que je dois utiliser des noms de méthodes qui changent un peu par rapport à l'habitude, je perds mes repères par rapport aux "normes" de programmation existantes (mais je suis peut-être trop vieux jeu :D).

Fabien.

—
Reply to this email directly or view it on GitHub.

[cprudhom]

En ce qui me concerne je suis contre "setXX" parce qu'il est possible que l'appel de méthode échoue.
Or, setXX sous-entend que l'action est directe.
Ca me dérange également que les utilisateurs ne soient pas conscients de l'aspect effet de bord.

Par contre, pourquoi pas updateLB au lieu de updateLowerBound, etc.

En ce qui concerne getValue() et instantiate(), c'est moins évident.
Par exemple, si la variable n'est pas instantiée, getValue renvoie la borne inférieure (ou une erreur si "-ea").

On pourrait imaginer un restrictDomainTo(), ou un truc du genre... (sans conviction).

[jgFages]

Je suis d'accord avec Charles
et j'aime bien le: updateLB / updateUB

Pour la différence getValue() / instantiateTo
C'est vrai qu'il est un peu gênant d'avoir des noms si différent (différents entre eux, et des autres méthodes)
On ne peut pas mettre "updateValue" je pense car, avant l'appel de la méthode, la valeur n'était a priori pas définie...
pourquoi pas un "enforceValue(42)"?

[jgFages]

ou proposer getInstantiation() (à la place ou en plus de getValue())

[njussien]

ça me paraît difficile : il n'y a pas réellement de "value" lorsque la variable concernée n'est pas instantiée : getValue renvoie alors la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)

enforceValue ou enforce n'est pas mal par contre

Naren

Le 19 nov. 2012 à 23:25, jgFages a écrit :

ou proposer getInstantiation() (à la place ou en plus de getValue())

—
Reply to this email directly or view it on GitHub.

[fhermeni]

Bonjour
De mon point de vue extérieur, getValue() / instantiateTo() ne me choque pas trop

Je trouve enforceValue() trop long (je me doute bien que c'est une valeur de par le parametre).
Pour enforce(), ca me choque un peu car c'est un mot que je ne verrais qu'à cet endroit dans l'API alors que instantiate est à plusieurs endroits il me semble (il n'y a pas un isInstantiated() dans CPSolver ?), c'est un mot de vocabulaire de base de la CP et je le retrouvais partout dans la doc de Choco.

A+
Fabien

----- Mail original -----

ça me paraît difficile : il n'y a pas réellement de "value" lorsque
la variable concernée n'est pas instantiée : getValue renvoie alors
la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)

enforceValue ou enforce n'est pas mal par contre

Naren

Le 19 nov. 2012 à 23:25, jgFages a écrit :

ou proposer getInstantiation() (à la place ou en plus de
getValue())

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub .

[njussien]

Salut,

si je peux me permettre, c'est toi qui as lancé la discussion sur getValue/instantiateTo ... :) nous, on aime bien ;) 

    Naren 

Le 20 nov. 2012 à 07:55, Fabien Hermenier a écrit :

Bonjour
De mon point de vue extérieur, getValue() / instantiateTo() ne me choque pas trop

Je trouve enforceValue() trop long (je me doute bien que c'est une valeur de par le parametre).
Pour enforce(), ca me choque un peu car c'est un mot que je ne verrais qu'à cet endroit dans l'API alors que instantiate est à plusieurs endroits il me semble (il n'y a pas un isInstantiated() dans CPSolver ?), c'est un mot de vocabulaire de base de la CP et je le retrouvais partout dans la doc de Choco.

A+
Fabien

----- Mail original -----

ça me paraît difficile : il n'y a pas réellement de "value" lorsque
la variable concernée n'est pas instantiée : getValue renvoie alors
la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)

enforceValue ou enforce n'est pas mal par contre

Naren

Le 19 nov. 2012 à 23:25, jgFages a écrit :

ou proposer getInstantiation() (à la place ou en plus de
getValue())

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub .
—
Reply to this email directly or view it on GitHub.

[fhermeni]

Tout a fait, mais je parlais également du getLB() vs. updateLowerBound()/updateLB()/et feu setLB()

Mais si setValue(), getValue() ne vous semble pas propre, je trouve que getValue()/instantiateTo() plus compréhensible et/ou court que getInstantiated()/setInstantiatedTo() ou restrictDomainTo(), ou enforceValue().

Fabien

----- Mail original -----

Salut,

si je peux me permettre, c'est toi qui as lancé la discussion sur
getValue/instantiateTo ... :) nous, on aime bien ;)

Naren

Le 20 nov. 2012 à 07:55, Fabien Hermenier a écrit :

Bonjour
De mon point de vue extérieur, getValue() / instantiateTo() ne me
choque pas trop

Je trouve enforceValue() trop long (je me doute bien que c'est une
valeur de par le parametre).
Pour enforce(), ca me choque un peu car c'est un mot que je ne
verrais qu'à cet endroit dans l'API alors que instantiate est à
plusieurs endroits il me semble (il n'y a pas un isInstantiated()
dans CPSolver ?), c'est un mot de vocabulaire de base de la CP et
je le retrouvais partout dans la doc de Choco.

A+
Fabien

----- Mail original -----

ça me paraît difficile : il n'y a pas réellement de "value"
lorsque
la variable concernée n'est pas instantiée : getValue renvoie
alors
la borne inf (il faudrait d'ailleurs peut-être revoir ça :S)

enforceValue ou enforce n'est pas mal par contre

Naren

Le 19 nov. 2012 à 23:25, jgFages a écrit :

ou proposer getInstantiation() (à la place ou en plus de
getValue())

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub .
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub .

[jgFages]

Ok sinon pour info je n'utilise jamais de getValue pour les variables graphes: je regarde si ma variables est instantiée et ensuite je prends une borne (en guise de valeur).
On pourrait faire la même chose pour les entiers ça règlerait le problème...

[cprudhom]

Je recommande POMME+SPACE ou CTRL+SPACE ;)