Salut,
 
Je viens de tomber sur un os en PHP, et une opération qui m'aurait semblé totalement légale dans un autre langage me retourne un parse error.
 
En fait, je vpoulais savoir s'il était possible d'extraire la première valeur d'un table retoruné par une fonction sans passer par un tableau intermédiaire...
 
Un exemple valant mieux qu'un long discours...:
 

 
Pourquoi l'exemple précédent ne fonctionne t il pas? J'ai beau essayer d'isoler le retour de ma fonction avec des parenthèses, ça ne fonctionne toujours pas... Suis je obligé de passer par un tableau temporaire?
 
Ou alors par un truc dugenre:
 

Parce-que.
 
(en gros non, tu ne peux pas utiliser directement le résultat d'une fonction, il faut le mettre dans une variable.:o)

Et encore, y'a pas longtemps on pouvait pas faire :

Maintenant on peut

PHP sa simplicité en a fait sa popularité, mais aussi un langage tout pourri
Défaut simple, ya pas vraiment de terme d'objet
pour une string tu peux pas faire :  
$mastring->methodedelobjet()
tu doit faire :  
fonctionsurlastring($lastring);
 
au fait pourquoi en PHP c'est -> et pas . ?
peut etre parce que . est déjà utilisé pour la concaténation de chaînes ?

Jamais compris pourquoi c'était pas +

En même temps ça n'a pas grande importance, ce n'est qu'une convention ça, et tous les langages ne l'utilisent pas (Smalltalk utilise un simple espace pour signifier l'envoi d'un message à un objet)

Je peux pas blairer les langage où c'est '+', parce que dès que tu fous une addition dedans c'est le bordel
 
Genre JS :

HAHA WHAT'S GOING ON
tagada 23 ? tagada 5 ? Quel est le plus logique ? Rajouter des parenthèses pour forcer l'addition, et rajouter plein de caractère qui font chier en même temps ?
Je préfère :

ou

 
Bon ok, c'est minime... Maintenant j'aime bien quand on mélange pas les choses, mieux vaut laisser les opérateurs mathématiques pour les maths

Quand le langage est fortement typé ya aucun problème nulle part
 
Python:

>>> "tagada" + 2 + 3
 
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in -toplevel-
    "tagada" + 2 + 3
TypeError: cannot concatenate 'str' and 'int' objects
>>>

Ruby

>> 'tagada' + 2 + 3
TypeError: can't convert Fixnum into String
        from (irb):1:in `+'
        from (irb):1

Haskell/GHCi

Prelude> "tagada" + 2 + 3 
 
<interactive>:1:13: 
    No instance for (Num [Char]) 
      arising from use of `+' at <interactive>:1:13 
    Probable fix: add an instance declaration for (Num [Char]) 
    In the definition of `it': it = ("tagada" + 2) + 3

Erlang

3> "tagada" + 2 + 3. 
 
=ERROR REPORT==== 13-Oct-2006::01:04:06 === 
Error in process <0.34.0> with exit value: {badarith,[{erl_eval,eval_op,3},{erl_ 
eval,expr,5},{shell,exprs,6},{shell,eval_loop,3}]} 
 
** exited: {badarith,[{erl_eval,eval_op,3}, 
                      {erl_eval,expr,5}, 
                      {shell,exprs,6}, 
                      {shell,eval_loop,3}]} **

Common Lisp / clisp

[3] (+ "tralala" 2 3)
 
*** - +: "tralala" is not a number
The following restarts are available:
USE-VALUE      :R1      You may input a value to be used instead.
ABORT          :R2      ABORT

Scheme / Petite Chez Scheme

- (+ "tralala" 2 3)
 
[Repl(15)] Error in +: "tralala" is not a number.
Type (debug) to enter the debugger.

 
Tu veux jouer avec des langages de merde, c'est ton problème hein, c'est pas comme s'il n'y avait pas d'alternatives

 
Si je résume : le choix de . dans php pour la concaténation est logique, pour éviter des confusions, à cause de la confusion de php lui même au niveau du typage...Chais chuper php  

>> 'tagada' + 2 + 3
TypeError: can't convert Fixnum into String
        from (irb):1:in `+'
        from (irb):1

Ah ouais ok En voilà quelque chose de bien

Je dirais plutôt que comme + est déjà utilisé, il ont pris .
 
Quand tu vois les discussions sur l'implémentation des namespaces dans PHP6, ils cherchaient un symbole pour séparer les trucs. Alors normalement c'est du genre system.machin.truc, sauf qu'ils pouvaient pas faire comme ça parce que . est l'opérateur de concaténation . Ils pensaient aussi utiliser ::, mais pas de bol c'est pour appeller une fonction statique sur un objet. Bref, je sais pas ce qu'ils foutent, mais on dirait qu'écrire un parser qui sait différencier un opérateur suivant le contexte est au-dessus de leur moyen

moi j'aurais plutôt dit que c'était "hérité" de perl

J'vois pas ce que tu veux d'autre qu'une TypeError dans ce genre de cas hein

C'est censé être étonnant de leur part ça

Do it the PHP way, convertit en string et tente quelque chose de manière à ce que le n00b de base ait le résultat voulu.
 
 
Nan y'a mieux, convertit la string en 0, et fait l'addition

Selon les premières meeting notes, la discussion a fini sur :

yeah, je sens venir les trucs marrants...

Small test :

Affiche '3'.... Il concatène machin et 2. Puis pour additionner il convertit la première en 0, et ajoute 3. Faut mettre logiquement des parenthèses
 
si maintenant on a ça :

Ca retourne '4'. De nouveau concaténation, puis pour l'addition, il convertit en 1 (en fait il stop au premier caractère non-numérique pour la conversion en int).
 
 
Faut juste le savoir

Small test:

>>> 'machin' + 2 + 3
 
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in -toplevel-
    'machin' + 2 + 3
TypeError: cannot concatenate 'str' and 'int' objects
>>> '1 machin' + 2 + 3
 
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in -toplevel-
    '1 machin' + 2 + 3
TypeError: cannot concatenate 'str' and 'int' objects
>>> int("machin" ) + 2 + 3
 
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in -toplevel-
    int("machin" ) + 2 + 3
ValueError: invalid literal for int(): machin
>>> int("1 machin" ) + 2 + 3
 
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in -toplevel-
    int("1 machin" ) + 2 + 3
ValueError: invalid literal for int(): 1 machin
>>> "machin" + str(2+3)
'machin5'
>>> "1 machin" + str(2+3)
'1 machin5'

C'est cohérent, tu peux pas faire de connerie, ça essaie de faire exactement ce que tu demandes et pas autre chose, pas besoin de devoir se souvenir de règles stupides

 
'tain mais vive php, quoi!

Clairement. Si y'avait moyen sous PHP d'éviter l'automatisation à outrance

ajouter la notion de types de données?

Ca commence à venir tout tout doucement. Déjà dans les fonctions, tu peux forcer le type d'un paramètre (mais seulement un objet ou un Array, pas de type de base genre int ou string). Ensuite il est question aussi pour PHP6 de permettre de forcer le type de retour... Ca vient, ça vient

Ouais enfin je viens de lire les dernières devnotes, et PHP va continuer à être une grosse blague, je vois vraiment pas l'intérêt de continuer à l'utiliser
 
Leurs références permanentes à "PHP's KISS principle" me font exploser de rire, aussi

Gratos et proposé partout. J'ai commencé le dev web avec ça, tous nos premiers hébergements en mutualisé (OVH) ne proposaient que PHP...
 
OVH commence à tester RoR, et devrait le proposer à terme. Maintenant on a un dédié, je pourrait le foutre dessus, mais ça veut dire tout recommencer, se reformer et tout. Donc pas avant quelques temps...
 
Pour l'instant sous PHP5 ça va encore, y'a moyen de faire quelque chose, à condition de bien faire gaffe. Grâce aux tests unitaires les erreurs de bases sont évitées, et j'arrive à m'en tirer sans que PHP soit trop pénalisant et limitant.