Test.Simple style questions

[Marvin Humphrey]

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,

[Marvin Humphrey]

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

> I'd have gone with lowerCamelCase,
> but perhaps there's a pattern I haven't caught on to.

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();
};

[David E. Wheeler]

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

> 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.

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

> 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.

:-) 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

[David E. Wheeler]

On Aug 21, 2007, at 18:55, 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:

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

Best,

David