Given the heterogeneity and complexity of the factors involved, not least of agreeing a common language to describe and access the construct of abnormal beliefs in question, it would seem sensible to adopt an eclectic approach to delusions — one that links understanding from neuroscience, cognitive and social psychology. This would allow ‘abnormal’ and delusional beliefs to be understood as arising not simply from damaged biological mechanisms or information processing modules, but from cognitive beings firmly situated within their social milieu. Such an approach might also better allow us to treat patients with distressing beliefs, as well as provide a clearer insight into how each of us comes to hold our own beliefs, be they viewed by others as mundane, profound or peculiar.
then google found Dr. William Henry Jones & Project Integration Architecture:
The Construct function is a member of
PObject but it is not declared virtual. Thus, the Construct function is just a simple member function (with class scope) of each class chosing to declare (and define!) it. In order to use it directly (which you shouldn't), your code must know at compile time that the pointer (or reference) is a pointer to the class which declares and defines the Construct function. A base class pointer will get the base class Construct function, even if all derived classes also have Construct functions!!!!
The way to access the Construct function (you knew there had to be a way, didn't you?) is to obtain a pointer to the correct
PClassInfo object through a call to the
GetClassDesc member function (which is declared virtual in
PObject and call the
CreateObject member function of that object. Since the
GetClassDesc member function is a virtual function, you will obtain the 'right'
PClassInfo pointer regardless of whether or not you are using a base class pointer and you will necessarily get the 'right' Construct function. In this way, base class code can construct new derived class objects without knowing what derived classes might exist or what they do. Ain't that neat?.
PIA paper here: Abstract One of several key elements of the Project Integration Architecture (PIA) is the intention to formulate parameter objects which convey meaningful semantic information. In so doing, it is expected that a level of automation can be achieved in the consumption of information content by PIA-consuming clients outside the programmatic boundary of a presenting PIA-wrapped application. This paper discusses the steps that have been recently taken in formulating such semantically-meaningful parameters. SEE: Project Integration Architecture: Architectural Overview.
quick pass: usually, location defines semantic meaning in object-oriented technology; PIA wraps several layers of structural meaning (infusion of semantic meaning) ... PIA establishes the semantic nature of any given number not by its position in a file or a structure or an input stream, but by the kind of object in which the number is presented [...] This infusion of meaning is a change from previous approaches in which parameters obtained semantic meaning by virtue of their position in input/output streams and internal usage in a program. A key benefit of semantic infusion through object derivation is that measurement types and systems of measurement can (and do) become encapsulated characteristics of parameter objects. Parameter objects can now ‘know’ whether they are in feet or meters, pounds force or Newtons and can, thus, tailor themselves through conversion to desired forms on demand . Object, know thyself?
PIA commercialization plan makes an interesting point about conformance to the standard:
The assertion that forms the foundation of the commercialization plan being proposed is that PIA is, at its heart, an application integration standard. PIA is something to which application wrappers based upon its technology conform. In being a standard, this then implies that more than one party desires to conform to it in order to obtain the benefits of standardization. It is further proposed that revenues derive from the benefits delivered to the customer. It is in conformance to the standard, rather than in the standard itself, that the true benefits derive and, thus, the source of revenue is identified. Following this logic, the PIA technology, being a standard, and its implementation, is not the revenue source. Rather, it is in products that conform to and support the PIA technology standard that the primary revenue stream is to be found. As a parallel, consider the IBM PC industry. It is asserted that the IBM PC architecture itself is not the source of revenues in this industry. Instead, it is the conformance of the products of various vendors to that architecture that produces the revenue. This can be inferred if one considers that the success of that industry is, in all probablity, independent of the computer architecture selected. Had Digital Equipment Corporation placed the VAX architecture in a similar, open-technology posture, the PC industry most probably would have succeeded equally by putting generic, compatible VAXes in desktop boxes.
• Burt Rutan, the X-Prize, and their Impact on Getting into Space
• A Word from the Know-Nothing Bureaucrats :: Space is easy. So says the alternative, private-sector space crowd momentarily being led into that glorious blackness by Burt Rutan and his SpaceShipOne. The bureaucracy just makes it "hard" to protect their jobs, their budgets, and their little political niche in life. Yeah. As Mr. Rutan is about to find out (and is perhaps already finding out) space, even the little toe-hold he is trying to gain, is hard - in fact, space is very hard. I will admit that bureaucracy doesn't make space any easier, as witness the tangled management and cultural mess the Columbia Accident Investigation Board uncovered, but taking away the bureaucracy won't magically make space flight something your granny can do with her Oldsmobile. Space is a hard, dangerous, demanding, expensive, and unforgiving world to fly in.
i love this guy.