Je commence à lire quelques doc sur l'Obj-C afin de commencer
(peut-être) à découvrir Cocoa. (Jusqu'à présent, je n'ai toujours
programmé qu'avec InterfaceLib puis Carbon)
Je n'ai pas trouvé de forum fr dédié à l'Obj-C. Je poste donc ici.
Question :
Peut-on définir pour un objet des opérateurs +, *, etc. comme en C++ ?
Si oui, comment ?
SI non, la solution usuelle est-elle Obj-C++ ?
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
c'était de définir des classes qui relèvent plus de l'architecture du programme que de l'interface utilisateur proprement dite à partir d'InterfaceBuilder.
Frédéric plus loin a résumer ma pensée...
Je trouve que c'est une possibilité de générer une classe depuis IB, mais un non sens logique en tout cas pour moi...
beaucoup l'utilise cependant...
c'était de définir des classes qui relèvent plus
de l'architecture du programme que de l'interface utilisateur proprement
dite à partir d'InterfaceBuilder.
Frédéric plus loin a résumer ma pensée...
Je trouve que c'est une possibilité de générer une classe depuis IB,
mais un non sens logique en tout cas pour moi...
c'était de définir des classes qui relèvent plus de l'architecture du programme que de l'interface utilisateur proprement dite à partir d'InterfaceBuilder.
Frédéric plus loin a résumer ma pensée...
Je trouve que c'est une possibilité de générer une classe depuis IB, mais un non sens logique en tout cas pour moi...
beaucoup l'utilise cependant...
thomas-ml
Julien Salort wrote:
Ce que je trouvais surprenant (je n'ai pas dit que c'était « mal », juste « surprenant ») c'était de définir des classes qui relèvent plus de l'architecture du programme que de l'interface utilisateur proprement dite à partir d'InterfaceBuilder.
En l'occurrence l'exemple du CurrencyConverter est assez mal choisi car leur exemple répond mal au MVC... Pour faire "propre" il aurait fallu créer une classe "Converter" dont le seul job aurait été de convertir une devise en une autre, qui prendrait deux flottants et en renverrait un autre, sans aucun rapport avec l'interface graphique.
Par exemple, je considere que l'exemple Currency Converter With Bindings est plus propre.
Si tu t'en tiens au MVC c'est très logique de créer une classe dans IB : tu crées les classes du modèle dans XCode, mais les classes du contrôleur, de "liaison" entre le modèle et la vue, c'est tout aussi logique de les créer dans XCode que dans IB puisque elles relèvent autant "de l'architecture du programme" que "de l'interface utilisateur proprement dite"... D'ailleurs, tu peux créer la classe dans XCode et après l'importer dans IB !
-- Thomas Deniau
Julien Salort <lists@juliensalort.org> wrote:
Ce que je trouvais surprenant (je n'ai pas dit que c'était « mal »,
juste « surprenant ») c'était de définir des classes qui relèvent plus
de l'architecture du programme que de l'interface utilisateur proprement
dite à partir d'InterfaceBuilder.
En l'occurrence l'exemple du CurrencyConverter est assez mal choisi car
leur exemple répond mal au MVC... Pour faire "propre" il aurait fallu
créer une classe "Converter" dont le seul job aurait été de convertir
une devise en une autre, qui prendrait deux flottants et en renverrait
un autre, sans aucun rapport avec l'interface graphique.
Par exemple, je considere que l'exemple Currency Converter With Bindings
est plus propre.
Si tu t'en tiens au MVC c'est très logique de créer une classe dans IB :
tu crées les classes du modèle dans XCode, mais les classes du
contrôleur, de "liaison" entre le modèle et la vue, c'est tout aussi
logique de les créer dans XCode que dans IB puisque elles relèvent
autant "de l'architecture du programme" que "de l'interface utilisateur
proprement dite"... D'ailleurs, tu peux créer la classe dans XCode et
après l'importer dans IB !
Ce que je trouvais surprenant (je n'ai pas dit que c'était « mal », juste « surprenant ») c'était de définir des classes qui relèvent plus de l'architecture du programme que de l'interface utilisateur proprement dite à partir d'InterfaceBuilder.
En l'occurrence l'exemple du CurrencyConverter est assez mal choisi car leur exemple répond mal au MVC... Pour faire "propre" il aurait fallu créer une classe "Converter" dont le seul job aurait été de convertir une devise en une autre, qui prendrait deux flottants et en renverrait un autre, sans aucun rapport avec l'interface graphique.
Par exemple, je considere que l'exemple Currency Converter With Bindings est plus propre.
Si tu t'en tiens au MVC c'est très logique de créer une classe dans IB : tu crées les classes du modèle dans XCode, mais les classes du contrôleur, de "liaison" entre le modèle et la vue, c'est tout aussi logique de les créer dans XCode que dans IB puisque elles relèvent autant "de l'architecture du programme" que "de l'interface utilisateur proprement dite"... D'ailleurs, tu peux créer la classe dans XCode et après l'importer dans IB !
-- Thomas Deniau
Gérard Iglesias
Julien Salort wrote:
En revanche, dfinir une classe (qui semble pouvoir tre tout fait quelconque) et instantier des objets (non graphiques) directement avec IB, c'est assez nouveau pour moi.
Désolé j'arrive un peu tard dans la discussion, mais un point de précision:
En général ce que tu 'instancie' de la sorte ce n'est pas un objet de la classe elle même, mais un proxy qui représente un objet de cette classe...
Car, quand tu défini une classe de manière formelle dans ton .nib, IB n'a pas le code pour créer le 'vrai' objet.
Pour un objet d'une palette, c'est une autre histoire bien entendu, IB n'instancie pas un proxy, puisque il a le code.
Le but est de pouvoir définir les connexions entre cet objet et les autres éléments du nib. Grosse économie de code, c'est certain.
Lorsque le .nib est activé, lors du chargement, le proxy est remplacé par une instance de la classe et les connexions sont réalisées sur la 'vrai' instance.
Par ailleurs il faut noter que dans le .nib il y a un proxy d'importance, c'est le File's Owner, qui lui reprsente l'owner du .nib dans l'appel :
[NSBundle loadNibNamed:aName owner:aFilesOwner];
Et grâce auquel ton programme aura access simplement aux objets présents dans le .nib.
Salutations
Gerard
Julien Salort wrote:
En revanche, dfinir une classe (qui semble pouvoir tre tout fait
quelconque) et instantier des objets (non graphiques) directement avec
IB, c'est assez nouveau pour moi.
Désolé j'arrive un peu tard dans la discussion, mais un point de
précision:
En général ce que tu 'instancie' de la sorte ce n'est pas un objet de la
classe elle même, mais un proxy qui représente un objet de cette
classe...
Car, quand tu défini une classe de manière formelle dans ton .nib, IB
n'a pas le code pour créer le 'vrai' objet.
Pour un objet d'une palette, c'est une autre histoire bien entendu, IB
n'instancie pas un proxy, puisque il a le code.
Le but est de pouvoir définir les connexions entre cet objet et les
autres éléments du nib. Grosse économie de code, c'est certain.
Lorsque le .nib est activé, lors du chargement, le proxy est remplacé
par une instance de la classe et les connexions sont réalisées sur la
'vrai' instance.
Par ailleurs il faut noter que dans le .nib il y a un proxy
d'importance, c'est le File's Owner, qui lui reprsente l'owner du .nib
dans l'appel :
[NSBundle loadNibNamed:aName owner:aFilesOwner];
Et grâce auquel ton programme aura access simplement aux objets présents
dans le .nib.
En revanche, dfinir une classe (qui semble pouvoir tre tout fait quelconque) et instantier des objets (non graphiques) directement avec IB, c'est assez nouveau pour moi.
Désolé j'arrive un peu tard dans la discussion, mais un point de précision:
En général ce que tu 'instancie' de la sorte ce n'est pas un objet de la classe elle même, mais un proxy qui représente un objet de cette classe...
Car, quand tu défini une classe de manière formelle dans ton .nib, IB n'a pas le code pour créer le 'vrai' objet.
Pour un objet d'une palette, c'est une autre histoire bien entendu, IB n'instancie pas un proxy, puisque il a le code.
Le but est de pouvoir définir les connexions entre cet objet et les autres éléments du nib. Grosse économie de code, c'est certain.
Lorsque le .nib est activé, lors du chargement, le proxy est remplacé par une instance de la classe et les connexions sont réalisées sur la 'vrai' instance.
Par ailleurs il faut noter que dans le .nib il y a un proxy d'importance, c'est le File's Owner, qui lui reprsente l'owner du .nib dans l'appel :
[NSBundle loadNibNamed:aName owner:aFilesOwner];
Et grâce auquel ton programme aura access simplement aux objets présents dans le .nib.
