> > For the "it could break stuff" argument, I agree, but it was clearly stated
> by al that we can break compatibility and that the API should be clean for
> 6.1.
>
> Just because we *can* break stuff does not mean we *should* break stuff on a
> whim, which what happens here.
>
> > As far as I understand that, that's not because we chose a bad name at first
> that we should keep it.
>
> And there's nothing bad about `#stop`.
>
> > As I explained, now the ParentedMixin is totally independent to Widget and
> so there is no purpose to conceive it with Widget in mind.
>
> Widget is not independent of ParentedMixin and that's more than reason enough
> to consider this when you suggest breaking any code using this protocol
> without justification.
>
> > Finally, OF COURSE it implies destructor semantic
>
> No, destructor semantics are complex and, among other things, imply the object
> does not *exist* after the destructor or finalizer was called. This is *not*
> what this method does and it is *not* a destructor, semantically it matches
> C#'s Dispose() or Java's (and Python's) close(), not destructors or
> finalizers.
>
> [a bunch of ad hominem]
>
> > If you compare to C++
>
> Don't compare to C++, there are no comparison basis because the languages
> could hardly have more different lifecycle semantics. If you want to compare
> to something I'd suggest comparing to other garbage-collected languages,
> dynamically typed or not, that would be a much better base. And none of them
> implements destructor semantics any more than your mis-renamed method does.
>
> > Those are fixed.
>
> Half are fixed.
>
I don't agree with you about the semantic of destroy. Where is it written that
"destructor semantics imply the object does not exist after the destructor or
finalizer was called" ? Anyway, I could accept a compromise by switching to a
solution inspired by java or c#. My point is mostly that stop() does not have
any meaning, that's why I want to change it.
> > Not sure I understand. Could you rephrase?
>
> Why would stopping semantics, and stoppage queries, belong in a mixin for
> parent/child relationship instead of being independent from and above it?
It could, here is what it will look like:
DestroyableMixin = {
destroy: function() {/*to implement*/}
};
Didn't we had a discussion recently about the fact you don't think it's useful
to formalize interfaces in duck-typed languages ? That doesn't seem very
consistent.
PS: Xavier, you just criticize my solution and the most constructive comment
you can make to explain the current one is "And there's nothing bad about
`#stop`". Can't you try to justify it? Say what is the conceptual meaning of
the name 'stop'? al will say I complain again, but it's been a long time your
only argumentation is completely based upon criticizing and making opposing
arguments look ridicule, sometimes you just say your opponent is stupid. What
type of argumentation is that? I really think most of your talk is leaded by
aggressiveness, what I would like to know is if you do it on purpose or
unconsciously. And you, do you know it?
--
https://code.launchpad.net/~openerp-dev/openerp-web/trunk-core-extraction-1-niv/+merge/94021
Your team OpenERP R&D Team is subscribed to branch
lp:~openerp-dev/openerp-web/trunk-core-extraction-1-niv.
_______________________________________________
Mailing list: https://launchpad.net/~openerp-dev-gtk
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-dev-gtk
More help : https://help.launchpad.net/ListHelp
