David,

What's the rationale behind the stylistic choice of naming some  
member vars using UpperCamelCase, e.g. this.TestResults?  It seems  
like an unusual decision, since UpperCamelCase is usually reserved  
for classes/packages/namespaces.  I'd have gone with lowerCamelCase,  
but perhaps there's a pattern I haven't caught on to.

Also, a heads-up: for the new Test.Builder.TestResult class, I intend  
to use get/set accessors everywhere.  Public member vars suck.  See  
below.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

/usr/www/live/htdocs/junk/Test.Simple/ $ ack actual_ok
doc/pod/Test/Builder.pod
479:      actual_ok: did it literally say 'ok'?
493:"actual_ok" is a reflection of whether or not the test literally  
printed "ok"
523:and actual_ok is left C<null>.
530:      actual_ok: 0,      // in absolute terms, it failed

lib/Test/Builder.js
231:        result.actual_ok = test;
235:        result.actual_ok = false;
420:        actual_ok: true,
447:        actual_ok: false,
642:                actual_ok: null,

tests/details.js
10:    actual_ok: true,
20:    actual_ok: true,
32:     actual_ok: false,
43:    actual_ok: false,
53:    actual_ok: true,
65:    actual_ok: null,
77:    actual_ok: true,

/usr/www/live/htdocs/junk/Test.Simple/ $ ack actualOK
lib/Test/Harness.js
112:                    if (test.TestResults[i].actualOK) this.bonus++;

tests/harness.js
61:            actualOK: true,
68:            actualOK: true,
101:    actualOK: false,
128:mockTest.TestResults[2].actualOK = true;
152:mockTest.TestResults[2].actualOK = false;
206:    actualOK: false,
296:        actualOK: true,
303:        actualOK: true,

On Aug 21, 2007, at 6:38 PM, Marvin Humphrey wrote:

Hmm, I think I get it now.

     Test.Builder.prototype.noPlan = function () {
         this.NoPlan   = 1;
         this.HavePlan = 1;
     };

The shared namespace for functions and member vars in JS objects  
forces the matter.

I see that nearly all member vars for Test.Builder follow that pattern:

     Test.Builder.prototype.reset = function () {
         this.TestDied      = false;
         this.HavePlan      = false;
         this.NoPlan        = false;
         this.CurrTest      = 0;
         this.ExpectedTests = 0;
         this.UseNums       = true;
         this.NoHeader      = false;
         this.NoEnding      = false;
         this.TestResults   = [];
         this.ToDo          = [];
         this.Buffer        = [];
         this.asyncs        = [0];
         this.asyncID       = 0;
         return this._setupOutput();
     };

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

On Aug 21, 2007, at 18:38, Marvin Humphrey wrote:

IIRC, it was to highlight it as special. It's not really designed for  
user by end users. But it doesn't really matter.

:-) For some reason, they bother me less in JavaScript. Probably  
because you access them in much the same was as methods (with a dot),  
and because you can use = to assign to them, which I always liked.  
But of course, as soon as you need some sort of validation, you need  
to write a method, and then they should all be methods, for the sake  
of consistency.

Best,

David

On Aug 21, 2007, at 18:55, Marvin Humphrey wrote:

Yes, this was taken directly from Test::Builder, which has (or used  
to have) global variables all over the place.

Best,

David