question de debutant mais je comprend pas pourquoi on a des int , float ?
 
alors qu il existe des objets Integer, Float
 
enfin vous voyez ma questions , pourquoi il y a des types (primitifs je crois) qui ne sont aps objets ?
 
merci

pour simplifier les choses simples
 
tu n'as pas forcement envie de faire 1.add(3)   ou 1.equals(2) , si ?  
 
( il y a surement d'autre raisons, mais c'est la premiere que je vois )

ben perso je trouve ca vraiment pas top , je trouverais ca beaucoup plus pratique que tout soit objet... et surtout beaucoup plus cohérent , donc je pense que y a peut etre des "vraies" raisons non ?    
 

On peut pas définir d'opérateurs en java ?

 
bah non
 
(en fait, il y a quelques un sur string, mais c'est dans le compilo, et c'est une des raison qui fait que string est finale.)

si tu veux tout gerer en objet, pourquoi tu ne te sers pas des wrappers ( Int, Long , ...) ?  
 

non ( enfi pas a ma connaissance )

 
Ca craint

 
c'est un choix
 
je les regrette dans certains cas, mais je suis content d'y echapper dans d'autres

Question performance aussi fait que les types primitifs ont été gardés. Alloué un objet est couteux.

 
je dis pas le contarire , mais j aurais aimé savoir de maniére "intelectule" le pourquoi de ces types primitifs

 
ha oui c'est pas con ca    
 
deja que java est pas forcement top rapide
 
merci pour te reponse

 
garder aussi le langage accessible. Parce que tout objet, c'est violent pour rentrer dedans

1. C'est pour ça que d.ieu a inventé l'operator overloading
2. C'est pour ça que Microsoft a pensé à l'autoboxing qui fonctionne (pas celui de java, quoi)

Fallacy, en C# le compilo et le runtime autoboxent de manière intelligente et totalement transparente les types primitifs, on s'en fout de l'implémentation en java il y a surtout une interface totalement inconsistente (pas d'accès uniforme) pour des raisons totalement arbitraires.

J'vois pas en quoi

Si on prend l'exemple de Ruby

# Ajout de deux entiers
puts 1 + 5
#=> 6
 
# Multiplication de deux entiers
puts 5 * 9
#=> 45
 
# Pourtant mes entiers sont des objets
puts 5.class
#=> Fixnum
 
# Avec tout un tas de méthodes
puts 5.methods.join(", " )
#=> %, inspect, <<, singleton_method_added, &, clone, >>, method, round, public_methods, instance_variable_defined?
# divmod, equal?, freeze, integer?, chr, *, +, to_i, methods, respond_to?, -, upto, between?, prec, truncate, /, dup
# instance_variables, __id__, modulo, object_id, succ, |, eql?, zero?, ~, id, to_f, singleton_methods, send, prec_i, taint
# step, to_int, frozen?, instance_variable_get, ^, __send__, instance_of?, remainder, to_a, +@, nonzero?, -@, type, **
# floor, <, protected_methods, <=>, instance_eval, ==, prec_f, quo, >, display, ===, downto, id2name, size
# instance_variable_set, kind_of?, abs, extend, >=, next, to_s, <=, coerce, hash, ceil, class, tainted?, =~
# private_methods, div, nil?, untaint, times, to_sym, [], is_a?

Il est beaucoup plus illogique de créer cette dichotomie entre les types primitifs et les types objets sans aucune raison

 
ha ben c'est exactement ce que je voulais dire    
 
mais je me disais que si ca existait ca devait avoir une raison (compatibilité, raison d anciennneté etc etc...)
 
 

Il est rigolo plop(3) appelle plop(Object) au lieu de pas trouver  

Uniquement si tu as défini un plop(Object), ce que tu n'as strictement aucune raison de faire

 
Aussi pour ne pas trop rebuter les programmeurs Fortran, C, C++ et autres à l'époque.  
 
Au passage le "tout objet" c'est grave chiant (voir Eiffel) et le "overloading" d'opérateur c'est de la sucrerie syntaxique et ça peut vite devenir un casse tête.

Mauvaise réponse, en C# quand on déclare un int (avec type "int" ) il se comporte exactement comme un Integer  

N'importe quoi... (voir Smalltalk, Ruby, Python, D, C# 3.0, Nemerle, Scala)

C'est le cas de tout ce qu'on peut trouver en programmation, le problème est de trouver une balance entre les intérêts (légèreté et clarté de la syntaxe, puissance des constructs, ...) et les problèmes potentiels (magie, incohérence du code).
 
L'operator overloading, c'est comme la métaprogrammation, les first-class functions, les continuations ou les macros hygiénique (pas les macros textuelles ça c'est de la daube ), c'est dangereux, mais c'est d'une puissance incompréhensible quand on ne les as pas essayés

 
A la sortie de Java il n'y avait pas de C# !
 
Quand je dit le "tout objet" c'est grave chiant : j'entends que ça implique forcement des notions abstraites (heritage, polymorphisme etc ...) qui ne sont pas toujours évidentes à comprendre pour les débutant en POO d'ou la nécessité d'avoir un équilibre comme tu le dis plus bas, ce qui est justement le cas de Java.

Je vois pas en quoi le fait de faire

int i = 42; 
i = i + 124;

et que i soit un objet t'oblige à connaitre tout les principe de la POO. Tant que tu ne les utilise pas, ils ne t'embètent pas

Je plussoie Masklinn, tout est objet en Ruby, ca t'empeche absolument pas d'écrire du code à la C comme il a montré plus haut. Après c'est clair qu'un langage 100% objet sans "raccourcis", ie faire 3.add(4) pour une addition, c'est un peu une connerie.

donc je suis plutot d accord avec Masklinn , mais alors pourquoi avoir mis des types primitifs à votre avis ?
 
ca me tracasse  

Quelle importance? Je disais simplement que ça n'a rien d'impossible et que la limitation de Java n'a aucun sens et aucun intérêt (on peut aussi citer Smalltalk 80 dans lequel le concept de types primitifs n'existe même pas si ça t'amuse, il précède Java de 15 ans )

J'vois pas en quoi, c'est pas parce que tu manipules un objet que tu es obligé de comprendre tout ce qu'il y a derrière, ou même que tu es obligé d'utiliser ses "capacités objet"

Suffit de regarder C#, tu manipules tes ints strictement comme un `int` Java jusqu'au moment ou tu as besoin de manipuler un Integer: en Java tu es obligé de wrapper, et tu ne peux pas indexer tes collections génériques sur <int> (tu dois les indexer sur <Integer> ), en C# ton int a directement une interface d'objet donc tu ne te poses pas de question

Simplicité d'implémentation "haute performance": avec des types primitifs et pas d'autoboxing, on simplifie grandement le boulot du compilateur puisqu'on a pas besoin dans le cas 1 (types objets uniquement) de gérer les optimisations de perfs (en remplaçant à la compilation ou au runtime les objets par des valeurs quand ça a du sens) et dans le cas 2 (autoboxing) de générer la création d'objets à partir des valeurs (qui est ce que fait C#, et Java5 en fait également un peu, mais franchement pas assez pour donner un accès uniforme entre les types primitifs et objets).

De plus le cas 1 demande impérativement l'ajout d'operator overloading, au moins pour les classes "built-in" du langage (ce qu'a déjà Java d'ailleurs, "+" est overloadé sur les String pour effectuer des conversions + concaténations).

Au final, c'est la seule raison que je vois: se simplifier la tâche parce qu'on a pas envie de s'emmerder.