Thanks for your response!
On Mon, Sep 30, 2013 at 8:41 PM, Glyph firstname.lastname@example.org wrote:
On Sep 30, 2013, at 2:45 AM, Laurens Van Houtven email@example.com wrote:
What am I doing wrong? Is this a bug?
I think it's pretty clearly a bug. Calling the argument "proto" in the first place indicates the nature of the confusion.
There are parts of the flow here from bytes to method execution and back (like _wrapWithSerialization) which are nice for composition, but the fact that they're private sort of ruins their utility for extensibility.
Looking at the code you're trying to write in txampext though, the problem appears to be simply that you're writing functionality close enough to AMP's core that you should be making the changes to AMP directly, and fixing the issue by making changes to AMP itself rather than trying to work around it externally. The way I was going to recommend fixing it before I clicked on your link was by writing something like ExposingArgument and accessing the locator/receiver/sender via that new API rather than via the 'proto' argument at all :)
I'm a little confused why that would help; you're saying there should be a new API that gives arguments access to the locator, receiver, sender? What would that look like? Something along the lines of fromBox/toBox, or are you thinking of a more direct approach where the locator has a reference to the other components? (Given your suggestion of not going through the proto argument, I imagine something closer to the latter.)
My contributions to AMP have been more of the defect-findy kind, but I could certainly turn them more into the code-contributy kind. I imagine I'm not the first person to want tests for command classes ( https://github.com/lvh/txampext/blob/master/txampext/commandtests.py) or a nested AMP box ( https://github.com/lvh/txampext/blob/master/txampext/nested.py).
I look forward to being in the same locality as you, I presume it will make me more productive ;)