This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [setup PATCH] next_dialog micropatch (2)


On Tue, 2003-07-29 at 19:32, Max Bowsher wrote:
> Robert Collins wrote:
> > On Tue, 2003-07-29 at 06:50, Max Bowsher wrote:
> >
> >> You realise that *all* I am doing with this patch is to change how data
> is
> >> passed between a function and it's caller?
> >
> >
> > Yes, and its that aspect I objected to. I don't understand what was so
> > unclear.
> 
> I'm unclear on why you objected and what you want me to do instead.
> Please bear in mind that I have never read any Design Patterns books, and
> have no idea what an "Asynchronous Completion Token" is.

Thats ok - I thought you where referring to the "ACT" pattern is all.

> I'm also extremely puzzled, since you seem to be objecting to the use of a
> return value to communicate from a callee to a caller function. Any other
> method *must* be more complicated, and I do believe in avoiding unnecessary
> complication.

*must* is not strictly true here.
The thing I was objecting to was the use of the return value to return
program flow decisions, as opposed to the information needed to make the
decision.

> Just in case I'm not explaining myself well enough in words:
> 
> int foo()
> {
>     return 8;
> }
> 
> int main()
> {
>     printf("%u", foo());
>     return 0;
> }
> 
> In the above, you wouldn't want me to make foo void, and find another way to
> pass the value 8 back to main.... would you?

No, but it's not analogous:
* foo here is constant, it doesn't perform work, there is no decisions
to be made
* there is no current global to be 'fixed'.

A more useful analogy:

bool showUser = false;
int profit = 0;

void
getProfit()
{
   /* do some outside 'stuff' */
   profit = /* more outside stuff*/;
   if (profit > 45)
     showUser = true;
}

int main()
{
  getProfit()
  if (showUser)
    printf("profit: %d\n", profit);
  exit 0;
}

here, I would not put the boolean into the return value of getProfit.
(Functions that perform an action (mutators) should not return a value.)
I would:

bool showUser = false;

class Report {
public:
  Report() : profit(0) {}
  void calculateProfit() { 
     /* do the stuff */
    profit = /* ... */;
   if (profit > 45)
     showUser = true;
  }
  int getProfit() { return profit;}
private:
  int profit;
};

int main()
{
  Report aReport;
  aReport.calculateProfit();
  if (showUser)  
    printf("profit: %d\n", aReport.getProfit());
  exit 0;
}

as a first step. I'd probably then move the logic out of calculateProfit
into a 'bool showReport()' that does nothing but 
bool showReport() {
  return getProfit() > 45;
}


The analogy here is that moving the direction for the windows to go into
the return code, increases the coupling to the UI from the underlying
logic, and would be reversed as soon as a class is introduced to remove
a mutating method with a return code.

Cheers,
Rob

-- 
GPG key available at: http://members.aardvark.net.au/lifeless/keys.txt.
---

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]