Il y avait une discussion passionnante sur Twitter ce matin concernant les runtimes modernes vedette sur 64-bits sur Mac et sur l'iPhone. Une des caractéristiques du moteur d'exécution nouvelle création automatique de variables d'instance pour vos propriétés. Ainsi, par exemple, c'est une classe tout à fait valable pour Mac programmes 64-bit:
Notez qu'il n'y a pas de déclaration variable d'instance pour testString, ce n'est pas nécessaire. Maintenant que le fragiles problème de classe de base a été éliminée dans le modernes ABI, Le runtime est capable de faire ce travail pour nous.
Cela fonctionne sur l'iPhone aussi. Malheureusement, le simulateur d'iPhone est une application 32-bits Mac, ce qui signifie les programmes exécutés dans le simulateur cannot profiter de cette fonctionnalité. En d'autres termes, la classe suivante est une classe tout à fait valable lorsqu'il est compilé pour l'appareil iPhone, mais échouera avec des erreurs lorsqu'il est compilé avec le simulateur:
Vous pourriez utiliser cette fonctionnalité sur l'iPhone, mais pas sur le simulateur en faisant ceci:
Mais, il ya un hic. L'ABI modernes ne permettent pas l'accès à @ variables d'instance privées, et les variables d'instance créé pour vous par le runtime sont @ private. Cela signifie que vous ne pouvez pas accéder au sous-jacente, variable d'instance non déclarés à partir de votre propre classe. Vous devez utiliser la méthode d'accès partout.
Alors, quel est l'avantage de ne pas déclarer la variable d'instance sous-jacente? Si vous écrivez une application 64-bits Mac, il peut vous faire économiser un peu juste de taper. Sur l'iPhone, il ne vous épargner toute tapant du tout, en fait, il ajoute deux lignes de code à moins que vous ne jamais, jamais utiliser le simulateur. Cela signifie que pour les développeurs iPhone plupart, il n'ya vraiment aucun avantage à utiliser fonction dès maintenant. Dans l'avenir, il est possible, et peut-être même probable qu'il y aura les optimisations du compilateur qui peut se produire que si vous avez que vous avez laissé le runtime créer vos variables d'instance pour vous, cependant.
Craig Hockenberry a ouvert un rapport de bogue pour demander que le simulateur d'iPhone être changé pour utiliser un moteur d'exécution modernes (sans changer la taille des types de données à 64 bits tailles, bien sûr). Si vous souhaitez être en mesure d'avoir votre variables d'instance de synthèse, vous pourriez vouloir duper son rapport. Les développeurs plus qui déclarent un bug spécifique ou demande de fonctionnalité, les plus susceptibles d'Apple est de chercher à mettre en œuvre le correctif demandé ou fonction.
Si vous vous demandez si vous devriez utiliser cette nouvelle fonctionnalité dans vos applications iPhone, il n'ya vraiment pas de réponse unique. Il n'ya absolument aucune garantie qu'il n'y aura jamais aucun avantage à utiliser ce sur l'iPhone. Sauf si vous n'utilisez pas le simulateur du tout, vous avez encore de déclarer les variables d'instance lors de la compilation pour le simulateur, afin de ne pas vous faire économiser de toute frappe. C'est un pari, donc n'hésitez pas à utiliser que vous voulez, mais il n'y a certainement aucune raison impérieuse de les utiliser encore.
Je voudrais, cependant, commencer à se déplacer loin de l'accès variable d'instance lors de l'utilisation directe des propriétés. À un certain point, il sera probablement judicieux d'utiliser cette fonction, et vous serez coincé à jour une grande quantité de code si vous accéder directement à vos variables d'instance.
Merci à @bbum, @borkware, @chockenberry et le reste des geeks de cacao qui ont participé à la discussion éducatif!
Note: Si vous voulez expérimenter avec ce sur un programme Mac, voici les options de configuration de projet Xcode, vous aurez besoin de changer de sorte que vous n'êtes pas aussi la construction d'une version 32-bit (pour lequel les variables d'instance ne peuvent pas être synthétisés ) - cliquez pour agrandir les versions (il ya deux photos):


#import <Cocoa/Cocoa.h>
@interface TestController : NSObject {
}
@property (retain) NSString *testString;
@end
Notez qu'il n'y a pas de déclaration variable d'instance pour testString, ce n'est pas nécessaire. Maintenant que le fragiles problème de classe de base a été éliminée dans le modernes ABI, Le runtime est capable de faire ce travail pour nous.
Cela fonctionne sur l'iPhone aussi. Malheureusement, le simulateur d'iPhone est une application 32-bits Mac, ce qui signifie les programmes exécutés dans le simulateur cannot profiter de cette fonctionnalité. En d'autres termes, la classe suivante est une classe tout à fait valable lorsqu'il est compilé pour l'appareil iPhone, mais échouera avec des erreurs lorsqu'il est compilé avec le simulateur:
#import <UIKit/UIKit.h>
@interface HeroEditViewController : UITableViewController {
}
@property (nonatomic, retain) NSManagedObject *myObject;
@end
Vous pourriez utiliser cette fonctionnalité sur l'iPhone, mais pas sur le simulateur en faisant ceci:
#import <UIKit/UIKit.h>
@interface HeroEditViewController : UITableViewController {
#if TARGET_IPHONE_SIMULATOR
NSManagedObject *myObject;
#endif
}
@property (nonatomic, retain) NSManagedObject *myObject;
@end
Mais, il ya un hic. L'ABI modernes ne permettent pas l'accès à @ variables d'instance privées, et les variables d'instance créé pour vous par le runtime sont @ private. Cela signifie que vous ne pouvez pas accéder au sous-jacente, variable d'instance non déclarés à partir de votre propre classe. Vous devez utiliser la méthode d'accès partout.
Alors, quel est l'avantage de ne pas déclarer la variable d'instance sous-jacente? Si vous écrivez une application 64-bits Mac, il peut vous faire économiser un peu juste de taper. Sur l'iPhone, il ne vous épargner toute tapant du tout, en fait, il ajoute deux lignes de code à moins que vous ne jamais, jamais utiliser le simulateur. Cela signifie que pour les développeurs iPhone plupart, il n'ya vraiment aucun avantage à utiliser fonction dès maintenant. Dans l'avenir, il est possible, et peut-être même probable qu'il y aura les optimisations du compilateur qui peut se produire que si vous avez que vous avez laissé le runtime créer vos variables d'instance pour vous, cependant.
Craig Hockenberry a ouvert un rapport de bogue pour demander que le simulateur d'iPhone être changé pour utiliser un moteur d'exécution modernes (sans changer la taille des types de données à 64 bits tailles, bien sûr). Si vous souhaitez être en mesure d'avoir votre variables d'instance de synthèse, vous pourriez vouloir duper son rapport. Les développeurs plus qui déclarent un bug spécifique ou demande de fonctionnalité, les plus susceptibles d'Apple est de chercher à mettre en œuvre le correctif demandé ou fonction.
Si vous vous demandez si vous devriez utiliser cette nouvelle fonctionnalité dans vos applications iPhone, il n'ya vraiment pas de réponse unique. Il n'ya absolument aucune garantie qu'il n'y aura jamais aucun avantage à utiliser ce sur l'iPhone. Sauf si vous n'utilisez pas le simulateur du tout, vous avez encore de déclarer les variables d'instance lors de la compilation pour le simulateur, afin de ne pas vous faire économiser de toute frappe. C'est un pari, donc n'hésitez pas à utiliser que vous voulez, mais il n'y a certainement aucune raison impérieuse de les utiliser encore.
Je voudrais, cependant, commencer à se déplacer loin de l'accès variable d'instance lors de l'utilisation directe des propriétés. À un certain point, il sera probablement judicieux d'utiliser cette fonction, et vous serez coincé à jour une grande quantité de code si vous accéder directement à vos variables d'instance.
Merci à @bbum, @borkware, @chockenberry et le reste des geeks de cacao qui ont participé à la discussion éducatif!
Note: Si vous voulez expérimenter avec ce sur un programme Mac, voici les options de configuration de projet Xcode, vous aurez besoin de changer de sorte que vous n'êtes pas aussi la construction d'une version 32-bit (pour lequel les variables d'instance ne peuvent pas être synthétisés ) - cliquez pour agrandir les versions (il ya deux photos):
Aucun commentaire:
Enregistrer un commentaire