Hi Martin, Skip, it makes sense, sort of. ClassReorganized could be handled already by just either discarding whatever cache you would have on the protocols of the class (for example, in a browser) or comparing the new class organisation with the old one. You may be pointing to, however, another issue: ClassReorganized not carrying enough information (i.e. not the old set of protocols). I'm not sure your ProtocolRenamed solves that. But it won't do much harm... Unless Nautilus overeacts and refresh itself 20 times, that it :) Thierry 2015-09-15 16:26 GMT+02:00 Martin Dias <tinchodias@gmail.com>:
Hi,
On Mon, Sep 14, 2015 at 5:02 PM, Skip Lentz <skip.lentz@inria.fr> wrote:
Hello,
Right now, when you add or remove a protocol to a class you get two announcements (ignoring methods that may have been removed):
1. Protocol{Added,Removed} 2. ClassReorganized.
But when you rename a protocol, you get just ClassReorganized (again, ignoring the method recategorizations). From this announcement, you only have access to the new class. So there is no way to tell the change.
To resolve this, I think a ProtocolRenamed announcement should be added, just like there is a CategoryRenamed announcement.
I think it makes sense, and it is harmless (I mean, shouldn't break anything).
MartÃn
This way Epicea can also log this, which it currently does not do. It logs the recategorizations of the methods in the protocol, but not the rename of the protocol. So as far as we can tell from the log, we canât see if the renamed protocol still exists or not.
Please share your thoughts,
Skip