bon, je m'initie à Obj-C à l'aide du bouquin de A. Hillegass "Cocoa par
la pratqiue.
j'ai qq warnings au sujet d'une seule ligne :
[self setExpectedRaise:0.0];
qui est dans :
- (void)unableToSetNilForKey:(NSString *)key
{
if ([key isEqual:@"expectedRaise"]) {
[self setExpectedRaise:0.0];
} else {
[super unableToSetNilForKey:key];
}
}
le setter étant tout simple :
- (void)setExpectedRaise:(float)f
{
expectedRaise = f;
}
et les * 4 * warnings pour cette ligne sont :
MyDocument.m:58: warning: '...' as arguments.)
MyDocument.m:58: warning: will be assumed to return 'id' and accept
MyDocument.m:58: warning: (Messages without a matching method signature
MyDocument.m:58: warning: 'MyDocument' may not respond to
'-setExpectedRaise:'
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lucsky
Une bévue wrote:
et les * 4 * warnings pour cette ligne sont : MyDocument.m:58: warning: '...' as arguments.) MyDocument.m:58: warning: will be assumed to return 'id' and accept MyDocument.m:58: warning: (Messages without a matching method signature MyDocument.m:58: warning: 'MyDocument' may not respond to '-setExpectedRaise:'
Il ne s'agit que d'un seul warning, le message a simplement été saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
Est-ce que tu n'aurais pas tout simplement oublié d'inclure le header de ton MyDocument (#import "MyDocument.h" ou qqchose du genre) ?
-- Luc Heinrich -
Une bévue <une.bevueVOTEZ@NONfree.fr> wrote:
et les * 4 * warnings pour cette ligne sont :
MyDocument.m:58: warning: '...' as arguments.)
MyDocument.m:58: warning: will be assumed to return 'id' and accept
MyDocument.m:58: warning: (Messages without a matching method signature
MyDocument.m:58: warning: 'MyDocument' may not respond to
'-setExpectedRaise:'
Il ne s'agit que d'un seul warning, le message a simplement été
saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
Est-ce que tu n'aurais pas tout simplement oublié d'inclure le header de
ton MyDocument (#import "MyDocument.h" ou qqchose du genre) ?
et les * 4 * warnings pour cette ligne sont : MyDocument.m:58: warning: '...' as arguments.) MyDocument.m:58: warning: will be assumed to return 'id' and accept MyDocument.m:58: warning: (Messages without a matching method signature MyDocument.m:58: warning: 'MyDocument' may not respond to '-setExpectedRaise:'
Il ne s'agit que d'un seul warning, le message a simplement été saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
Est-ce que tu n'aurais pas tout simplement oublié d'inclure le header de ton MyDocument (#import "MyDocument.h" ou qqchose du genre) ?
-- Luc Heinrich -
une.bevueVOTEZ
Luc Heinrich wrote:
l ne s'agit que d'un seul warning, le message a simplement été saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
Est-ce que tu n'aurais pas tout simplement oublié d'inclure le header de ton MyDocument (#import "MyDocument.h" ou qqchose du genre) ?
ben non, j'ai deux classes :
MyDocument.m avec : #import "MyDocument.h" #import "Person.h"
Person.m avec : #import "Person.h"
le setter "setExpectedRaise" est défini dans "Person.m"
le "prog" marche très bien qd même...
je suis complétement novice en Obj-C (qq heures) je viens du java...
en passant, un truc que je n'ai pas pigé, quand on fait : - (void)setPersonName:(NSString *)s {...} il veut dire quoi le "*" ???
j'essaie de faire, vite fait sur le gaz, une adaptation, partielle, d'un prog écrit en pur java pour évaluer les bindings et core-data en Obj-C.
je ne suis pas sûr de rester en Obj-C mais au moins ça me servira a mieux comprendre le bridge cocoa-java.
j'ai d'ailleurs appris ce matin que certains se font leur bridge eux-mêmes et ne comptent + sur Apple... -- une bévue
Luc Heinrich <lucsky@mac.com> wrote:
l ne s'agit que d'un seul warning, le message a simplement été
saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
Est-ce que tu n'aurais pas tout simplement oublié d'inclure le header de
ton MyDocument (#import "MyDocument.h" ou qqchose du genre) ?
ben non, j'ai deux classes :
MyDocument.m avec :
#import "MyDocument.h"
#import "Person.h"
Person.m avec :
#import "Person.h"
le setter "setExpectedRaise" est défini dans "Person.m"
le "prog" marche très bien qd même...
je suis complétement novice en Obj-C (qq heures) je viens du java...
en passant, un truc que je n'ai pas pigé, quand on fait :
- (void)setPersonName:(NSString *)s {...}
il veut dire quoi le "*" ???
j'essaie de faire, vite fait sur le gaz, une adaptation, partielle, d'un
prog écrit en pur java pour évaluer les bindings et core-data en Obj-C.
je ne suis pas sûr de rester en Obj-C mais au moins ça me servira a
mieux comprendre le bridge cocoa-java.
j'ai d'ailleurs appris ce matin que certains se font leur bridge
eux-mêmes et ne comptent + sur Apple...
--
une bévue
le setter "setExpectedRaise" est défini dans "Person.m"
Hmm, il est défini dans Person.m mais le warning de gcc dit que tu l'appelles sur un MyDocument...
C'est louche ton histoire :)
en passant, un truc que je n'ai pas pigé, quand on fait : - (void)setPersonName:(NSString *)s {...} il veut dire quoi le "*" ???
Le '*' désigne un pointeur. Dans Objective-C, il y a C.
-- Luc Heinrich -
ftestuz
Une bévue wrote:
bon, je m'initie à Obj-C à l'aide du bouquin de A. Hillegass "Cocoa par la pratqiue.
Juste une remarque, c'est un bon livre qui te permettra de bien comprendre Cocoa par l'Objective-C, d'ailleurs je l'ai utilisé aussi. Mais je ne crois pas que la nouvelle édition soit disponible en français. Hors l'exemple que tu utilises semble le montrer : -unableToSetNilForKey: est noté comme deprecated depuis 10.3.
j'ai qq warnings au sujet d'une seule ligne :
[self setExpectedRaise:0.0];
qui est dans : - (void)unableToSetNilForKey:(NSString *)key { if ([key isEqual:@"expectedRaise"]) { [self setExpectedRaise:0.0]; } else { [super unableToSetNilForKey:key]; } } le setter étant tout simple : - (void)setExpectedRaise:(float)f { expectedRaise = f; }
et les * 4 * warnings pour cette ligne sont : MyDocument.m:58: warning: '...' as arguments.) MyDocument.m:58: warning: will be assumed to return 'id' and accept MyDocument.m:58: warning: (Messages without a matching method signature MyDocument.m:58: warning: 'MyDocument' may not respond to '-setExpectedRaise:'
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à l'intérieur de @implementation
- que -setExpectedRaise: est définie dans Person.m
- que -setExpectedRaise: est déclarée dans Person.h à l'intérieur de @interface
- que Person.m importe Person.h
-- Frédéric Testuz
Une bévue <une.bevueVOTEZ@NONfree.fr> wrote:
bon, je m'initie à Obj-C à l'aide du bouquin de A. Hillegass "Cocoa par
la pratqiue.
Juste une remarque, c'est un bon livre qui te permettra de bien
comprendre Cocoa par l'Objective-C, d'ailleurs je l'ai utilisé aussi.
Mais je ne crois pas que la nouvelle édition soit disponible en
français. Hors l'exemple que tu utilises semble le montrer :
-unableToSetNilForKey: est noté comme deprecated depuis 10.3.
j'ai qq warnings au sujet d'une seule ligne :
[self setExpectedRaise:0.0];
qui est dans :
- (void)unableToSetNilForKey:(NSString *)key
{
if ([key isEqual:@"expectedRaise"]) {
[self setExpectedRaise:0.0];
} else {
[super unableToSetNilForKey:key];
}
}
le setter étant tout simple :
- (void)setExpectedRaise:(float)f
{
expectedRaise = f;
}
et les * 4 * warnings pour cette ligne sont :
MyDocument.m:58: warning: '...' as arguments.)
MyDocument.m:58: warning: will be assumed to return 'id' and accept
MyDocument.m:58: warning: (Messages without a matching method signature
MyDocument.m:58: warning: 'MyDocument' may not respond to
'-setExpectedRaise:'
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à
l'intérieur de @implementation
- que -setExpectedRaise: est définie dans Person.m
- que -setExpectedRaise: est déclarée dans Person.h à l'intérieur de
@interface
bon, je m'initie à Obj-C à l'aide du bouquin de A. Hillegass "Cocoa par la pratqiue.
Juste une remarque, c'est un bon livre qui te permettra de bien comprendre Cocoa par l'Objective-C, d'ailleurs je l'ai utilisé aussi. Mais je ne crois pas que la nouvelle édition soit disponible en français. Hors l'exemple que tu utilises semble le montrer : -unableToSetNilForKey: est noté comme deprecated depuis 10.3.
j'ai qq warnings au sujet d'une seule ligne :
[self setExpectedRaise:0.0];
qui est dans : - (void)unableToSetNilForKey:(NSString *)key { if ([key isEqual:@"expectedRaise"]) { [self setExpectedRaise:0.0]; } else { [super unableToSetNilForKey:key]; } } le setter étant tout simple : - (void)setExpectedRaise:(float)f { expectedRaise = f; }
et les * 4 * warnings pour cette ligne sont : MyDocument.m:58: warning: '...' as arguments.) MyDocument.m:58: warning: will be assumed to return 'id' and accept MyDocument.m:58: warning: (Messages without a matching method signature MyDocument.m:58: warning: 'MyDocument' may not respond to '-setExpectedRaise:'
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à l'intérieur de @implementation
- que -setExpectedRaise: est définie dans Person.m
- que -setExpectedRaise: est déclarée dans Person.h à l'intérieur de @interface
- que Person.m importe Person.h
-- Frédéric Testuz
une.bevueVOTEZ
Frédéric Testuz wrote:
Mais je ne crois pas que la nouvelle édition soit disponible en français. Hors l'exemple que tu utilises semble le montrer : -unableToSetNilForKey: est noté comme deprecated depuis 10.3.
Oui, oui, j'ai une version "10.2"...
j'ai qq warnings au sujet d'une seule ligne : [...]
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à l'intérieur de @implementation
Ben en fait je me suis gourré je l'avais mis dans "MyDocument.m"
depuis tout roule...
en java une erreur pareille m'aurait généré je ne sais combien de @&#°% et la compil n'aurait pas pu aboutir...
Mais je ne crois pas que la nouvelle édition soit disponible en
français. Hors l'exemple que tu utilises semble le montrer :
-unableToSetNilForKey: est noté comme deprecated depuis 10.3.
Oui, oui, j'ai une version "10.2"...
j'ai qq warnings au sujet d'une seule ligne :
[...]
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à
l'intérieur de @implementation
Ben en fait je me suis gourré je l'avais mis dans "MyDocument.m"
depuis tout roule...
en java une erreur pareille m'aurait généré je ne sais combien de @&#°%
et la compil n'aurait pas pu aboutir...
Mais je ne crois pas que la nouvelle édition soit disponible en français. Hors l'exemple que tu utilises semble le montrer : -unableToSetNilForKey: est noté comme deprecated depuis 10.3.
Oui, oui, j'ai une version "10.2"...
j'ai qq warnings au sujet d'une seule ligne : [...]
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à l'intérieur de @implementation
Ben en fait je me suis gourré je l'avais mis dans "MyDocument.m"
depuis tout roule...
en java une erreur pareille m'aurait généré je ne sais combien de @&#°% et la compil n'aurait pas pu aboutir...
Merci en tout cas !
-- une bévue
une.bevueVOTEZ
Luc Heinrich wrote:
C'est louche ton histoire :)
oui (voir le fil du dessous), j'avais mis ce setter dans le mauvais fichier (MyDocument.m au lieu de Person.m), curieux finalement, qu'il n'y ait eu que des warnings.
la gestion des classes est très différentes du java...
en passant, un truc que je n'ai pas pigé, quand on fait : - (void)setPersonName:(NSString *)s {...} il veut dire quoi le "*" ???
Le '*' désigne un pointeur. Dans Objective-C, il y a C.
OK, merci, le bouquin que j'utilise pré-suppose la connaissance du C, ce qui n'est pas mon cas...
-- une bévue
Luc Heinrich <lucsky@mac.com> wrote:
C'est louche ton histoire :)
oui (voir le fil du dessous), j'avais mis ce setter dans le mauvais
fichier (MyDocument.m au lieu de Person.m), curieux finalement, qu'il
n'y ait eu que des warnings.
la gestion des classes est très différentes du java...
en passant, un truc que je n'ai pas pigé, quand on fait :
- (void)setPersonName:(NSString *)s {...}
il veut dire quoi le "*" ???
Le '*' désigne un pointeur. Dans Objective-C, il y a C.
OK, merci, le bouquin que j'utilise pré-suppose la connaissance du C, ce
qui n'est pas mon cas...
oui (voir le fil du dessous), j'avais mis ce setter dans le mauvais fichier (MyDocument.m au lieu de Person.m), curieux finalement, qu'il n'y ait eu que des warnings.
la gestion des classes est très différentes du java...
en passant, un truc que je n'ai pas pigé, quand on fait : - (void)setPersonName:(NSString *)s {...} il veut dire quoi le "*" ???
Le '*' désigne un pointeur. Dans Objective-C, il y a C.
OK, merci, le bouquin que j'utilise pré-suppose la connaissance du C, ce qui n'est pas mon cas...
-- une bévue
ftestuz
Une bévue wrote:
Frédéric Testuz wrote:
Mais je ne crois pas que la nouvelle édition soit disponible en français. Hors l'exemple que tu utilises semble le montrer : -unableToSetNilForKey: est noté comme deprecated depuis 10.3.
Oui, oui, j'ai une version "10.2"...
Dans ce cas, rien à dire.
j'ai qq warnings au sujet d'une seule ligne : [...]
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à l'intérieur de @implementation
Ben en fait je me suis gourré je l'avais mis dans "MyDocument.m"
depuis tout roule...
en java une erreur pareille m'aurait généré je ne sais combien de @&#°% et la compil n'aurait pas pu aboutir...
C'est parce que c'est un exemple (bon ?) des informals protocols. -unableToSetNilForKey: est en réalité défini dans une catégorie (NSKeyValueCoding) de NSObject mais pas implémentée. C'est aux classes qui souhaitent utiliser cette fonctionnalité de l'implémenter.
Mais je ne crois pas que la nouvelle édition soit disponible en
français. Hors l'exemple que tu utilises semble le montrer :
-unableToSetNilForKey: est noté comme deprecated depuis 10.3.
Oui, oui, j'ai une version "10.2"...
Dans ce cas, rien à dire.
j'ai qq warnings au sujet d'une seule ligne :
[...]
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à
l'intérieur de @implementation
Ben en fait je me suis gourré je l'avais mis dans "MyDocument.m"
depuis tout roule...
en java une erreur pareille m'aurait généré je ne sais combien de @&#°%
et la compil n'aurait pas pu aboutir...
C'est parce que c'est un exemple (bon ?) des informals protocols.
-unableToSetNilForKey: est en réalité défini dans une catégorie
(NSKeyValueCoding) de NSObject mais pas implémentée. C'est aux classes
qui souhaitent utiliser cette fonctionnalité de l'implémenter.
Mais je ne crois pas que la nouvelle édition soit disponible en français. Hors l'exemple que tu utilises semble le montrer : -unableToSetNilForKey: est noté comme deprecated depuis 10.3.
Oui, oui, j'ai une version "10.2"...
Dans ce cas, rien à dire.
j'ai qq warnings au sujet d'une seule ligne : [...]
bon, si qq'1 a une idée...
D'après les messages quelques idées :
- vérifie que -unableToSetNilForKey: est définie dans Person.m à l'intérieur de @implementation
Ben en fait je me suis gourré je l'avais mis dans "MyDocument.m"
depuis tout roule...
en java une erreur pareille m'aurait généré je ne sais combien de @&#°% et la compil n'aurait pas pu aboutir...
C'est parce que c'est un exemple (bon ?) des informals protocols. -unableToSetNilForKey: est en réalité défini dans une catégorie (NSKeyValueCoding) de NSObject mais pas implémentée. C'est aux classes qui souhaitent utiliser cette fonctionnalité de l'implémenter.
-- Frédéric Testuz
une.bevueVOTEZ
Frédéric Testuz wrote:
C'est parce que c'est un exemple (bon ?) des informals protocols. -unableToSetNilForKey: est en réalité défini dans une catégorie (NSKeyValueCoding) de NSObject mais pas implémentée. C'est aux classes qui souhaitent utiliser cette fonctionnalité de l'implémenter.
oui, je savais ça mais n'en avais pas déduit ces conséquences-là.
ça n'existe pas en java ça, ça manque d'ailleurs, car c'est vraiment ch@#nt d'avoir à tester sans arrêt if (machin != null) même pour un print-out de string... -- une bévue
C'est parce que c'est un exemple (bon ?) des informals protocols.
-unableToSetNilForKey: est en réalité défini dans une catégorie
(NSKeyValueCoding) de NSObject mais pas implémentée. C'est aux classes
qui souhaitent utiliser cette fonctionnalité de l'implémenter.
oui, je savais ça mais n'en avais pas déduit ces conséquences-là.
ça n'existe pas en java ça, ça manque d'ailleurs, car c'est vraiment
ch@#nt d'avoir à tester sans arrêt if (machin != null) même pour un
print-out de string...
--
une bévue
C'est parce que c'est un exemple (bon ?) des informals protocols. -unableToSetNilForKey: est en réalité défini dans une catégorie (NSKeyValueCoding) de NSObject mais pas implémentée. C'est aux classes qui souhaitent utiliser cette fonctionnalité de l'implémenter.
oui, je savais ça mais n'en avais pas déduit ces conséquences-là.
ça n'existe pas en java ça, ça manque d'ailleurs, car c'est vraiment ch@#nt d'avoir à tester sans arrêt if (machin != null) même pour un print-out de string... -- une bévue
Schmurtz
(Luc Heinrich) wrote:
Une bévue wrote:
et les * 4 * warnings pour cette ligne sont : MyDocument.m:58: warning: '...' as arguments.) MyDocument.m:58: warning: will be assumed to return 'id' and accept MyDocument.m:58: warning: (Messages without a matching method signature MyDocument.m:58: warning: 'MyDocument' may not respond to '-setExpectedRaise:'
Il ne s'agit que d'un seul warning, le message a simplement été saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
C'est pas GCC, c'est Xcode qui à fait le mélange. Le mieux dans ce cas est d'afficher la fenêtre d'erreur, qui elle affiche les messages dans l'ordre.
-- Schmurtz
lucsky@mac.com (Luc Heinrich) wrote:
Une bévue <une.bevueVOTEZ@NONfree.fr> wrote:
et les * 4 * warnings pour cette ligne sont :
MyDocument.m:58: warning: '...' as arguments.)
MyDocument.m:58: warning: will be assumed to return 'id' and accept
MyDocument.m:58: warning: (Messages without a matching method signature
MyDocument.m:58: warning: 'MyDocument' may not respond to
'-setExpectedRaise:'
Il ne s'agit que d'un seul warning, le message a simplement été
saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
C'est pas GCC, c'est Xcode qui à fait le mélange. Le mieux dans ce cas
est d'afficher la fenêtre d'erreur, qui elle affiche les messages dans
l'ordre.
et les * 4 * warnings pour cette ligne sont : MyDocument.m:58: warning: '...' as arguments.) MyDocument.m:58: warning: will be assumed to return 'id' and accept MyDocument.m:58: warning: (Messages without a matching method signature MyDocument.m:58: warning: 'MyDocument' may not respond to '-setExpectedRaise:'
Il ne s'agit que d'un seul warning, le message a simplement été saucissonné (et présenté à l'envers, quel merveille ce gcc hein).
C'est pas GCC, c'est Xcode qui à fait le mélange. Le mieux dans ce cas est d'afficher la fenêtre d'erreur, qui elle affiche les messages dans l'ordre.
-- Schmurtz
une.bevueVOTEZ
Schmurtz wrote:
C'est pas GCC, c'est Xcode qui à fait le mélange. Le mieux dans ce cas est d'afficher la fenêtre d'erreur, qui elle affiche les messages dans l'ordre.
Question : quand on quitte un projet et qu'on le relance, ça implique, implicitement, un "Clean all" ???
Passeke, après avoir quitté un tel projet et l'avoir relancé j'ai des warnings qui disparaissent, après avoir ajouté une ligne comme : #import <Foundation/Foundation.h>
cette ligne n'est "effective" qu'après un "Clean all", je suppose ??? -- une bévue
Schmurtz <moi@ici.com> wrote:
C'est pas GCC, c'est Xcode qui à fait le mélange. Le mieux dans ce cas
est d'afficher la fenêtre d'erreur, qui elle affiche les messages dans
l'ordre.
Question : quand on quitte un projet et qu'on le relance, ça implique,
implicitement, un "Clean all" ???
Passeke, après avoir quitté un tel projet et l'avoir relancé j'ai des
warnings qui disparaissent, après avoir ajouté une ligne comme :
#import <Foundation/Foundation.h>
cette ligne n'est "effective" qu'après un "Clean all", je suppose ???
--
une bévue
C'est pas GCC, c'est Xcode qui à fait le mélange. Le mieux dans ce cas est d'afficher la fenêtre d'erreur, qui elle affiche les messages dans l'ordre.
Question : quand on quitte un projet et qu'on le relance, ça implique, implicitement, un "Clean all" ???
Passeke, après avoir quitté un tel projet et l'avoir relancé j'ai des warnings qui disparaissent, après avoir ajouté une ligne comme : #import <Foundation/Foundation.h>
cette ligne n'est "effective" qu'après un "Clean all", je suppose ??? -- une bévue
