XCode 3
fouf
Membre
Bonjour a tous ...
J'ai un peu regarder sur le site d'Apple la présentation de Leopard et en particulier de XCode 3. Voici donc les quelques nouveautées (et au passage mon avis dessus) :
- le nouveau style de l'editeur avec des "boites" (qui sont je crois retractables) : ca c'est vraiment pratique quand on a un fichier de plusieurs miliers de lignes.
- une nouvelle version de IB qui va (selon Apple) faciliter la localisation et permettre d'avoir encore plus de comportements differents pour les elements d'interface.
- une fonction pour faire du pas a pas en arriere lors du debuggage. Si il fallait ne garder qu'une seule amelioration dans XCode, pour moi ca serait celle la.
- XRay : un utilitaire pour analyser le comportement d'une application (perfs, allocs mémoire, etc ...) durant son fonctionnement. Boarf, ca doit être utile dans quelques cas mais je pense pas l'utiliser tous les jours.
- Objective-C 2.0 : une amelioration de la syntaxe, des performances du runtime, et surtout un systeme de garbage collection. Bon, a part le gc, je ne pense pas que cela va modifier mes habitudes pour coder (j'espere pas). Pour le gc, je ne pense pas l'utiliser etant donne que je trouve le systeme de release/retain bien plus efficace ...
Allez, bonne vacs a tous :fouf):
J'ai un peu regarder sur le site d'Apple la présentation de Leopard et en particulier de XCode 3. Voici donc les quelques nouveautées (et au passage mon avis dessus) :
- le nouveau style de l'editeur avec des "boites" (qui sont je crois retractables) : ca c'est vraiment pratique quand on a un fichier de plusieurs miliers de lignes.
- une nouvelle version de IB qui va (selon Apple) faciliter la localisation et permettre d'avoir encore plus de comportements differents pour les elements d'interface.
- une fonction pour faire du pas a pas en arriere lors du debuggage. Si il fallait ne garder qu'une seule amelioration dans XCode, pour moi ca serait celle la.
- XRay : un utilitaire pour analyser le comportement d'une application (perfs, allocs mémoire, etc ...) durant son fonctionnement. Boarf, ca doit être utile dans quelques cas mais je pense pas l'utiliser tous les jours.
- Objective-C 2.0 : une amelioration de la syntaxe, des performances du runtime, et surtout un systeme de garbage collection. Bon, a part le gc, je ne pense pas que cela va modifier mes habitudes pour coder (j'espere pas). Pour le gc, je ne pense pas l'utiliser etant donne que je trouve le systeme de release/retain bien plus efficace ...
Allez, bonne vacs a tous :fouf):
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
moi le garbage collector je pense pas l'utiliser, ça ne fais qu'alourdire l'app pour rien, et c'est très bien comme ça...
sinon je pense que c'est similaire à java,
elf
PS: tu programme overmac?
Je commence à voir le java.
d'ailleur c'est complétement HS mais je fais du java à l'école moi...
bon, allez retour sur le sujet: Xcode 3!
-garbage collector (mouais, bof...)
-revue de la syntaxe (pas génial ça...)
-plus rapide (c'est apple qui le dit, mais si c'est vrai c'est pas si mal...)
On parle bien de syntax enhancements, donc améliorations (ajouts) pour te permettre plus de choses.
Apparemment, les changements seraient profonds...
A un tel point que le WebKit (basé sur Objc++) aurait commencé son adaptation en Objc 2.0, non en modifiant le code actuel, mais en le ré-écrivant (le mélange entre code 1.0 et 2.0 étant régulé par des directives if-def-else-endif et une pseudo macro OBJC_API_VERSION).
Wait 'n see...
.
Ah ouais alors si c'est ça et que c'est plus la même syntaxe, et qu'il faut choisir l'un ou l'autre (ou utiliser des ifdef/else/endif) en effet ça craint
Parce que ça veut dire que si on développe un framework qu'on veut distribuer, il faudra le rendre compatible dans les 2 versions d'Obj-C, sans doute... (enfin au moins pour certaines parties du code pour lequel il faudra prévoir les 2 alternatives pour permettre aux utilisateurs de notre code de compiler ça avec du ObjC ou du ObjC++ au choix) ? pfff
Ce runtime sera livré avec Leopard, alors que Tiger (ou Panther) seront toujours en runtime 1.0.
Donc, je pense qu'au moment de l'écriture d'un prog, il y aura un choix à faire :
- soit rester compatible, et donc compiler l'obj-c en 1.0 (sans pouvoir utiliser les "nouveautés" comme le garbage collector)
- soit basculer en 2.0, mais en perdant la compatibilité avec les anciens systèmes.
Bien sûr, avec quelques directives de compilation et un projet Xcode adapté, on peut créer les 2 versions du même programme (ce que les programmeurs du Webkit ont peut-être commencé à faire).
Mais tout cela ne reste que de la supputation.
.
Sinon, sans repartir sur une nouvelle discussion garbage collector bien/pas bien (j'ai mon avis là -dessus : pas bien), je me demande quand même si son utilité ne sera pas dans le cas suivant:
-on développe son appli comme s'il n'y avait pas de garbage collector
-pour la distribuer, on active le garbage collector.
Si je regarde Safari, je pense qu'il a pas mal de fuites mémoire (même si le leaks n'est pas entièrement fiable). C'est un programme compliqué, bourré d'objets et de threads. Aussi, je crois vraiment que le garbage collector n'aurait quasiment aucune influence sur les performances, mais serait efficace pour confiner l'appli dans un espace mémoire plus restreint.
Après, bien sûr, à la charge du développeur de ne pas jouer au feignant et de ne pas compter sur le Garbage Collector pour développer plus vite.
Qu'en pensez-vous ?
+
Chacha
Je me suis laissé entendre dire qu'avec l'introduction des Bindings, il était de plus en plus difficile de respecter le cycle traditionnel des retain/release... Ce qui occasionnerait alors des leaks à la pelle (c'est bien pour ça que je ne binde pas).
D'autre part, les "avancés" (sic) d'Apple en matière de programmation (Bindings, CoreData, etc...) ont pour conséquence :
1. de pourrir le bon programmeur (c'est à dire de le rendre fainéant, paresseux, moins respectueux de la bonne tenue de son code)
2. de favoriser la venue des "programmaillons" (terme de mon cru qui indique celui qui code avec ses pieds)
3. de ne reposer que sur des technologies qu'on ne maà®trise pas (les Bindings, c'est une boite noire). Or l'API d'Apple n'est pas exempte de bugs...
Je n'aime pas les Bindings (car je sens que je perds la maà®trise de mon programme), je suis dubitatif quant à CoreData (je préfere utiliser SQLite en direct : rapide, efficace, maà®trisable).
Le garbage collector... Pourquoi pas. Je fais pas mal de Java au boulot, et c'est vrai que je ne me pose pas de problème métaphysique... Ma première réaction est quand même BEURK, mais bon, si c'est ça le progrès...
.
C'est du C++ donc moi pas tout comprendre. A première vue, il s'agit d'un remplacement pour une méthode obsolète. ivar_getName(_ivar) au lieu de _ivar->ivar_name, bon okay c'est mince.
En même temps, s'ils ont appelé leur méthode getName, ça veut peut-être dire qu'il y aurait une méthode setName, ce qui pourrait signifier ... bien des choses, ou alors plus probablement rien de spécial. Mais d'intriguant quand même.
ObjC++ permettra d'utiliser du C++ dans le code alors qu'ObjC tout court permettait du C (normal c'est une surcouche du C) mais pas de C++.
Si dans le WebKit ils avaient des morceaux de code en C brut ou qu'ils veulent passer des bouts de code en C++, là je capte pourquoi ils ont à faire ça. Mais si on s'en tien à Cocoa et qu'on utilise dans les lignes de code qu'on tape que de l'ObjC (ni C pur ni C++) ça risquerait donc de pas changer grand chose, du moins à première vue (Mais bon, sans plus d'infos, ...)
La raison pour laquelle Webkit l'utilise (surtout le framework Webcore en fait) est qu'ils essaient de rendre le code le plus portable possible, donc indépendant de la plate-forme, sachant que l'objective-c est très lié à Apple et au Mac. En plus Webkit est issu de Khtml, écrit lui aussi en C++ ...
Je sais pas trop quoi penser du code que j'ai posté, mais je sais une chose: l'Objective-c++ et l'Objective 2.0 n'ont pas de rapport direct. Peut-être que l'Obj-c 2.0 apportera des améliorations dans la possibilité d'utiliser le C++, mais il n'en est pas la condition d'existence.
Ceci dit mettez-moi aux abonnés absents jusqu'au 26 ou 27 et bonnes vacances à tous.
:adios!:
Meuh non, ça lui permet de gagner du temps se consacrer à des choses vraiment essentielles, comme mettre des animations, des dégradés et des ombres partout.
Non, plus sérieusement, je pense plutôt que le bon programmeur aura appris à les utiliser, mais ne les utilisera pas d'office. Il y a des cas où c'est vraiment pratique (les pref surtout) pour ne pas devoir maintenir des tonnes de gluecode, mais bien souvent il est plus rapide (pour l'exécution du programme ou à coder) d'éviter la boite noire et faire les choses à la main. Et c'est là qu'on verra la différence entre les bons et les mauvais programmeurs.
Tu n'as pas tord, mais dans ces "programmaillons" beaucoup sont dégoûtés par le côté boite noire - voire par le côté programmation tout court (parce qu'en plus le programmaillon n'aime pas lire la doc) et abandonnent très vite.
Comme pour les autres, je demande à voir. Il y a des langages qui ont une gestion de la mémoire automatique et qui donnent de bons résultats. Dont Java apparement:Â je connais quelqu'un qui utilise Java de la même manière qu'il utilise l'objective-c (et c'est loin d'être un débutant) et il arrive au même niveau de performances que l'obj-c (pour des programmes sans UI).
- properties : se serait la possibilité de nommer les ivars (les variables d'instance d'un objet) afin d'y accèder sous la forme de monObjet.propriété.
- boucle for spécifique à l'utilisation des énumérateurs.
Le code suivant :
serait remplacé par :
- possibilité de préciser dans un protocole formel les méthodes obligatoires (à implémenter) de celles qui peuvent être facultatives.
- et bien sur, l'implantation d'un garbage collector (dont on ne sait toujours pas grand' chose).
.
Je ne comprends pas, Bru :-\\
On ne peux pas déjà y accèder par monObjet->propriété, comme en C/C++ ?
En tous les cas, ça semble faire peu de nouveauté, pour une version 2 :brule:
Peut-être y a t'il du TOP SECRET aussi là -dessous?
Comme je l'ai écrit, je n'ai fait que relater ce qui ce dit ici ou là .
Effectivement, il y a peut-être beaucoup plus de nouveautés (encore top secret pour le moment).
De toute façon, dès que la beta développeur sera distribuée, les infos seront beaucoup plus précises.
.
Ca te permet d'accéder aux accesseurs d'un champs privé comme ci tu le redefinissais (le champs privé).
un exemple :
monObjet.propriete = nouvelleValeur;
correspond à
monObjet.setPropriete(nouvelleValeur) (en java)
ou [monObjet setPropriete:nouvellePropriete] (en Obj-c)
En gros, ca sert à rien et ca fait moins "Objet" ....
ps: Personnellement, ca ne me plait guère... Et puis ca ne t'économise pas grand chose car tu es tout de même obligé de définir tes accesseurs, mais en plus tu dois définir ta propriété (en .net en tout cas...).
Les énumerateurs seront comme ceux dans Java 5, enfin plus pratique à utiliser !