PureBasic

Oui ce serait pas mal, mais dans mon cas, pas besoin de ces artifices...
Pour accéder à une méthode : occurrence\methode()
Pour accéder à un attribut : *occurrence\attribut
Tout simplement...

sinon n'oubliez pas que les prototypes font des merveilles à ce sujet.

J'y ai pensé, mais je préfère garder une cohérence avec le "\" commun entre les structures et les interfaces. Pour mon Visual (pas encore fini) j'utilise autre chose ( normal avec un pré-compilateur

)
Voici ce que ça donne :

erix14 a écrit :
Dr.Dri a écrit :Dans ce cas passe par une macro, transparent pour l'utilisateur sans les inconvénients des fonctions (ca doit pouvoir se bidouiller nan ?)
Je parlais non seulement du temps à coder ses fonctions : GetX(), SetX(val), GetY(), SetY(val), etc. Mais aussi, de l'énorme baisse de performance que cela implique... Surtout pour des applications 3D.

Au Contraire, je trouve bizarre que j'ai gagner en performance en codant de manière OO. pourtant , d'après des dires , je devrais perdre en perf...
Cette méthode à l'air "legere", donc je suis près à la transformation de mon pseudo moteur3D

@Erix14
HS: Ton pseudo viens d'un missile anti char ?

car le Eryx est une arme anti-char

@++

Si on gagne du temps en POO, c'est parce que les méthodes en POO prennent moins de paramètres qu'en programmation procédurale. Mais du procédural bien fait, avec des structures, est plus rapide. J'ai déjà fait des tests très précis sur la question...

Mais, les programmes en POO sont plus faciles à concevoir et à maintenir...

Cpl.Bator a écrit :HS: Ton pseudo viens d'un missile anti char ?

Mon pseudo vient de mon prénom Eric et de mon département le Calvados (14). Mais comme cette construction de pseudonyme n'est pas originale, et que donc Eric14 n'est jamais disponible, je l'ai changé en Erix14.

Et quand pense tu mettres une version exploitable de ton code ?
Car cela m'interesse vraiment

@++

Vu qu'une normalisation de la POO en PureBasic n'intéresse pas grand monde, cela restera entre nous. Je vous contacterai en MP dans les prochains jours.

Je prépare plusieurs Class d'exemple, dont une spécialement pour le calcul et la représentation graphique de tests de rapidité.
A+

erix14 a écrit :Vu qu'une normalisation de la POO en PureBasic n'intéresse pas grand monde

ne dit pas ça !!

le problem pour moi par exemple, ce'est que je sais pas a quoi ça correspond !!

ni meme a quoi ça peut servir

mais ton boulot sur ce theme peux peut-etre interresser Fred
qui pourrai l'integrer a Purebasic, en fonctions Clair et EXPLIQUé !!!

Il y a plusieurs type de programmation
notament la procedurale et l'orienté objet.

la procédurale : PureBasic , DarkBasic , BlitzBasic , Visual Basic, qbasic,etc...
L'oo : C++,PureBasic,C#,etc...

Le principe de la POO est de pouvoir par exemple d'utiliser une classe ( c'est une grosse structure qui réunie des procédure propre à cette meme classe) sans avoir a ce retaper le code ou à l'adapté, c'est très pratique pour des gros projet, comme mon moteur3D par exemple.
j'utilise entre autre une classe de caméra libre qui déconne un peu, le jour ou je veut la changer, je change juste la classe, ca reste compatible.

si tu ne me comprend pas va faire un tour ici : http://www.commentcamarche.net/poo/poointro.php3

erix14 a écrit :Vu qu'une normalisation de la POO en PureBasic n'intéresse pas grand monde, [...]

je pense que çà intéresse bcp de monde au contraire.
ya qu'a voir les discussions qui n'en finissent pas sur le forum anglais.

moi çà m'interesse. le seul truc qui m'embete c'est que c'est du bricolage sous purebasic. mais c'est possible, la preuve et çà commence à prendre forme. les approches sont de plus en plus élégantes et c'est très encourageant tout çà.

@ Cpl.Bator
VB est objet

@Erix14
Je comprends ta position sur les getAttribut et setAttribut parce je pensais comme toi au début. Cepandant après avoir étudié l'objet plus en profondeur on peut trouver l'intéret de telles fonctions...

1) de cette facon on ne connait pas la structure interne d'un objet, on se contente d'appeller ses méthodes.

2) si jamais une classe hérite d'une autre et que le traitement d'un des attributs diffère complètement, en surchargeant la fonction "get" et/ou "set" de cet attribut, c'est complètement transparent pour l'utilisateur.

Je tient à rapeller que la programation objet est plus complexe à court terme mais beaucoup plus facilement maintenable à long terme. En particulier avec les accesseurs (get et set) dans le cas de méthodes ou de classes abstraites par exemple.

Dri

erix14 a écrit :Vu qu'une normalisation de la POO en PureBasic n'intéresse pas grand monde, cela restera entre nous

Non sa intéresse du monde et sa pourrait en intéresser plus si la gestion est simple.

@ Dobro :

C'est assez simple et c'est assez pratique. En temps normal en pure on fait sa pour lire un string dans un fichier :

Code : Tout sélectionner

OpenFile(0, "...")
ligne.s = ReadString(0)

En POO (bon sa donnera jamais sa en PureOO mais sa donne une idée) :

Code : Tout sélectionner

File MonFichier = File("...")
Ligne.s = MonFichier\ReadString()

Dans ce cas ce n'est pas très intéressant mais sur des trucs plus balaises celà simplifi la tâche. Et sa pourrait être un plus pour Pure (le procédural et/ou l'OO)

Dr. Dri a écrit :Je comprends ta position sur les getAttribut et setAttribut parce je pensais comme toi au début. Cepandant après avoir étudié l'objet plus en profondeur on peut trouver l'intéret de telles fonctions...

1) de cette facon on ne connait pas la structure interne d'un objet, on se contente d'appeller ses méthodes.

2) si jamais une classe hérite d'une autre et que le traitement d'un des attributs diffère complètement, en surchargeant la fonction "get" et/ou "set" de cet attribut, c'est complètement transparent pour l'utilisateur.

Je tient à rapeller que la programation objet est plus complexe à court terme mais beaucoup plus facilement maintenable à long terme. En particulier avec les accesseurs (get et set) dans le cas de méthodes ou de classes abstraites par exemple.

Dri

Moi j'utilise cette méthode : Le programmeur peut entrer n'importe quelle valeur dans les attributs, ce sont les méthodes qui les utilisent qui en vérifier la validité... si cela engendre des problèmes elle retourne un code d'erreur. Pour la surcharge de celles-ci, je suis d'accord avec toi, mais perdre autant de puissance pour quelque chose qui sert pratiquement pas

De plus, la parade serait de surchargé la méthode et de l'appeler tout de suite après avoir vérifié les attributs, comme les Callback de Window.
Ma solution, c'est la solution rapide.

je ne m'occupe pas de Extends.
Il y a plusieurs mois je devais rajouter plusieurs extensions à la classe FPDF, je ne me suis pas embêté, j'ai copié directement les attributs et les méthodes dans la classe, et basta...

Bon, je viens d'ajouter les extensions pour faire plaisir

Code : Tout sélectionner

XIncludeFile #PB_Compiler_Home+"Class\Personne_Class.pbi"

ClassEx(PersonneEx,Personne);{
     Profession.s
     CEx_(PersonneEx, Personne)()
     AfficheProfession.s()
EndClassEx(PersonneEx,Personne);}

Constructor(PersonneEx));{
     *This\nom = "inconnu"
     *This\prenom = "inconnu"
     *This\age = 0
     *This\Profession = "inconnu"
EndConstructor(PersonneEx);}

Methode(PersonneEx,AfficheProfession,s));{
     ProcedureReturn *This\Profession
EndMethode(PersonneEx,AfficheProfession);}


New(taPersonne,Personne)("Martin","Jean",32)
New(maPersonne,PersonneEx)()

*maPersonne\nom = "Dupond"
*maPersonne\prenom = "Pierre"
*maPersonne\age = 54

Debug maPersonne\Affiche()
Debug taPersonne\Affiche()

Debug maPersonne\AfficheProfession()

ça a l'air bien sympathique tout ça , mais je n'ai pas encore compris ce qu'il fallait faire pour tester ton exemple ? J'ai loupé des épisodes ?

PureBasic

Macro & Espaces