interface stability policy on 1.8 branch

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: interface stability policy on 1.8 branch

L. David Baron
On Monday 2006-06-12 20:23 -0400, Benjamin Smedberg wrote:
> So the method has the same signature, but with a C++ default arg? Do you
> envision that coders may need to detect whether they're calling the "old"
> signature or the "new" signature? If we're going to rev nsIContent, I'm not
> sure it's not worth revving nsIEventListenerManager also.

So nsIEventListenerManager isn't all that related to nsIContent in usage
patterns -- it's retrieved from an nsIDOMEventReceiver.  But I think the
bigger argument is that I think if anybody's using it they're much more
likely to be using it to add/remove listeners than to create a new type
of object that receives events.  And the method I'm changing is only
related to callers doing the latter.  So I'm inclined to leave the
default-parameter hack and not rev the IID.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: interface stability policy on 1.8 branch

Darin Fisher-2
On 6/14/06, L. David Baron <[hidden email]> wrote:

> On Monday 2006-06-12 20:23 -0400, Benjamin Smedberg wrote:
> > So the method has the same signature, but with a C++ default arg? Do you
> > envision that coders may need to detect whether they're calling the "old"
> > signature or the "new" signature? If we're going to rev nsIContent, I'm not
> > sure it's not worth revving nsIEventListenerManager also.
>
> So nsIEventListenerManager isn't all that related to nsIContent in usage
> patterns -- it's retrieved from an nsIDOMEventReceiver.  But I think the
> bigger argument is that I think if anybody's using it they're much more
> likely to be using it to add/remove listeners than to create a new type
> of object that receives events.  And the method I'm changing is only
> related to callers doing the latter.  So I'm inclined to leave the
> default-parameter hack and not rev the IID.

That sounds reasonable to me.

-Darin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: interface stability policy on 1.8 branch

Mike Shaver
On 6/14/06, Darin Fisher <[hidden email]> wrote:

> On 6/14/06, L. David Baron <[hidden email]> wrote:
> > So nsIEventListenerManager isn't all that related to nsIContent in usage
> > patterns -- it's retrieved from an nsIDOMEventReceiver.  But I think the
> > bigger argument is that I think if anybody's using it they're much more
> > likely to be using it to add/remove listeners than to create a new type
> > of object that receives events.  And the method I'm changing is only
> > related to callers doing the latter.  So I'm inclined to leave the
> > default-parameter hack and not rev the IID.
>
> That sounds reasonable to me.

And to me.

Can someone make sure that these sorts of changes are called out to
sheppy so that they make it into the "Firefox2 for Developers" doc
he's slaving away on?  That would please me greatly.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12