Re: théorie des ensembles pas naives

Le type est déterminé par le fait que tu ait fait passer la valeur par un constructeur du type

Non, le type n'est "que une fonction de validation". Cf un de mes articles précédent dans la série, et la section implémentation Rust de la spec.

Par exemple:

class even(n: int) {
 n % 2 = 0;
}
class mod4(n: int) {
 n % 4 = 0;
}

Ici, even et mod4 sont définis tout deux à partir de int et n'ont pas connaissance de l'autre.

Et pourtant :

8 is even; # because 8 is int and 8 % 2 = 0 is true
8 is mod4; # becaues 8 is int and 8 % 4 = 0 is true

Et voici l'implémentation Rust de number et int qui sont appelés lors de l'appel de is ou passage en paramètre d'une fonction :

usecrate::{Value,PrimitiveValue,Type};
pubstruct NumberType;
implTypeforNumberType{
fn has(&self,llval: &Value)-> bool {
matchllval{
Value::Primitive(PrimitiveValue::Number(_))=>true,
_=>false,
}
}
}
pubstruct IntegerType;
implTypeforIntegerType{
fn has(&self,llval: &Value)-> bool {
matchllval{
Value::Primitive(PrimitiveValue::Number(a))=>a.fract()==0.0,
_=>false,
}
}
}

Je pourrais très bien modifier ces implémentations pour dire que la string "1.5" est un nombre.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg