>Subject: petition
>Please sign and distribute Sent: Monday, April 16, 2002 10:43 AM
>Subject: URGENT! WE NEED 1,000,000 SIGNATURES!
>Dear all:
Hi, how are you?
>Please sign this petition and pass it around to everyone you know. It
>is very important to collect at least 1,000,000 signatures.
>Don't wait; just pass it to every one you know without delay. This is
>a petition that may help lawyers in Belgium who are suing
>Ariel Sharon. They need 1,000,000 signatures, so please sign it and
>pass it on.
Someone special perhaps?
>To sung please click on the the website is given below. Thanks for all your
>help.
Tell me more about that.
--
Bon l'ennui dans tout cela c'est que le gars
risque de vous ennuyez davantage. A moins qu'il
finisse par se lasser ?
Information Sony sur le passage de sa plate-forme Open-R en GPL :
http://www.sony.co.jp/en/SonyInfo/News/Press/200205/02-017E/
Cog, un robot développé au MIT qui ne marche pas
encore mais est à la pointe de ce qu'on peut faire
en IA :
http://www-caes.mit.edu/mvp/html/cog.html
Je l'ai utilisé chez France Telecom il y a
un an puis chez Axa il y a un peu moins de temps.
La phrase "make n'a aucune espèce
d'utilité pour compiler du java" est aussi idiote
que de prétendre que "ant ne sert à rien" ou
que tel ou tel outil ne doit pas être utilisé.
Je pense que c'est à chacun de choisir et pour
choisir il faut au moins connaître le "terrain".
Il y a souvent cette tendance à vouloir toujours
se tourner vers le "plus facile", tendance que
je rencontre à tous les niveaux et qui forment
des gens qui ne savent même pas au final faire
un chercher/remplacer par un script.
Personnellement, Ant est bien lorsque l'on a
rien d'autre sous la main. Mais il n'est pas
comparable avec Make pour la simple raison
que Make comprend son propre langage indépendant
et un interfaçage transparent avec le shell courant (et pas ces fichus tags).
Pour Windows, l'idéal reste cygwin. De toute
manière faire du code portable est souvent plus
une question de programmation de shell qu'une
question de Makefile.
Concernant Ant, il est fait en Java, il est
exacte qu'une compilation globale sera
plus rapide, mais cela masque la réalité du
développement. Je ne recompile 99% du temps
qu'un sous-répertoire lorsque je viens de
modifier un truc et là Make est vraiment
l'idéal. Je me vois mal mettre sur tous les
répertoires un fichier build.xml. D'autant
plus que le démarrage Java est lui bien plus
lent !.
Make s'intègre parfaitement à Emacs, un petit
C-c c et je compile la classe modifiée, les
lignes d'erreurs me sont retournés et je
peux bosser le plus naturellement.
Pour moi, Ant est plus intéressant en étape
final d'un projet lorsqu'on souhaite tout
packager (.war ou .ear) mais il est loin
d'être incontournable. Il faut s'amuser
à développer une extension pour voir ce
qu'il y a derrière.
Tout d'abord comme tu le fais remarqué, il ne s'agit
pas de rétablir toute l'étendu du paradigme objet
en 10 lignes. Cet article s'adresse avant tout à
des gens qui ne connaissent pas l'objet, me faire
le reproche de ne pas être à la hauteur de gamma
est ridicule, aucun débutant ne commencera par
gamma, c'est comme de commençer le piano avec
les préludes de Bach, irréaliste et sans intérêt.
- Concernant la première remarque :
Enlève le terme "se réduit" s.t.p. sinon la
connotation est négative
- 2° remarque : Le comportement n'est
pas le résultat d'une exécution de la description
d'une classe ? J'aimerai bien voir un objet
qui ne serait pas "décrit" par une classe.
- 3° remarque : Hors sujet aussi
- 4° remarque : D'accord avec toi,
cela porte à confusion
- 5° remarque : Commune était à prendre
au sens de "dans tous les languages Objets"
- 6° remarque : "est une sorte de"
appartient à un niveau sémantique, il ne s'agit
pas d'une obligation. Par exemple regarde le
dernier exemple et le DP "Template", cette
relation n'existe pas
- 7° remarque : C'est vrai que cela peut porter
à confusion lorsque l'on connaît l'objet
- 8° remarque : Théoriquement tu as raison, mais
je me réfère avant tout à la pratique et à la
pratique seulement. L'objet comme les réseaux
de neurone n'ont pas grand chose à voir avec la
réalité sinon comment classes-tu
l'ornithorynque ? :)
- 9° remarque : Tu as parfaitement raison, mais
voir la remarque 3°
- 10° remarque : Le contraire ne donnes pas
une vision trés subtil du polymorphisme, mais
il est vrai que les interfaces peuvent avoir des
associations entre elles par héritage.
- 11° remarque : Pourquoi pas, mais chacun
sa manière.
- 12° remarque : Mais tu t'attends à quoi ?
J'ai pourtant bien écrit "Introduction", tu
reconnais toi même qu'il s'agit d'une
vulgarisation qui n'est pas à ton goût. Quant
tu achètes un bouquin sur l'objet/UML tu ne
prends pas les bouquins pour débutant et tu
ne dénigres par les auteurs associés puisque
ces mêmes auteurs t'ont permis de progresser ??
La remarque de Bobert va dans mon sens, mais pour
bien éclairer le sens de ma phrase, un protocole
HTTP est normalisé, l'usage en fait un standard.
Les DP ne peuvent entrer dans cette catégorie.
Quant aux factory c'est vrai que je n'ai pas trés
appronfondi mais il suffit de regarder
l'introduction aux modèles de création une ligne
au-dessus pour avoir l'explication. RTFM
Lorsque tu écris qu'une fabrique est une
interface, cela n'à pour moi aucun sens puisqu'une
interface désigne une abstraction afin
d'interchanger l'implémentation sans rompre
le cohérence de l'ensemble. L'interface couvre
donc n'importe quel code Java y compris les
fabriques si cela est utile.
Un fabrique n'a selon toi aucun sens en dehors
de l'interface mais puisque l'implémentation n'est
pas délimitée comment pourrais - tu donné un
sens à la fabrique ? La classe est ici à des
fins pratiques, je ne veux pas embrouiller tout
le monde au risque de choquer les
pusillanimes de la programmation.
Je pense que le terme Erreur Grave doit être
remis dans un contexte saint.
C'est une introduction donc je n'aborde pas
tous les sujets.
Concernant les interfaces et les classes abstraites,
elles appartiennent à la même famille décrivant
des squelettes de classes plus ou moins
complet. La distinction n'est pas clairement faite
ici car l'article tente (et je dis bien tente)
d'être généraliste, or le concept d'interface
se traduit par une classe abstraite en C++.
D'autre part, l'héritage entre interface existe
même avec une classe (hé oui, cela n'a
à priori aucun sens), donc je te laisse conclure:
// Ce code était présent dans l'outil WebObject
public interface Toto extends java.lang.Object {
}
Donc l'interface Java est traitée comme une
classe abstraite particulière. Je reconnais que
extends et remplaçé par implements à l'usage mais
c'est pour forcer l'usage de l'interface pas
pour renforçé la différence de l'interface
et de la classe abstraite.
Concernant l'héritage de classe et l'héritage
d'interface. Il faudrait peut être que tu
lises l'article en entier et notamment la ligne
suivante sur l'implémentation.
Un standard est avant tout défini par un
organisme indépendant, gamma et compagnie
ne forme en aucun cas un organisme de contrôle
et d'évolution des design patterns.
Par exemple :
Je viens de me définir une nouvelle norme pour
les fabriques.
public class ObjectBuilder {
public ObjectBuilder( ClassLoader loader )...
public Point getPoint( int x, int y )...
public void setDelegate( ObjectBuilder ob )...
}
Encore une avec une hierarchie
public class ObjectCreator {
public Object getObjectForName( String name );
public ObjectCreator getParent();
}
Encore une
public class NewObject {
public Instance getNewObject();
}
public interface Instance {
public Object getObject();
}
Bref on peut faire tout et n'importe quoi autour
des designs patterns alors pour moi il n'y a
ni norme ni standard.
Concernant ta dernière remarque toujours aussi
grave, commence déjà par lire sérieusement
l'article avant d'écrire au hasard.
# Eliza et ChatBot
Posté par Alexandre Brillant . En réponse à la dépêche Bloquer le SPAM avec Postfix. Évalué à 6.
"psychologue".
http://webreference.com/perl/tutorial/13/4.html(...)
Un petit exemple :
>Subject: petition
>Please sign and distribute Sent: Monday, April 16, 2002 10:43 AM
>Subject: URGENT! WE NEED 1,000,000 SIGNATURES!
>Dear all:
Hi, how are you?
>Please sign this petition and pass it around to everyone you know. It
>is very important to collect at least 1,000,000 signatures.
>Don't wait; just pass it to every one you know without delay. This is
>a petition that may help lawyers in Belgium who are suing
>Ariel Sharon. They need 1,000,000 signatures, so please sign it and
>pass it on.
Someone special perhaps?
>To sung please click on the the website is given below. Thanks for all your
>help.
Tell me more about that.
--
Bon l'ennui dans tout cela c'est que le gars
risque de vous ennuyez davantage. A moins qu'il
finisse par se lasser ?
# Open-R et Cog
Posté par Alexandre Brillant . En réponse à la dépêche Ca marche au GPL. Évalué à 10.
[^] # Re: Java + Make = Ant
Posté par Alexandre Brillant . En réponse à la dépêche Introduction à Make. Évalué à 9.
un an puis chez Axa il y a un peu moins de temps.
La phrase "make n'a aucune espèce
d'utilité pour compiler du java" est aussi idiote
que de prétendre que "ant ne sert à rien" ou
que tel ou tel outil ne doit pas être utilisé.
Je pense que c'est à chacun de choisir et pour
choisir il faut au moins connaître le "terrain".
Il y a souvent cette tendance à vouloir toujours
se tourner vers le "plus facile", tendance que
je rencontre à tous les niveaux et qui forment
des gens qui ne savent même pas au final faire
un chercher/remplacer par un script.
[^] # Re: Java + Make = Ant
Posté par Alexandre Brillant . En réponse à la dépêche Introduction à Make. Évalué à 3.
potentiel de Ant.
http://www.djefer.com/articles/fiches/FT_SYS_ANT_01.html(...)
Personnellement, Ant est bien lorsque l'on a
rien d'autre sous la main. Mais il n'est pas
comparable avec Make pour la simple raison
que Make comprend son propre langage indépendant
et un interfaçage transparent avec le shell courant (et pas ces fichus tags).
Pour Windows, l'idéal reste cygwin. De toute
manière faire du code portable est souvent plus
une question de programmation de shell qu'une
question de Makefile.
Concernant Ant, il est fait en Java, il est
exacte qu'une compilation globale sera
plus rapide, mais cela masque la réalité du
développement. Je ne recompile 99% du temps
qu'un sous-répertoire lorsque je viens de
modifier un truc et là Make est vraiment
l'idéal. Je me vois mal mettre sur tous les
répertoires un fichier build.xml. D'autant
plus que le démarrage Java est lui bien plus
lent !.
Make s'intègre parfaitement à Emacs, un petit
C-c c et je compile la classe modifiée, les
lignes d'erreurs me sont retournés et je
peux bosser le plus naturellement.
Pour moi, Ant est plus intéressant en étape
final d'un projet lorsqu'on souhaite tout
packager (.war ou .ear) mais il est loin
d'être incontournable. Il faut s'amuser
à développer une extension pour voir ce
qu'il y a derrière.
[^] # Re: Erreur dans le second exemple de lisp
Posté par Alexandre Brillant . En réponse à la dépêche Développement d'un mode mineur avec Emacs. Évalué à 3.
[^] # Re: conception, vous avez dit conception ?
Posté par Alexandre Brillant . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 0.
pas de rétablir toute l'étendu du paradigme objet
en 10 lignes. Cet article s'adresse avant tout à
des gens qui ne connaissent pas l'objet, me faire
le reproche de ne pas être à la hauteur de gamma
est ridicule, aucun débutant ne commencera par
gamma, c'est comme de commençer le piano avec
les préludes de Bach, irréaliste et sans intérêt.
- Concernant la première remarque :
Enlève le terme "se réduit" s.t.p. sinon la
connotation est négative
- 2° remarque : Le comportement n'est
pas le résultat d'une exécution de la description
d'une classe ? J'aimerai bien voir un objet
qui ne serait pas "décrit" par une classe.
- 3° remarque : Hors sujet aussi
- 4° remarque : D'accord avec toi,
cela porte à confusion
- 5° remarque : Commune était à prendre
au sens de "dans tous les languages Objets"
- 6° remarque : "est une sorte de"
appartient à un niveau sémantique, il ne s'agit
pas d'une obligation. Par exemple regarde le
dernier exemple et le DP "Template", cette
relation n'existe pas
- 7° remarque : C'est vrai que cela peut porter
à confusion lorsque l'on connaît l'objet
- 8° remarque : Théoriquement tu as raison, mais
je me réfère avant tout à la pratique et à la
pratique seulement. L'objet comme les réseaux
de neurone n'ont pas grand chose à voir avec la
réalité sinon comment classes-tu
l'ornithorynque ? :)
- 9° remarque : Tu as parfaitement raison, mais
voir la remarque 3°
- 10° remarque : Le contraire ne donnes pas
une vision trés subtil du polymorphisme, mais
il est vrai que les interfaces peuvent avoir des
associations entre elles par héritage.
- 11° remarque : Pourquoi pas, mais chacun
sa manière.
- 12° remarque : Mais tu t'attends à quoi ?
J'ai pourtant bien écrit "Introduction", tu
reconnais toi même qu'il s'agit d'une
vulgarisation qui n'est pas à ton goût. Quant
tu achètes un bouquin sur l'objet/UML tu ne
prends pas les bouquins pour débutant et tu
ne dénigres par les auteurs associés puisque
ces mêmes auteurs t'ont permis de progresser ??
Bonne continuation
[^] # Re: Hum... [première partie]
Posté par Alexandre Brillant . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.
bien éclairer le sens de ma phrase, un protocole
HTTP est normalisé, l'usage en fait un standard.
Les DP ne peuvent entrer dans cette catégorie.
Quant aux factory c'est vrai que je n'ai pas trés
appronfondi mais il suffit de regarder
l'introduction aux modèles de création une ligne
au-dessus pour avoir l'explication. RTFM
[^] # Re: Hum... [seconde partie]
Posté par Alexandre Brillant . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.
interface, cela n'à pour moi aucun sens puisqu'une
interface désigne une abstraction afin
d'interchanger l'implémentation sans rompre
le cohérence de l'ensemble. L'interface couvre
donc n'importe quel code Java y compris les
fabriques si cela est utile.
Un fabrique n'a selon toi aucun sens en dehors
de l'interface mais puisque l'implémentation n'est
pas délimitée comment pourrais - tu donné un
sens à la fabrique ? La classe est ici à des
fins pratiques, je ne veux pas embrouiller tout
le monde au risque de choquer les
pusillanimes de la programmation.
[^] # Re: Hum... [première partie]
Posté par Alexandre Brillant . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.
remis dans un contexte saint.
C'est une introduction donc je n'aborde pas
tous les sujets.
Concernant les interfaces et les classes abstraites,
elles appartiennent à la même famille décrivant
des squelettes de classes plus ou moins
complet. La distinction n'est pas clairement faite
ici car l'article tente (et je dis bien tente)
d'être généraliste, or le concept d'interface
se traduit par une classe abstraite en C++.
D'autre part, l'héritage entre interface existe
même avec une classe (hé oui, cela n'a
à priori aucun sens), donc je te laisse conclure:
// Ce code était présent dans l'outil WebObject
public interface Toto extends java.lang.Object {
}
Donc l'interface Java est traitée comme une
classe abstraite particulière. Je reconnais que
extends et remplaçé par implements à l'usage mais
c'est pour forcer l'usage de l'interface pas
pour renforçé la différence de l'interface
et de la classe abstraite.
Concernant l'héritage de classe et l'héritage
d'interface. Il faudrait peut être que tu
lises l'article en entier et notamment la ligne
suivante sur l'implémentation.
Un standard est avant tout défini par un
organisme indépendant, gamma et compagnie
ne forme en aucun cas un organisme de contrôle
et d'évolution des design patterns.
Par exemple :
Je viens de me définir une nouvelle norme pour
les fabriques.
public class ObjectBuilder {
public ObjectBuilder( ClassLoader loader )...
public Point getPoint( int x, int y )...
public void setDelegate( ObjectBuilder ob )...
}
Encore une avec une hierarchie
public class ObjectCreator {
public Object getObjectForName( String name );
public ObjectCreator getParent();
}
Encore une
public class NewObject {
public Instance getNewObject();
}
public interface Instance {
public Object getObject();
}
Bref on peut faire tout et n'importe quoi autour
des designs patterns alors pour moi il n'y a
ni norme ni standard.
Concernant ta dernière remarque toujours aussi
grave, commence déjà par lire sérieusement
l'article avant d'écrire au hasard.
[^] # Re: Une lecture intéressante
Posté par Alexandre Brillant . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.
vlissides sont en C++ (et un tout petit peu
de smalltalk histoire de).
Donc :
Erm. À vrai dire, les monsieurs qui ont écrits le bouquin sont des développeurs C++, et tous les exemples sont en C++.
# Complément à l'introduction
Posté par Alexandre Brillant . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 1.
http://www.djefer.com/articles/design/index.htm(...)
Bonne lecture