On 2007-06-20, at 00:39 EDT, Robin Sheat wrote:
This will override the setter in your superclass and correctly
install your play method. Of course, that will mean your subclass
will not obey the normal play protocol of views.
No matter in this case, it just relays the play signal to another
object.
However, there's an interesting point raised here (academically,
anyway, I
don't need to do this), the implication from what you say is that
the normal
behaviour for 'stop' will be invoked even if it is overridden. Is
this the
case? I kinda assumed that JS would use a Java-like method, such as
super.method(), to do this, but it's never come up for me.
Your assumption is correct. By writing a stop method, you are
overriding the stop method in the superclass and you would have to
make a super call to invoke it. Since you have overridden the stop
method, the superclass setter for play will end up calling your
method, so the play protocol isn't going to work because of that too.
Really, I think this API is just crazy. In the base class, there are
`play` and `stop` methods, and there is a setter for the `play`
attribute. Setting `play` to true or false invokes the `play` or
`stop` methods respectively. It's a clever pun, that can be created
in the runtime, but that leaves you with the mess you have found in
LZX. I think it would have been better to use separate names for the
attribute and the method. For instance, there is another attribute
`playing` that says whether the resource is playing or not. Perhaps
the setter should have been on `playing`. [Why have a setter at
all? Presumably so you can easily write a constraint that will
control playing.]
