[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [objc-improvements] Just remembered something about multiplemethod s

From: Richard Frith-Macdonald
Subject: Re: [objc-improvements] Just remembered something about multiplemethod signatures...
Date: Tue, 9 Sep 2003 09:28:46 +0100

I've been following this discussion, but haven't contributed ... partly because others are covering the points I thought of, and partly because I've been ill for the last week, and wasn't sure I was thinking clearly enough to jump in without confusing things more.

However, the discussion of the method signature issue seems to have reached an impasse, and perhaps an additional opinion (something like a vote) is useful. I'm not saying anything new, but I hope I can clarify the state of the discussion a little ...

One point to bear in mind is that there is no way to get this completely reliable. The compiler simply may not know the signature of a method provided by an object (which could be loaded from a bundle or running in another process and forwarded to). It is therefore unreasonable to insist that the compiler always generates correct code.

That being said, my preference is still to minimise the chance of the compiler ever generating incorrect code, so I make the assumption that it is the programmers responsibility to provide the compiler with signatures for every method used, and to (ideally) use casts to resolve ambiguities. Of course, a programmer uses packages produced by other people, and the headers of new versions of the packages may introduce methods which conflict with those the programmer used privately ... so we need the compiler to help as much as possible in resolving ambiguities.

Taking that assumption  (the compiler knows all the signatures) -
1. If the compiler has no signature for a method ... it should generate an error. 2. If the compiler has multiple conflicting signatures ... it should generate an error. 3. If the compiler has multiple signatures which would generate the same code, it should generate a warning.

It sounds like telling the difference between (2) and (3) may be too hard (I certainly don't know how to code that comparison) ... in which case we have to assume (2) for now, but making the distinction between the two cases would be a very good thing.

The errors and warnings should give as much information as possible about the nature of the ambiguities.

For backward compatibility, we should have a flag to turn the errors into warnings. When that flag is in use, the code generated should use the old semantics (after all, it is for backwards compatibility) ... ie use IMP where there is no signature, and arbitrarily select a signature otherwise.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]