Tweak question

> I don't understand (what appears to me as) some duplication in  
> Tweak's event
> propagation mechanism in the bank-account tutorial http://
> tweak.impara.de/TECHNOLOGY/Tutorials/BankAccountTutorial/ : an ATM
> hooked to a bank account and displaying its balance on its  
> #balanceReadout.
>
> It keeps the #balanceReadout widget current by hooking into 2  
> separate events
> with 2 pieces of code:
>
> onAccountChanged
> "Update the balance readout when the account changes"
> <on: accountChanged>
> self updateBalanceReadout
>
> onAccountValueChanged
> "Update the balance readout when the account value changes"
> <on: valueChanged in: account>
> self updateBalanceReadout.
>
> This seems unnecessary. If I simply declared the path to the target  
> object
> being observed:
>   { #account #value }
> It seems I have said enough to respond correctly to both  
> #accountChanged and
> #valueChanged. The rest could be done by Tweak behind the scenes.
>
> Such a role-chain is a common scenario:
>    A is watching the #x of the #y of the #z.
> Hence A has to react to xChanged, yChanged, and zChanged (in the  
> appropriate
> corresponding target objects).
>
> Similarly, given Tweaks real + virtual fields, I'm not sure why all  
> the
> on<X>Changed stuff needs to be explicit. Why not directly reference  
> the
> fields e.g. Isn't the underlying event behavior adequately determined
> by something declarative along the lines of:
>
>  { #balanceReadout #value } derivedFrom: { #account #value }
>
> Is there already some better way to do this in Tweak, just not used  
> in the
> tutorial?