Reprise du message précédent :

$class = 'A';

$b =  new $class('$parametre);

apres , pour la gestion , si tes objets n'heritent pas d'une classe commune ou n'implementent pas la meme interface, cas sert pas a grand chose

Ah tiens, j'avais fais des recherches sur les mode html, celui là à l'air pas mal

Peine de mort  

Ce qui est étrange, c'est que quand j'affiche le contenu de la table via phpmyadmin, aucun souci... tout en en UTF-8.
Je dois avoir un souci avec ma page (pourtant, bien charset: UTF-8). Ptet quand je recup les infos de la table... je vais investiguer...

Ya pas mieux
 
Mais j'ai pas réussi à utiliser mmm-mode pour pouvoir utiliser un django-*-mode et nxhtml en même temps

Heu, là tu construit un objet de type A, moi je veux un objet de type B et A... (note : ma classe B est pas vide, je la veux, j'ai des méthodes importantes dedans )

hû ?

 
Tes tables et tes champs sont bien en UTF8 aussi ?

 
Oui, tout en utf8_general_ci

pourquoi te ne ferai pas une classe B et une classe A qui herite de B ?

edit :

tu vas te trouver avec nu objet , amis sans savoir les méthodes qu'il a

exemple si ton objet est juste de classe B et que tu appelle une fonction implémenté dans A , ca te pete a la gueule

Ah ouais en effet ça suce :-/

Et le serveur est en utf8 ?    
 
XaT

Ca pue le problème de conception ton truc.

Parceque ça n'a aucun sens, mon objet B "EST" un objet A, mais pas l'inverse
 
 

Ha ça après c'est mon problème, c'est mon architecture. Là ma question c'est au niveau du langage, comment faire ça proprement genre à la C++ ?

Laisse moi juge de mon architecture, vois plutôt ça d'un point de vue langage si tu préfère

 
 
alors tu fais un objet B qui herite de A
et je te confirem qeu si tu pars a voiuloir faire du C++ en PHP , ca va très vite être ton problème

tout
bon, je fais autre chose pr l'instant, je reviendrais dessus plus tard ! ça me gave là

Avec l'extension runkit et runkit_class_adopt, même si ça fait un peu bricolé (plein de trucs marchent pas, genre is_a ou instanceof).

J'me fous de ton architecture, ça change rien au fait que ce que tu veux faire pue la mort et le problème de conception.

Il a raison.
Il faut au moins que tu définisses une interface pour ton B, sinon je vois pas ce que tu peux en faire après.
Perso je ferais une factory method qui te retourne le bon objet (d'une classe implémentant l'interface) en fonction du contexte...

T'as une directive de config à passer après la connexion à MySQL aussi, genre "SET character_set_connection=utf8, character_set_results=utf8".
Tu peux essayer dans ta page qui déconne : t'envoi cette requête (à adapter si besoin) juste après ta connexion au serveur.

flo850 a écrit :    a écrit : alors tu fais un objet B qui herite de A

 
Yep mais ça va bloquer définitivement pour objet B sur A
 
Le but s'pas de faire du C++, mon exemple c'est juste pour illustrer le but de la manoeuvre, soit instancier plusieurs objets B avec une structure différentes selon la construction. Ca existe en C++, certainement en java, certainement aussi dans plein d'autres langage, et doit bien y avoir moyen d'avoir ce comportement en PHP5 aussi sans faire ça de façon trop crade, nope ?

 
+1 avec Serge

Pas forcément, c'est une architecture que j'utilisais fréquement en C++ dans mon ancien boulot et qui n'avait rien d'un vieux hack.
Et là dans mon cas, je pense que ça correspond très bien à ma problèmatique, pas besoin de t'enflammer et dire que ça pue la mort forcément, tu sais pas ce que je veux faire, j'énonce juste la partie problèmatique de ma structure

 
le seul moyen propre que je vois, c'est d'avoir une classe ou une interface mère ( B )  
 
et d'avoir d'autres classes  qui héritent de B ou qui implémentent B , qui sont éventuellement instanciés par une factory  
 
 
au passage, je sera curieux de savoir dans quelle situation tu as besoin de ça ?

Vois mon post, à part via runkit on peut pas

Ha, super, merci je vais regarder ça

 
ça n'a pas de sens de faire ça. Ni en php ni dans aucun langage, qu'ils le permettent ou non.
Si tu as besoin de ça c'est que les classes dont tu veux une instance ont une interface commune.
Soit elles sont liées par héritage, auquel cas tu traiteras ton B comme un objet du type de la classe mère, soit elles implémentent la même interface, auquel cas tu traiteras B comme étant n'importe-quel objet implémentant cette interface.
Dans tous les cas tu délègueras la vraie création de ton instance à une méthode/un objet qui sait quelle classe intancier en fonction du contexte.

Ben va faloir expliquer la situation qui demande un truc pareil.

Sinon pour de l'héritage dynamique comme ça, y'a toujours la design pattern Decorator

En gros j'ai :
- interface "application" (Une application existe par elle même, sans être liée à un utilisateur)
- un nombre indéfinit et extension de classes implémentant mon interface
- ma class B, construite à partir d'un utilisateur et d'une application
 
Et j'aimerais manipuler un objet de type B pour chacune des applications installées par l'utilisateur, où j'ai mon lot standard d'infos (comme les parametres de l'applications, dépendant du couple user/app, donc dans B).
L'avantage d'un héritage, c'est que ça met clairement en avant le faire que l'app installée EST bien une appli, et donc si la personne programmant l'implémentation de l'app, au travers de l'objet B elle aura accès aux méthodes qu'elle a pu définir

Vais regarder ça aussi tient

 
Tout ce que tu devrais avoir besoin de manipuler pour avoir ton abstraction c'est des instances de ton interface Application, alors...

Ben ta classe B contient une Application et un Utilisateur, par simple composition. À la limite elle implémente Application pour forwarder directement les appels vers l'app qui est dedans (donc c'est un décorateur)...

Quand tu parles des "méthodes qu'elle a pu définir" tu parles de méthodes qui ne font pas partie de l'interface Application ou d'un truc complètement différent

 
Genre c'est pas la premiere chose que j'ai essaye. (avec et sans une balise de type block)
 

 
Sous IE 6, ca ne marche pas. Et bien sur qu'il faut mettre un href dans IE sinon le lien est considere comme inactif, et donc le hover ne fonctionne pas.
 

 
j'allais le dire - un truc dans ce genre doit répondre au problème!
 

<?php
 
interface App{
    
    function doSomething();
    function doSomethingElse();
    
}
 
class A implements App{
    
}
 
class AA implements App{
    
}
 
class User{
    private $toto, $tata;
}
 
class B{
    
    private $app, $user;
    
    function __construct(App $app, User $u){
        $this->app = $app;
        $this->user = $u;
    }
    
    
}
 
?>

 
m'enfin j'en ai un qui marche, moi.

<?php
 
interface App{
    
    function doSomething();
    function doSomethingElse();
    
}
 
class A implements App{
    
}
 
class AA implements App{
    
}
 
class User{
    private $toto, $tata;
}
 
 
?>

class B implements App {    
    private $app, $user;
    
    function __construct(App $app, User $u){
        $this->app = $app;
        $this->user = $u;
    }    
    function doSomething() { return $this->app->doSomething(); }
    function doSomethingElse() { return $this->app->doSomethingElse(); }
}

C'est plus sympa comme ça

Masklinn a écrit : Quand tu parles des "méthodes qu'elle a pu définir" tu parles de méthodes qui ne font pas partie de l'interface Application ou d'un truc complètement différent

Yep, ce qui ne fait pas partie de l'interface.
Ma problèmatique est pas mal liée au fait que le développeur d'un appli peut vouloir des méthodes perso en dehors du cadre imposé.
Le cadre imposé permet juste de garantir un comportement standard pour pouvoir le manipuler dans le cadre de l'architecture globale.
Après, pour le rendu graphique via template, le dev récupère un instance de B (classe qu'il ne controle pas, il ne controle que A), et il est obligé de passer par B pour récupérer les parametre de l'utilisateur.
Alors plutot que de lui fournir B (pour les données) et A (pour ses méthodes perso), faire hériter B de A me semble tout à fait approprié.
Mais comme B sert aussi pour A', A'', ... je suis eu pour un héritage hardcodé.
Ca me semble pas completement délirant quand même

Même page avec charset en utf8, sur mon serveur : ça rulz, tu le met sur du mutu d'ovh, rulz plus du tout.
Donc je sais pas, variables d'environement du serveur en lui même, ou alors du serveur web.

Je vote pour ça.

XaT

C'est ce que je fais actuellement mais la possibilité de faire autrement m'intéresse, et j'aime bien avoir plusieurs cordes à mon arc avant de choisir