egc@CS.CMU.EDU (eddie caplan) (07/18/90)
it has been argued that object oriented programming allows for rapid
adaptation to change. so, what is the ultimate manifestation of such
programs? objects that can self-adapt to a changing environment?
intelligent objects? have we discovered an unintended approach to AI?
is flexibility itself a definition of intelligence?
please, let's start a serious discussion about what object orientation can
achieve.
thanks,
eddie
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
INTERNET: caplan@cs.cmu.edu BITNET: caplan%cs.cmu.edu@cmuccvma
CSNET: caplan%cs.cmu.edu@relay.cs.net UUCP: ...!seismo!cs.cmu.edu!caplan
USPS: eddie caplan, c/o school of comp sci, cmu, pittsburgh, pa 15213-3890
phone: (412) 268-6426
a good engineer is a good thief. bennet, thanks for the signature.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
INTERNET: caplan@cs.cmu.edu BITNET: caplan%cs.cmu.edu@cmuccvmagus@plains.UUCP (jim gustafson) (07/18/90)
>it has been argued that object oriented programming allows for rapid >adaptation to change. so, what is the ultimate manifestation of such >programs? objects that can self-adapt to a changing environment? >intelligent objects? have we discovered an unintended approach to AI? The ability of a program to to reason about itself, and modify it's process state involves the concept of _computational reflection_. Reflective languages such as modified Actors have been studied quite a bit by OOP researchers. For a treatment of reflection in Smalltalk-80, see: Foote, B. and Johnson, R.E., "Reflective facilities in Smalltalk-80", Conf. Proc. OOPSLA '89, Oct., 1989, pp. 327-335. --jwg. -- Jim Gustafson gus@plains.nodak.edu uunet!plains!gus (UUCP) gus@plains (Bitnet)
rick@tetrauk.UUCP (Rick Jones) (07/19/90)
In article <EGC.90Jul17163309@MEAT.PIE.CS.CMU.EDU> egc@CS.CMU.EDU (eddie caplan) writes: > >it has been argued that object oriented programming allows for rapid >adaptation to change. so, what is the ultimate manifestation of such >programs? objects that can self-adapt to a changing environment? >intelligent objects? have we discovered an unintended approach to AI? >is flexibility itself a definition of intelligence? I'd like to throw a few thoughts in to help start this off. This is sparked by the mention of AI, and my observations that various computing disciplines, including AI, seem to be saying "hey, we can use objects too!". This may not exactly be addressing the point raised, but it's along similar lines. So, do we have "intelligent objects" created by AI engineers, with their close cousins "expert objects", not to mention perhaps "functional objects", "logical objects", etc? I think (hope!) not. Object orientation is really a design concept far more than a language concept. The languages help by providing more direct support for the design, but object oriented designs can be implemented in procedural languages if you try hard enough. A classic example is the X-windows intrinsics toolkit. The essential characteristics of an object are that it is something which will provide information about itself, and accept requests to act upon itself. How it finds the information or performs the actions is its business, not its client's. In current object oriented languages we already have the ability for an object to provide information either from an internally stored value or from computation, in a transparent way. In other words we can have different computational models (taking storage to be the simplest computational model) within the same object to achieve the required results, transparently. AI, rule-based deduction, logical computing, functional computing, etc. are all in the end different computational methods of achieving results. The real way to widen the scope of object methods is to try to allow a mixture of computation concepts WITHIN THE SAME CLASS. This means that if I have an object which can give me 3 pieces of information, I should be able to have, say, one item held as storage, another computed on request, and the third deduced using a knowledge base. Client objects need know nothing of the differences. This is obviously a simplistic view of the concept, and we're a long way from being able to implement it in any general form, but I think the underlying principle is important. My real point is that objects should be seen as being something at a higher level than languages, not just a good gizmo for each language discipline to adopt, use, mis-use, hype, hijack, corrupt, or whatever (select according to your synicism rating). I have, incidentally, looked in outline at the practicalities of building classes which can consult an embedded expert-system engine to provide results to calling classes transparently, and I think it is very feasible. I anticipate pursuing this further in the future (when I've solved my current problems). >please, let's start a serious discussion about what object orientation can >achieve. Serious enough? (Sorry about the loose use of "class" and "object", but I didn't think the rigorous distinction was important to this discussion) -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp
dmg@ssc-vax.UUCP (David Geary) (07/27/90)
In article <525@tetrauk.UUCP>, Rick Jones writes: > I am using Eiffel, and planning to make maximum use of it's exception handling > to deal with everything which is not a normal down-the-middle expected > situation (at least at the prototype stage). This includes things which are > not normally treated as errors, such as "record not found" on file access, or > "wrong entry" at a terminal. This could be a good subject for discussion; > has anyone any experience of taking this approach to building software? Well, it's a good idea to check for things which are not "normal down-the-middle expected situations". However, I do not know if one would want to raise exceptions *every* time an unexpected situation arises. I program in C, and use assertions religiously (after reading OOSC by Bertrand Meyer, BTW). Anyway, here is a function that I wrote for a generic doubly linked list package: PUBLIC listNode_t* list_GetNodeByPos(list, pos) list_t* list; int pos; { ASSERT_BOOL(list); { listNode_t* nextNode = list_GetFirstNode(list); int nodeCnt; if(list_IsPosValid(list, pos)) { for(nodeCnt=1; nextNode; ++nodeCnt) { if(nodeCnt == pos) return nextNode; nextNode = listNode_GetNodeAhead(nextNode); } } return NULL; } } The function returns a node at a specified position. It would not be a "normal down-the-middle expected situation" for someone to do: list_GetNodeByPos(list, 5); when there are only 4 nodes on the list. Initially, one might be inclined to put an assertion to assert the validity of pos upon entry to the function. This eliminates the if(list_IsPosValid(list,pos)) test from the function, and, IMHO, makes the function easier to read. However, someone may want to do the following: list_t* myList; int cnt=1; ... while(nextNode = list_GetNodeByPos(myList, cnt++)) { ... do something interesing with nextNode ... } When cnt becomes greater than the number of nodes on the list, the function (as written above) quietly returns NULL, and the while loop is terminated. However, if one puts an assertion at the top of the function to assert pos, then a message will appear on stdout (screen) like so: Assertion Failed: File: list.c Line: xxx Therefore, one must make a decision when deciding how to handle "abnormal" situations (or, in eiffel-speak, when forming the invariant for a class). Is the "abnormal" situation serious enough to warrant an assertion, or do we want to return a value which implies an error? This is a seemingly simple question, which can be surprisingly difficult to answer under certain circumstances.