Loading...
 
Print

should

In page names, the word should is limited by living ontology to uses described in OP:should. It is preferred to the less overt term:for which tends to combine assumptions about goals, roles, purposes and desirable outcomes. Using should teases them out:

"Names of test methods should always include the word "should"... it forces you to think more about the responsibilities of the object you are testing." - software architect Kevin Rutherford?

In open politics itself, separating any statement about what "should" be, from statements about the problem, or problems with the solution, is central to the issue/position/argument form perhaps best developed in dkosopedia: FrameShop(external link)

can't get to "should" from "is"


David Hume? was one of the first political philosopher?s to point out that one cannot derive any statement about what should be, in fact, no morally normative statement at all, from any combination of simple statements about what is. Subsequent separation of "is" into "becomes/remains/equals?" or "should" into infer/refer/defer types of norms (Rutherford's test methods being of the infer type, dkosopedia's Dem-leaning positions being of the defer type, and those of living ontology being generally of the refer type) did not change the basic separation of the two domains: vision, deliberation and decision? is required to move from any set of "is" to any "should".

The software engineering dilemma of assertions was historically solved by making data items visible, so a general test of an object's entire state at any time could be conducted. The dialectic between goals "make fields public" vs. "don't expose an object's state" is today most often resolved by ensuring, to quote Craig Hubley, "that you have no objects that are so passive that they can work with fields exposed. Refactor. And do all your "setting" with assertions,"

position as assertion


As Rutherford puts it, "...have a single assertThat() method that takes an actual value and a constraint. With suitable sugar-methods, you can make your assertions read almost like english :

  • assertThat(myFile, contains("this string));"

Such English-like assertions are also the basis of naming conventions at openpolitics.ca itself, compare:

The assertion is clear: someone takes that position, someone does that comparison. Ideally assertions are from the perspective of the user in different roles, e.g. as voter. In all open politics services relying on living ontology, active verbs (from the perspective of the user or using service) are strictly controlled as to their meaning. There's one list of all control verbs paralleling the list of all issues debated.

restrictions on "should"


Any "should" language is under living ontology restricted to positions, and assertions about testable behaviour exactly as you describe, i.e. many "position:" namespace articles have a "should" either explicit or implied in their title.

A similar restriction applies to use of we/will/must and all which assume complete control of the object by the subject.

why restrict verbs?


This restriction of verbs is the same principle as REST and standardized user interface design under usability guidelines, which rely on a very few common verbs ("preview", "post"). In dating service?s consider such self-assertions as:
  • "I'm a _gender_ of age _ in _location_ seeking ..."

"When I designed the predecessor to the lavalife service, reducing all the language to simple assertions with common verbs was the main goal, and it worked very well: the instructions read similarly to the screens, and so on. What's harder is to make errors and exceptions also converge to this language." - Craig Hubley

Bill Joy? considers the convergence of error messages to the architectural objects to be the number one sign of good operating system design.




Show php error messages