On 2 Aug 2008, at 00:18, Quentin Mathé wrote: > 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.
-methodSignatureForSelector is very expensive to call for every message sends. I hacked in a special case for -count, which makes it always assume an int return. Not ideal by any means, but it works for now. > 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? The big problem is, different boxing / unboxing code needs to be created by the compiler for every type. If I can tell at compile time what the type is, then it's no problem. If I can't, then I have to emit boxing / unboxing code for every single combination of types the method might have. This will make generated code very bloated very quickly. It's also almost certainly not really needed - you generally only get objects with one return-type / selector combination passed into any given method. Possibly some Strongtalk- style type annotations could be requested to resolve conflicts (or maybe even a simple type-feedback engine, if I have time to write one). In the Étoilé runtime, type info is used for dispatch, so there is no such thing as a type collision - calling a method where you expect one type and receive another will simply fail with a runtime exception, as it should. > 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 :-/ Not a huge problem. While finding this bug, I wrote a program that dumped a list of selector name / type pairs. For now, it seems that selector type conflicts are sufficiently rare that we can ignore the problem and work around instances that appear. I only show 28 in GNUstep + EtoileFoundation, and most of these are int vs unsigned int or void vs oneway void (which isn't even a conflict, just a failure of pure string-comparison). The only one that looks like it might be a problem is -data, which sometimes returns an NSData and sometimes returns a void*. This hopefully won't be a problem, since big data-manipulation things are better done in ObjC than Smalltalk. David _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
