Reorder the args to these adapters: success is first now, followed by failure.

This has been wacked-out like this ever since I first wacked it out.
Since the base class is ResultAdapter and it only takes failure, and the
'processed' function for ConfirmAdapter is optional, it seemed to make
sense this way.
But, we have another ResultAdapter (for non-invocation ResultListener)
and it expects success first.
So Mike noticed this today (I swear there was a big brouhaha about this
over the summer) and beat me with my own rubber chicken.
I'm not sure why I had a mental block about reordering, but let's do it!


git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5583 542714f4-19e9-0310-aa3c-eee0fc999fb1
This commit is contained in:
Ray Greenwell
2008-12-09 02:20:48 +00:00
parent 343a2a7026
commit 5f69af762d
2 changed files with 6 additions and 3 deletions
@@ -24,8 +24,11 @@ package com.threerings.presents.client {
public class ConfirmAdapter extends InvocationAdapter
implements InvocationService_ConfirmListener
{
public function ConfirmAdapter (
failed :Function, processed :Function = null)
/**
* Construct a confirm adapter.
* The processed function may be null.
*/
public function ConfirmAdapter (processed :Function, failed :Function)
{
super(failed);
_processed = processed;
@@ -27,7 +27,7 @@ package com.threerings.presents.client {
public class ResultAdapter extends InvocationAdapter
implements InvocationService_ResultListener
{
public function ResultAdapter (failed :Function, processed :Function)
public function ResultAdapter (processed :Function, failed :Function)
{
super(failed);
_processed = processed;