Hi David, Le 1 août 08 à 00:22, David Chisnall a écrit :
> The issue here is that the selector count seems to be defined with > two types, one returning an object and the other returning an > integer. The compiler thinks it's the first one, and is the second > one. It gets an integer return, but treats it as an object. The > return value is 3, which is equivalent to the SmallInt value. If you > try this with an array of four elements, then you will get a crash > instead. > > The offending -count method seems to be in GSMemoryPanelEntry - I > have absolutely no idea what this class is supposed to do. It is > incredibly bad form to define selectors with the same name but > different types to others in the system (sometimes unavoidable with > independently-developed libraries, but it certainly should not be > happening with selectors declared in OpenStep classes) I agree it isn't a really good practive, yet I don't think OpenStep or Cocoa have explicitly pushed this rule. In fact, if you look at a simple method like -type defined by around 10 classes on Mac OS X (CoreAnimation, PDFKit etc. included), the return type tends to vary quite a bit. Here are the return types of some core classes: NSEvent returns NSEventType NSCell returns NSCellType NSPrinter, NSNetService returns NSString I think there are a small yet substantial number of methods with identical selectors but different signatures in Cocoa/GNUstep. The issue specially arises with small methods though. It can probably never be completely avoided. For example, if a developer writes and distributes a framework, and later on Apple introduces several identically named methods in Cocoa classes, it's going to be difficult for him to change its API for this single reason, specially if the method names he picked are really good. Collisions for method signatures will also probably exist if a Smalltalk-80 lib is implemented on top of GNUstep for Pragmatic Smalltalk. > I'm not sure what the best solution is here. I don't want to have to > move the auto-boxing logic into runtime code, since this will come > with a huge performance penalty, but it might be unavoidable. > > Suggestions? Shouldn't the method signatures be looked up on the class of the receiver if needed? Using -methodSignatureForSelector: is costly, but sel_get_typed_uid() could be used instead and there is may be a clever way to call it only when it's necessary. The following may work… If you can get the number of the registered typed selectors for a given selector name, you could then bypass the check of the method signature if there is only one registered. When more than one typed selector exist for a given selector name, only in this case you would have to look up the method signature for handling the autoboxing… Do you think this could do the trick or am I overlooking something? After taking a look at runtime functions, it seems there are no functions that return the number of typed selectors registered for a selector name. It also sel_get_any_uid() and sel_get_any_typed_uid() cannot be used to infer this information, since they may return the same selector even if there are more than one selector registered for a selector name :-/ That's all I can think of for now. Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
