std_foreach et functor template

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323584-643892249-1197599994=:7301
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

On Fri, 14 Dec 2007, Sylvain wrote:

| le fait qu'une classe propose des opérateurs - impossibles à définir soi-même
| - ou non, n'est pas imho un fait d'appartenance au langage.

Si la surcharge d'operateur ext explicitement interdite par le
langage, comment fais-tu pour la définir en tant que méthode d'une
classe dans une bibliothèque ?

-- Gaby
--8323584-643892249-1197599994=:7301--

On Dec 14, 1:19 am, Sylvain <noS...@mail.net> wrote:

Michael DOUBEZ wrote on 13/12/2007 22:04:

L'argument est faible, je le voi[s]: tant qu'il n'y aura qu'un seul
décideur de ce qu'est Java, tou[t] ce qu'il intègre dans le produit
pourrait être considéré comme faisant parti du langage.

les lieux de définition de Java (au sens le + large) ne sont peut être
pas l'image parfaite d'un comité de proposition pour le C ou C++, soit.
penser pour autant qu'il n'existerait qu'un seul décideur (moral, je ne
saurais lire physique) est une erreur.

les "APIs standards et obligeatoires" (dont l'ensemble définit un subset
du langage: ME, SE ou EE) sont normalisées par Sun mais leurs origines
sont multiples.

Les origines sont peut-être multiples, et pour des raisons
commerciales ou d'autres, Sun écoute bien d'autres parties
(surtout si l'autre partie est du poid, comme IBM), mais la
décision finale, c'est bien de Sun, et de personne d'autre.

Dans le cas de C++, la décision finale, c'est bien plus ou moins
démocratique. Dans le cas de C#, il n'y a pour ainsi dire que
Microsoft dans la boucle. Ce sond deux autres modèles. (Dans le
cas des premières versions d'Ada, on pourrait peut-être parler
d'encore un modèle différent -- la décision finale était bien
fait par un organisme unique, sur ces critères à lui, mais à
l'encontre du Java, cet organisme n'avait pas d'intérêt
commercial direct dans le langage.)

le fait qu'une classe propose des opérateurs - impossibles à
définir soi-même - ou non, n'est pas imho un fait
d'appartenance au langage.

Il y a quand même bien une différence entre java.lang.String ou
std::type_info (qui s'integrent assez étroitement dans le
langage proprement dit), et des classes comme java.util.HashMap
ou std::map, qu'on pourrait implémenter soi-même sans autres
ressources que le langage. Entre les deux, il y a des composants
qui exige bien quelque chose au délà de ce que le langage offre,
sans toutefois que le compilateur ait besoin d'en être au
courant -- tout ce qui concerne les entrées/sorties ou la GUI,
par exemple (qui doivent se baser, en Java, sur des classes et
des methodes "native", implémenté dans un autre langage, et en
C ou C++, sur un API système qui typiquement exige aussi un
petit bout d'assembleur comme passerelle).

"langage Java", pas plus que "langage C++" ne se réduit à sa
seule syntaxe, un environnement Java (ME, SE ou EE) est donc
nécessairement constitué de tous les packages (toutes les
librairies) obligeatoires pour cet environnement - comme un
environnement C++ 'conforme' sera constitué de l'ensemble de
sa librairie standard.

Disons qu'en tant qu'utilisateur, il t'importe peu ce qui est
<< langage >> du point de vue d'un auteur de compilateur, et ce
qui ne l'est pas. Ce qui t'intéresse, c'est ce qui rend ton
boulot plus ou moins facile, dans l'ensemble. À ce niveau,
l'absence des threads, d'une GUI ou d'une ramasse-miettes
standard en C++, ce sont bien des défauts de C++. Qu'on les
qualifie de problème de langage ou non, ils affectent la façon
que tu développes, et ils dépendent bien de ton choix de
langage -- si tu avais choisi Java, tu aurais d'autres
problèmes, mais pas ceux-ci.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Michael DOUBEZ wrote on 13/12/2007 22:04:

L'argument est faible, je le vois: tant qu'il n'y aura qu'un seul
décideur de ce qu'est Java, tout ce qu'il intègre dans le produit
pourrait être considéré comme faisant parti du langage.

les lieux de définition de Java (au sens le + large) ne sont peut être
pas l'image parfaite d'un comité de proposition pour le C ou C++, soit.
penser pour autant qu'il n'existerait qu'un seul décideur (moral, je ne
saurais lire physique) est une erreur.

Tu dois penser au Java Community Process. Il n'en reste pas moins que
Java reste une Trademark déposée par Sun et que en fin de compte il
décide de ce qui va et ce qui ne va pas dans la VM Java.

les "APIs standards et obligeatoires" (dont l'ensemble définit un subset
du langage: ME, SE ou EE) sont normalisées par Sun mais leurs origines
sont multiples.

Il n'en reste pas moins que les VM développées par les autres éditeurs
(IBM, Apple, Windows et Kaffe je crois) sont difficilement à jour par
rapport aux dernières version de Sun et que le dernière version de Sun
reste la référence.

le fait qu'une classe propose des opérateurs - impossibles à définir
soi-même - ou non, n'est pas imho un fait d'appartenance au langage.
"langage Java", pas plus que "langage C++" ne se réduit à sa seule
syntaxe, un environnement Java (ME, SE ou EE) est donc nécessairement
constitué de tous les packages (toutes les librairies) obligeatoires
pour cet environnement - comme un environnement C++ 'conforme' sera
constitué de l'ensemble de sa librairie standard.

Non mais qu'une classe soit proposée dans toutes les distributions du
leader technologique du langage en fait defacto un standard. Les autres
VM étant Java sans X, Y ou Z. Pas que ça porte beaucoup à conséquence en
pratique mais dans le cas de Java, la ligne de séparation
bibliothèque/langage est étroite.

Ainsi, tout ce qui est implémenté en "non java" mais fourni avec les
produits Sun peut être considéré comme integré à la VM gardant Sun dans
la position du seul garant d'avoir une VM "compile once, run everywhere".

Michael

On Fri, 14 Dec 2007, Sylvain wrote:

| le fait qu'une classe propose des opérateurs - impossibles à définir soi-même
| - ou non, n'est pas imho un fait d'appartenance au langage.

Si la surcharge d'operateur ext explicitement interdite par le
langage, comment fais-tu pour la définir en tant que méthode d'une
classe dans une bibliothèque ?

-- Gaby

D'ailleurs la classe String appartient au package java.lang, ce qui veut
tout dire en soi. Et en pratique on pense bien à String comme un type
primitif.
D'ailleurs voici ce que Sun raconte à ce propos:
(http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html)

"In addition to the eight primitive data types listed above, the Java
programming language also provides special support for character strings
via the java.lang.String class. Enclosing your character string within
double quotes will automatically create a new String object; for
example, String s = "this is a string";. String objects are immutable,
which means that once created, their values cannot be changed. The
String class is not technically a primitive data type, but considering
the special support given to it by the language, you'll probably tend to
think of it as such."

:-)

--
Alain

Gabriel Dos Reis wrote on 14/12/2007 03:39:

On Fri, 14 Dec 2007, Sylvain wrote:

| le fait qu'une classe propose des opérateurs - impossibles à définir soi-même
| - ou non, n'est pas imho un fait d'appartenance au langage.

Si la surcharge d'operateur ext explicitement interdite par le
langage, comment fais-tu pour la définir en tant que méthode d'une
classe dans une bibliothèque ?

je ne vois pas la contradiction, ce n'est pas ce que j'ai dit.

mon point est: java.lang.String fait parti du langage seulement parce
que cette classe est obligeatoire depuis la spec. 1.0 du langage.
(et parce que le compilo la traite avec bienvaillance).

Sylvain.

James Kanze wrote on 14/12/2007 09:29:

[...] la décision finale était bien
fait par un organisme unique, sur ces critères à lui, mais à
l'encontre du Java, cet organisme n'avait pas d'intérêt
commercial direct dans le langage.)

l'intérêt *commercial* de Java pour Sun est un vaste débat !!
(je n'ai toujours pas vu de "puces VM hard" vendues par Sun).

le fait qu'une classe propose des opérateurs - impossibles à
définir soi-même - ou non, n'est pas imho un fait
d'appartenance au langage.

Il y a quand même bien une différence entre java.lang.String ou
std::type_info (qui s'integrent assez étroitement dans le
langage proprement dit), et des classes comme java.util.HashMap
ou std::map, qu'on pourrait implémenter soi-même sans autres
ressources que le langage.

c'est mon point! il existe des classes standards impossible à coder sans
modifier le compilo (plus rarement la VM), il en existe d'autres tout
aussi standards qui se codent grâce à la seule syntaxe sans difficulté,
donc cette caractéristique ne définit pas la nécessaire appartenance au
(concept de) langage. nous sommes d'accord.

Entre les deux, il y a des composants
qui exige bien quelque chose au délà de ce que le langage offre,
sans toutefois que le compilateur ait besoin d'en être au
courant -- tout ce qui concerne les entrées/sorties ou la GUI,
par exemple (qui doivent se baser, en Java, sur des classes et
des methodes "native", implémenté dans un autre langage, et en
C ou C++, sur un API système qui typiquement exige aussi un
petit bout d'assembleur comme passerelle).

là je ne suis pas sur de partager l'avis "au delà e ce que le langage
offre"; le langage offre le support de methode (dite) native et la
gestion de libraries externes. toutes les classes à proxy (dont GUI)
reposent sur cette possibilité. le langage offre des packages standards
(donc appartenant à celui-ci) de ce type (dont peut être le premier
java.awt) et il permet à chacun de développer des packages exigeants les
mêmes contraintes.

Disons qu'en tant qu'utilisateur, il t'importe peu ce qui est
<< langage >> du point de vue d'un auteur de compilateur, et ce
qui ne l'est pas. Ce qui t'intéresse, c'est ce qui rend ton
boulot plus ou moins facile, dans l'ensemble. À ce niveau,
l'absence des threads, d'une GUI ou d'une ramasse-miettes
standard en C++, ce sont bien des défauts de C++. Qu'on les
qualifie de problème de langage ou non, ils affectent la façon
que tu développes, et ils dépendent bien de ton choix de
langage -- si tu avais choisi Java, tu aurais d'autres
problèmes, mais pas ceux-ci.

avant "plus ou moins facile" je dirais "plus ou moins possible".
Java imposant un ensemble de libraries, le developpeur sait ce sur quoi
il peut se baser (les variations selon les choix de l'auteur du compilo
sont sinon inexistantes beaucoup importantes qu'avec un environment C++).

la facilité à coder peut ensuite s'évaluer, soit au regard des libraries
standards, soit par l'apport de libraries choisies par le développeur
pour répondre à son besoin - là on rebouclera sur le fait qu'un
développeur utilisant systématiquement une librarie métier tierce aura
tendance à la considérer comme contribuante au langage.

Sylvain.