Instance NSDate à partir d'une instance de la classe héritée NSCalendarDate
Philippe49
Membre
Quelqu'un a une idée pour ajouter des années dans une NSDate ?
pour l'instant, je fais comme suit, mais cela me semble une usine :
pour l'instant, je fais comme suit, mais cela me semble une usine :
<br />-(NSDate*) newDateByAddingYears:(NSInteger)years<br />{<br /> NSCalendarDate * cDate=[self dateWithCalendarFormat:nil timeZone:nil];<br /> NSCalendarDate * newCDate=[cDate dateByAddingYears:years months:0 days:0 hours:0 minutes:0 seconds:0];<br /> NSString * description=[newCDate description]; <br /> return [NSDate dateWithString:description];<br />}<br />
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Mais pourquoi ne pas manipuler des NSCalendarDate au lieu des NSDate ?
dans un sens: timeIntervalSinceReferenceDate. on ajoute le nombre de seconde d'une année. Puis dans l'autre sens: dateWithTimeIntervalSinceReferenceDate:
Mais peut-etre que ça ne marche pas a cause des années bissextiles!
je fais un binding avec un NSDatePicker et apparemment il n'aime pas qu'on sous-classe NSDate en NSCalendarDate ?
On peux penser à le faire "à la main", pour les années bissextiles c'est encore faisable (le nombre de multiple de 4 et de 100 entre deux entiers), mais lorsqu'on ajoute des jours, des mois, des secondes le problème se repose. Alors j'essaie d'utiliser ce qui est déjà dans la boà®te en faisant une catégorie réutilisable.
oui , moi aussi, mais je ne vois pas quelle confiance on peut faire à un cast (NSDate*) sur une instance de la sous-classe NSCalendarDate ?
Oui, mais cela reste une NSCalendarDate, à la même adresse mémoire.
En C, un cast ne change pas l'objet en mémoire et à priori le champ isa reste intacte.Â
Expérience :
Réponse : NSCalendarDate
Certes, cela peut ne pas poser de problème en général, mais imaginons que NSCalendarDate redéfinisse une des méthodes de NSDate. A priori, c'est le sélecteur correspondant au champ isa qui va être choisi, et on se retrouve avec un objet qui réagit de façon inattendue ... On croit avoir un NSDate, et on pointe en fait sur un NSCalendarDate.
ça ne me semble pas du tout irréaliste qu'une sous-classe concrète d'une classe abstraite réimplémente des méthodes.
Ceci dit, si tu tiens vraiment à réinstancier (ça me semble étonnant que ce soit nécessaire), passe plutôt par [tt]timeIntervalSinceReferenceDate[/tt] que par des strings. ça évitera de créer de créer une string et de devoir la parser.
Je ne vois pas ce que tu veux dire par là . Tous les objets sont définis par une structure identique (voir le post de psychoh13).
En l'occurence, c'est plutôt pénible d'avoir à refaire ce qui est déjà fait.
Et j'aimerais bien avoir la réponse générale au cast d'une classe fille en une classe parent. Je crée un nouveau post .
Selon l'architecture des processeurs, l'ABI permettant à une fonction de retourner des entiers n'est pas compatible avec celle pour les fonctions qui retournent des flottants, c'est le cas des Intel par exemple.
Donc, le compilateur doit savoir si la fonction retourne un entier ou un flottant voire une structure pour pouvoir choisir entre les objc_msgSend...() qu'il faut, à savoir :
Sinon pour ton problème d'ajout d'années à ta date, pourquoi n'utiliserais-tu pas la méthode : -[NSCalendarDate dateByAddingYears:months:days:hours:minutes:seconds:]
Elle te crée une nouvelle NSCalendarDate à partir du receveur avec les valeurs que tu as donné.
C'est ce que je fais.
Mais avec cela je récupère une NSCalendarDate que je voudrais retransformer en NSDate.
Le calcule est simple, puisque NSCalendarDate est par le fait de l'héritage aussi une NSDate, cet objet répond donc à -timeIntervalSinceNow, par le plus grand des hasard NSDate définit aussi la méthode +dateWithTimeIntervalSinceNow:, donc tu peux facilement te créer une NSDate à partir d'une NSCalendarDate.
Pour avoir le meilleur rendement il faudrait peut-être utiliser les méthodes timeIntervalSince1970 et dateWithTimeIntervalSince1970:, mais le principe est le même.
joli
Sur le principe, cela revient à un passage fictif par un intermédiaire comme je le faisais avec [myDate description], mais en beaucoup mieux (temps et risque de la méthode description)
Cela montre quand même les limites de la notion de boà®te noire : dans cette classe on ne voit pas les données brutes, et on est obligé de trouver un artifice.
Cela permet aussi une bien meilleure modularité, modularité très importante dans le cas des class-clusters (NSDate en est une), dans la majorité des cas les sous-classes implémentent seulement les méthodes primitives de la super-classe abstraite, et la super-classe va, elle, utiliser ces méthodes primitives pour étendre les fonctionnalités de la classe elle-même, mais rien n'empêche non plus de réimplémenter certaines méthodes non-primitives dans les sous-classes.
Et enfin ça permet aussi de conserver la compatibilité des méthodes dans l'avenir, on sait qu'une méthode donnée, quelque soit son implémentation, fait toujours la même chose, par exemple -timeIntervalSinceNow fournira toujours le nombre de secondes qu'il y a entre la date du receveur et la date du jour, et ce quelque soit son implémentation, ce qui fait qu'on est sûr d'avoir le résultat que l'on souhaite en utilisant cette méthode. Ce n'est pas le cas si tu t'amuses à utiliser la directement valeur de _timeIntervalSinceReferenceDate de ta NSCalendarDate, l'implémentation peut changer radicalement, et si tu utilises ça, tu ne garantiras pas la pérennité de ta méthode.
À mon avis, quand on écrit une catégorie il vaut mieux supposer qu'on a pas accès aux variables d'instance et qu'on est donc obligé de passer par les méthodes de l'interface principale. Bien sûr on peut toujours chercher à accéder aux variables d'instance, surtout si on est nous-même l'implémenteur de la classe entière, mais sic 'est pas le cas il vaut mieux éviter.
En réalité, je n'avais pas eu l'occasion auparavant de vraiment utiliser ces classes NSDate, ... et je n'ai pas tilté sur le fait que timeIntervalSinceReferenceDate contient en fait l'info de la date.
moralité :
1) lire la doc
2) rechercher dans les accesseurs
Overview
NSDate objects represent a single point in time. The NSDate cluster's single public superclass, NSDate, declares the programmatic interface for specific and relative time values. The objects you create using NSDate are referred to as date objects. They are immutable objects. Because of the nature of class clusters, objects returned by the NSDate class are instances not of that abstract class but of one of its private subclasses. Although a date object's class is private, its interface is public, as declared by the abstract superclass NSDate. Generally, you instantiate a suitable date object by invoking one of the date... class methods.
NSDate is an abstract class that provides behavior for creating dates, comparing dates, representing dates, computing intervals, and similar functionality. NSDate presents a programmatic interface through which suitable date objects are requested and returned. Date objects returned from NSDate are lightweight and immutable since they represent an invariant point in time. This class is designed to provide the foundation for arbitrary calendrical representations. Its subclass NSCalendarDate offers date objects that are suitable for representing dates according to western calendrical systems.
The sole primitive method of NSDate, timeIntervalSinceReferenceDate, provides the basis for all the other methods in the NSDate interface. This method returns a time value relative to an absolute reference date"the first instance of 1 January 2001, GMT.
NSDate provides several methods to interpret and to create string representations of dates (for example, dateWithNaturalLanguageString:locale: and descriptionWithLocale:). In general, on Mac OS X v10.4 and later you should use an instance of NSDateFormatter to parse and generate strings using the methods dateFromString: and stringFromDate:"see NSDateFormatter on Mac OS X v10.4 for more details.
NSDate models the change from the Julian to the Gregorian calendar in October 1582, and calendrical calculations performed in conjunction with NSCalendar take this transition into account. Note, though, limitations of the description method.
NSDate is “toll-free bridged†with its Cocoa Foundation counterpart, CFDate. This means that the Core Foundation type is interchangeable in function or method calls with the bridged Foundation object. Therefore, in a method where you see an NSDate * parameter, you can pass a CFDateRef, and in a function where you see a CFDateRef parameter, you can pass an NSDate instance (you cast one type to the other to suppress compiler warnings). See Interchangeable Data Types for more information on toll-free bridging.
Cette petite phrase est présente (sous d'autres formes) dans la documentation de tous les classes-clusters. Il y a des méthodes primitives (2 dans le cas de NSString : -length et -characterAtIndex:) et toutes les autres méthodes sont basées dessus, elles peuvent être éventuellement réimplémentée dans les sous classes, mais ce n'est pas nécessaire.
2.3.4 Abstract Classes
Abstract classes or abstract superclasses such as NSObject define methods and instance variables used by multiple subclasses. Their purpose is to reduce the development effort required to create subclasses and application structures. When we get technical, we make a distinction between a pure abstract class whose methods are defined but instance variables are not, and a semi-abstract class where instance variables are defined).
An abstract class is not expected to actually produce functional instances since crucial parts of the code are expected to be provided by subclasses. In practice, abstract classes may either stub out key methods with no-op implementations, or leave them unimplemented entirely. In the latter case, the compiler will produce a warning (but not an error).
Abstract classes reduce the development effort required to create subclasses and application structures.
2.3.5 Class Clusters
A class cluster is an abstract base class, and a group of private, concrete subclasses. It is used to hide implementation details from the programmer (who is only allowed to use the interface provided by the abstract class), so that the actual design can be modified (probably optimised) at a later date, without breaking any code that uses the cluster.
Consider a scenario where it is necessary to create a class hierarchy to define objects holding different types including chars, ints, shorts, longs, floats and doubles. Of course, different types could be defined in the same class since it is possible to cast or change them from one to the next. Their allocated storage differs, however, so it would be inefficient to bundle them in the same class and to convert them in this way.
The solution to this problem is to use a class cluster: define an abstract superclass that specifies and declares components for subclasses, but does not declare instance variables. Rather this declaration is left to its subclasses, which share the programmatic interface that is declared by the abstract superclass.
When you create an object using a cluster interface, you are given an object of another class - from a concrete class in the cluster.
Je viens de rencontrer un problème en développant une petite classe de dégradés... Le problème ici était un problème de type qui m'a forcé à utiliser le cast.
Donc le cast est utile ! Mais dans un cas précis : lorsque vous définissez une méthode qui porte le même nom qu'une autre, mais que votre méthode retourne un type incompatible avec celui de l'autre méthode, dans mon cas j'ai définit une méthode - (CGFloat)position (sous forme de propriété), et il existait déjà une méthode - (NSInsertionPosition)position.
NSInsertionPosition étant un entier, et ma méthode position n'ayant pas été définie explicitement, le compilateur a cru bon considérer que la méthode -position que j'utilisais sur cette ligne : [[_colorArray objectAtIndex:index] position]; était la méthode retournant un entier, il a donc choisit objc_msgSend() au lieu de objc_msgSend_ftret(), ce qui m'a donné des valeurs flottantes utilisées sous forme d'entier converties à nouveau en flottants. (Je sais pas si vous me suivez
En clair, lorsqu'une méthode est définie à plusieurs endroits et surtout si elles retournent des types différents, il faut utiliser le typage statique ou le cast pour aider le compilateur à choisir la bonne fonction objc_msgSend...().
Ce que je présente là , est un cas très spécifique, l'Objective-C a l'avantage de permettre les noms à rallonge, ce qui permet d'éviter ce genre de collision. Mais dans les rares cas où le typage par id est utilisé, comme dans le cas des collections, il faut là faire attention aux méthodes que l'on utilise et parfois le cast est nécessaire, ou bien il faut utiliser les variables temporaires.
Alors qu'en C++, ils en abusent...
Je prend l'exemple le plus flagrant : NSNumber
Il y a un constructeur de commodité par type ! En C++, ils auraient fait une petite template...
J'aurais pu prendre l'exemple de NSValue aussi...
Je n'ai jamais vu de polymorphisme dans Foundation ou dans AppKit. ???
Sous C++, Java, C#, tu peux écrire des choses comme ça
Alors qu'en Objective-C ou en C tu ne peux pas faire de surcharge de méthode/fonction :
Le polymorphisme ce n'est pas pareil, en tout cas ça ne recouvre pas QUE le polymorphisme de surcharge. Le polymorphisme utilisé par l'Objective-C, c'est celui qui fait que deux objets de types différents peuvent interpréter un message/un appel de méthode identique mais à leur manière.
Par exemple, la méthode -description que tous les objets implémentent (puisque NSObject la déclare) retourne toujours une NSString, mais si tu l'envoies à un NSDictionnary ou un NSArray tu n'auras pas le même résultat, et c'est ça le polymorphisme.
Autre exemple de polymorphisme, les objets NSTextField et NSSlider répondent tous deux à la méthode setIntValue:, pourtant, NSTextField va afficher la valeur, alors que NSSlider va mettre son curseur à l'endroit indiqué par l'entier.
Je parlais de polymorphisme paramétrique qu'on ne peut apparemment pas avoir en Objective-C (ou tout du moins qui pose problème) ; je pensais que c'est ce dont tu parlais dans ton message au dessus vu que tu as deux méthodes de même nom avec deux types différents.
J'ai dit "polymorphisme" parce qu'apparemment on était dans ce cadre, donc j'ai pas précisé quel type de polymorphisme :P
Surtout que dans les autres cas on parle justement de surcharge et de spécialisation.
Les différents types de polymorphismes sont pas mal expliqués ici :
http://www.commentcamarche.net/poo/polymorp.php3
Ce qui a posé problème chez moi, c'est le polymorphisme "ad hoc" mais pour être précis, ce sont deux classes différentes et dans une hiérarchie différente, qui définissent chacune une méthode de même nom retournant un type différent.
En général, lorsque le type n'est pas définit (qu'il est à id, comme dans le cas d'une méthode retournant un élément dans une collection), le compilateur donne un warning indiquant qu'il y a plusieurs méthodes de même nom retournant un type différent. Cependant, ma méthode ici n'était pas définit explicitement mais sous forme de propriété, je pense donc que c'est pour ça que je n'ai pas eu de warning, et donc le compilateur a choisit l'implémentation qui était définie explicitement.
Non non, ce qu'on appelle surcharge c'est le polymorphisme ad-hoc :P
Un bon exemple est la "surcharge des opérateurs" en C++
On surcharge les opérateurs pour n'importe quel type d'objet.
http://fr.wikipedia.org/wiki/Surcharge_des_opérateurs
La "spécialisation" étant la surcharge dans le cadre d'une classe fille.
Mais c'est vrai que le terme est ambigu... "method overloading" définissant également le polymorphisme paramétrique.
Il y a un problème de traduction, car en anglais, c'est contradictoire (l'"operator overloading" n'est pas de la "method overloading" en fait...)
Là il s'agit bien de polymorphisme ad-hoc et aussi de surcharge de fonction, et puis le terme "surcharge" est une traduction directe du terme anglais "overloading" donc ce qui correspond à l'"overloading" correspond bel et bien à la surcharge en français.
Une petite citation de la documentation Apple pour étayer ce que je dis :
Mechanism of abstraction
C'est quand même vachement différent...
La même différence que "surcharge" et "surcharge d'arguments" ; par exemple la "surcharge d'opérateurs" n'est pas du tout de la surcharge d'arguments, mais bien du polymorphisme ad-hoc.
Ton exemple avec "Number" n'est pas du polymorphisme ad-hoc, c'est justement de l'argument overloading, donc du polymorphisme paramétrique
D'ailleurs on n'utilise pas le terme "surcharge" tout seul ; ça porte beaucoup trop à confusion. Le seul contexte où j'ai entendu "surcharge" c'est justement pour "surcharge d'opérateur", et c'est un sens bien précis.