DelegatesTo semantics...

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

DelegatesTo semantics...

Martin Chilvers
G'day,

I'm using the DelegatesTo trait and I've noticed that you don't get
trait change notifications if you change the object that you delegate
to. I can kind of see why this might be tricky to implement since you
would have to find all the traits that delegate to the object and then
check to see if any of the values are different, but without it, it
seems that the pattern is incomplete... See the attached test case for
details...

On a side note, I think in traits4, traits like Property, DelegatesTo
etc. should be implemented as trait 'modifiers' rather than as traits
themselves. These traits are not *types* like Int etc - they are
implementation details that determine how the value of a trait is found,
and they should be invisible to clients of a class (even meta clients).

Martin

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

traits_delegation_test_case.py (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DelegatesTo semantics...

Corran Webster
I could have sworn I have written code which relied on this working the way that you expect it to.  But I haven't written any serious traits code in over a year so my memory could be wrong (or I could have been writing buggy code :) ).  I agree the pattern is incomplete if this doesn't work.

Have there been changes to the traits codebase that might affect the way that this works?

-- Corran

On Tue, May 24, 2011 at 3:11 AM, Martin Chilvers <[hidden email]> wrote:
G'day,

I'm using the DelegatesTo trait and I've noticed that you don't get trait change notifications if you change the object that you delegate to. I can kind of see why this might be tricky to implement since you would have to find all the traits that delegate to the object and then check to see if any of the values are different, but without it, it seems that the pattern is incomplete... See the attached test case for details...

On a side note, I think in traits4, traits like Property, DelegatesTo etc. should be implemented as trait 'modifiers' rather than as traits themselves. These traits are not *types* like Int etc - they are implementation details that determine how the value of a trait is found, and they should be invisible to clients of a class (even meta clients).

Martin

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: DelegatesTo semantics...

Jonathan March
Perhaps the problem is not so much with delegation as with listening - in particular with the dynamic listener?

In the past few weeks I have successfully used static listeners on numerous DelegatesTo traits.

However I have had repeated instances of the @on_trait_change listener failing to trigger, with and without delegation.

Jonathan M

On Tue, May 24, 2011 at 9:50 AM, Corran Webster <[hidden email]> wrote:
I could have sworn I have written code which relied on this working the way that you expect it to.  But I haven't written any serious traits code in over a year so my memory could be wrong (or I could have been writing buggy code :) ).  I agree the pattern is incomplete if this doesn't work.

Have there been changes to the traits codebase that might affect the way that this works?

-- Corran

On Tue, May 24, 2011 at 3:11 AM, Martin Chilvers <[hidden email]> wrote:
G'day,

I'm using the DelegatesTo trait and I've noticed that you don't get trait change notifications if you change the object that you delegate to. I can kind of see why this might be tricky to implement since you would have to find all the traits that delegate to the object and then check to see if any of the values are different, but without it, it seems that the pattern is incomplete... See the attached test case for details...

On a side note, I think in traits4, traits like Property, DelegatesTo etc. should be implemented as trait 'modifiers' rather than as traits themselves. These traits are not *types* like Int etc - they are implementation details that determine how the value of a trait is found, and they should be invisible to clients of a class (even meta clients).

Martin

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: DelegatesTo semantics...

Robert Kern
On Tue, May 24, 2011 at 11:00 AM, Jonathan March <[hidden email]> wrote:
> Perhaps the problem is not so much with delegation as with listening - in
> particular with the dynamic listener?

No.

[~]
|1> from enthought.traits.api import *

[~]
|2> class A(HasTraits):
..>     x = Int()
..>

[~]
|7> class B(HasTraits):
..>     a = Instance(A, args=())
..>     x = DelegatesTo('a')
..>     def _x_changed(self, name, old, new):
..>         print '%s changed: %r -> %r' % (name, old, new)
..>

[~]
|8> b = B()

[~]
|9> b.x
0

[~]
|10> b.a = A(x=10)

[~]
|11> b.x
10


--
Robert Kern
Enthought
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: DelegatesTo semantics...

Jonathan March
On Tue, May 24, 2011 at 11:35 AM, Robert Kern <[hidden email]> wrote:
On Tue, May 24, 2011 at 11:00 AM, Jonathan March <[hidden email]> wrote:
> Perhaps the problem is not so much with delegation as with listening - in
> particular with the dynamic listener?

No.

Right, thanks. I read Martin's email too hastily ... the issue is changing the identity of the delegated-to object, not just its attributes.


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev