* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <132301@cup.portal.com> @ 1995-02-06 15:37 ` Fergus Henderson 1995-02-07 14:43 ` John Volan 1995-02-09 20:58 ` Mike Bates [not found] ` <9503802.3538@mulga.cs.mu.oz.au> 2 siblings, 1 reply; 12+ messages in thread From: Fergus Henderson @ 1995-02-06 15:37 UTC (permalink / raw) R_Tim_Coslet@cup.portal.com writes: >Hmm, just wondering, but has there ever been a computer programming >language similar in "syntax" to Latin? (using "prefixes"/"suffixes" >only instead of order to indicate which identifers were refering >to the procedures/functions and which to data sources or destinations). > >Most programming languages seem to use order related syntaxes >(e.g. prefix, infix, or postfix operator notation)... Prolog uses case to distinguish between variables (which are data sources/ destinations) and atoms (which Prolog uses for constants, functions, and procedures). Variables must start with an uppercase letter (or an underscore) while atoms must start with a lowercase letter (or be quoted). -- Fergus Henderson - fjh@munta.cs.mu.oz.au all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] 1995-02-06 15:37 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] Fergus Henderson @ 1995-02-07 14:43 ` John Volan 0 siblings, 0 replies; 12+ messages in thread From: John Volan @ 1995-02-07 14:43 UTC (permalink / raw) fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes: >R_Tim_Coslet@cup.portal.com writes: >>Hmm, just wondering, but has there ever been a computer programming >>language similar in "syntax" to Latin? (using "prefixes"/"suffixes" >>only instead of order to indicate which identifers were refering >>to the procedures/functions and which to data sources or destinations). >> >>Most programming languages seem to use order related syntaxes >>(e.g. prefix, infix, or postfix operator notation)... >Prolog uses case to distinguish between variables (which are data >sources/ destinations) and atoms (which Prolog uses for constants, >functions, and procedures). Variables must start with an uppercase >letter (or an underscore) while atoms must start with a lowercase >letter (or be quoted). I think what Tim was referring to was *grammatical* case (think: declension), not *typographical* case (think: capitalization). >-- >Fergus Henderson - fjh@munta.cs.mu.oz.au >all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-) -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <132301@cup.portal.com> 1995-02-06 15:37 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] Fergus Henderson @ 1995-02-09 20:58 ` Mike Bates [not found] ` <9503802.3538@mulga.cs.mu.oz.au> 2 siblings, 0 replies; 12+ messages in thread From: Mike Bates @ 1995-02-09 20:58 UTC (permalink / raw) R_Tim_Coslet@cup.portal.com writes: >Hmm, just wondering, but has there ever been a computer programming >language similar in "syntax" to Latin? (using "prefixes"/"suffixes" >only instead of order to indicate which identifers were refering >to the procedures/functions and which to data sources or destinations). > >Most programming languages seem to use order related syntaxes >(e.g. prefix, infix, or postfix operator notation)... Yes! Replace while loops with the ablative absolute! grassibus.longibus { lawnum.mowite; } (Sorry, my Latin dictionary is at home.) -- ------------------------------------------------------------------------------ Mike Bates FlightSafety International, Simulation Systems Div. Principal Engineer 2700 North Hemlock Circle Computer Systems Group Broken Arrow, Oklahoma 74012 mikeb@ssd.fsi.com 918-251-0500 ext. 462 ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <9503802.3538@mulga.cs.mu.oz.au>]
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <9503802.3538@mulga.cs.mu.oz.au> @ 1995-02-10 15:19 ` Jules 0 siblings, 0 replies; 12+ messages in thread From: Jules @ 1995-02-10 15:19 UTC (permalink / raw) In article <9503802.3538@mulga.cs.mu.oz.au>, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes: >all [L] (programming_language(L), L \= "Mercury") => better("Mercury", L) ;-) Doesn't this mean that all programming languages (other than Mercury) are better than Mercury? ;-> -- /* Julian R Hall csusb@csv.warwick.ac.uk Flames should be redirected to /dev/null - I don't know what I'm saying myself so don't expect it to make sense all the time! */ ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <3f9g1u$j4m@nps.navy.mil>]
* Re: ADA Objects Help! @ 1995-01-22 18:06 ` Robert Dewar 1995-01-24 22:18 ` Norman H. Cohen 0 siblings, 1 reply; 12+ messages in thread From: Robert Dewar @ 1995-01-22 18:06 UTC (permalink / raw) Rob Wilkinson, if you cannot see that from a purely semantic point of view there is nothing particularly special about member functions, then maybe it is you who need a better C++ book. You are viewing them through a semantic filter which says that you will view these member functions in a special way, corresponding to a particular paradigm that you (and the language design!) have in mind. However, if you can manage to take a more basic viewpoint, you will see that member functions are just functions, nothing more and nothing less. THey have a special syntax and visibility, but that does not mean they are semantically fundamentally different from ordinary functions. YOu may just be to wrapped up in your viewpoint to see the point that several people have made to you, certainly it does not seem to be registering. Basically we have functions that can be used as ordinary functions and functions that you want to associate with a particular "object". Note incidentally that at the language level, C++ does not have objects, it has special structures that are called classes that may be particularly well suited for the representation of objects, but they are not objects, because the concept of object has to do with programming paradigms, NOT with the language design. In Ada 95, this same programming paradigm (objects and member functions, probably better called methods in this context, since member functions is just a syntactic designation), are represented by tagged types and associated primitive subprograms with controlling arguments. Just as in C++, classes and member functions may be used to represent objects and methods, but of course have many other uses, in Ada 95, tagged types and primitive operations of these types may be used to present objects and methods. The semantics in this correspondence are pretty much identical, although the Ada 95 model is a little more flexible in that one can have more than one appearence of the tagged type in the parameter list, which together act as a controlling operand. THis is not important if you are strictly representing objects and methods, but can be very useful in other contexts. I think the reason that no one understands what you are saying, and consequently that you are getting frustrated, is that you are starting out from some fundamental assumptions that are false: classes in C++ represent objects, false, they can be used to represent objects, but that is a programmer choice. member functions in C++ are methods. again false, they can be used for this purpose, but that is a programmer design choice. Then you add to it your apparent feeling that this particular usage is critical enough that it is important to give it a separate syntax. The trouble is that this introduces multiple syntaxes for identical semantic concepts (at the language level), and in the Ada 95 design we consider it an advantage that no separate syntax is used. It leads to a much more flexible capability, with all the power of the corresponding C++ constructs and additional capabilities. In C++, classes are often used for purposes other than the representation of objects. For instance, in the absence of name spaces, they are used to represent packaging of entities quite often, and in this context the special syntax for member functions can definitely get in the way (e.g. if the function is a binary operator operating on the class type). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ADA Objects Help! 1995-01-22 18:06 ` ADA Objects Help! Robert Dewar @ 1995-01-24 22:18 ` Norman H. Cohen 1995-01-25 1:26 ` swdecato 0 siblings, 1 reply; 12+ messages in thread From: Norman H. Cohen @ 1995-01-24 22:18 UTC (permalink / raw) In C++, members may be static or nonstatic and may be data members or function members: class C { public: int nonstatic_data_member; static int static_data_member; void nonstatic_function_member(int x); static void static_function_member(int x); }; static void C::nonstatic_function_member(int x) { [references to static_data_member or nonstatic_data_member] } static void C::static_function_member(int x) { [references to static_data_member, but not nonstatic_data_member] } These reflect the unified/confused role of a class as a type definition and as a module. The equivalent in Ada is: package C_Module is type C_Type is record Nonstatic_Data_Member: Integer; end record; Static_Data_Member: Integer; procedure Nonstatic_Function_Member (This: access C_Type; X: in Integer); procedure Static_Function_Member (X: in Integer); end C_Module; package body C_Module is procedure Nonstatic_Function_Member (This: access C_Type; X: in Integer) is ... begin [references to Static_Data_Member or This.Nonstatic_Data_Member] end Nonstatic_Function_Member; procedure Static_Function_Member (X: in Integer) is ... begin [references to Static_Data_Member] end Static_Function_Member; end C_Module; The Ada formulation is actually a more accurate depiction of the usual C++ implementation than is the C++ formulation. The C++ formulation suggests that each object of class C has space set aside for its own copy of the function, or at least of a pointer to the function. (This effect can be achieved in Ada with a record component belonging to an access-to-subprogram type.) In reality, since the function is not virtual, the function body is the same for all members of the class, so there is only one copy of it and it is called directly, without going through any pointers. A pointer to the object "containing" the called function is passed to this single copy through the implicit parameter "this", and a reference to nonstatic_function_member in the function body is just a shorthand for this->nonstatic_function_member. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ADA Objects Help! 1995-01-24 22:18 ` Norman H. Cohen @ 1995-01-25 1:26 ` swdecato [not found] ` <D330pK.M1@nntpa.cb.att.com> 0 siblings, 1 reply; 12+ messages in thread From: swdecato @ 1995-01-25 1:26 UTC (permalink / raw) I started this discussion on the comp.lang.ada news group and was pleasantly surprised to see that it had migrated here... I am a new Ada student, so correct me if I make any glaring mistakes. Your sample code attempts to mimic a C++ class using a package. The problem with the package implementation is that I can't instantiate instances of the object at run time. In Ada, a pointer to a package is created at compile time since the declaration using the "new" operation occurs prior to the firt BEGIN. From a syntax standpoint, Ada packages are as close to C++ classes as you can get, minus the dynamic allocation. Many Ada folks have demonstrated how Ada objects are created and deleted. My argument against the Ada style was that I felt that the C++ syntax more accurately modelled the englist language. I have no doubt that the same effect can be achieved with either language. I still say that the following code is easier to understand when dealing with objects... MY_TYPE *objectPtr = new MY_TYPE; objectPtr->run(); objectPtr->sleep(); objectPtr->move(); objectPtr->Set(A,B); etc In Ada the same program would be: Run(objectPtr); Sleep(objectPtr); Move(objectPtr); Set(objectPtr, A, B); I don't see how passing "structs" to static functions differs from any other function which takes a parameter. In my mind, when I create a pointer to an object of some user defined class, that one pointer takes any public data and functions associated with the class. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <D330pK.M1@nntpa.cb.att.com>]
* Re: ADA Objects Help! [not found] ` <D330pK.M1@nntpa.cb.att.com> @ 1995-01-28 21:46 ` John DiCamillo 1995-01-30 22:50 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] John Volan 1995-01-29 18:19 ` ADA Objects Help! mat 1 sibling, 1 reply; 12+ messages in thread From: John DiCamillo @ 1995-01-28 21:46 UTC (permalink / raw) ka@socrates.hr.att.com (Kenneth Almquist) writes: >swdecato@cs.nps.navy.mil wrote: >> Many Ada folks have demonstrated how Ada objects are created and deleted. >> My argument against the Ada style was that I felt that the C++ syntax more >> accurately modelled the englist language. >I don't know about you, but when I issue a command in English I place the >verb before the noun, as in "Mow the lawn." This translates naturally to >the C or Ada code: > mow(lawn); >The C++ alternative, > lawn->mow(); >is backwards. Actually, your example is backwards. An imperative in English has an implicit subject (usually 'you', that is, the person being commanded) and an explicit object (in this case, 'lawn'). So the Ada code would be: mow(robot, lawn); and the C++ would be: robot.mow(lawn); >Not to make too big a deal about this--either order (noun before verb or >verb before noun) is readable once you get used to it. I doubt that one >order is inherently "better" than the other. Agreed. >However, using both orders >in the same program seems like a bad idea if you are concerned about >readability. Oh, no. Here I must disagree. The two syntaxes (in C++) represent operations with different properties, so having a single syntax is potentially confusing. Note: I don't believe that the amount of confusion in either case is significant, but I am satisfied with the C++ (and Eiffel, and Smalltalk, and...) syntax. > Kenneth Almquist -- ciao, milo ================================================================ John DiCamillo Pinin' for the fjords? milod@netcom.com What kind of talk is that? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Subject/Object Confusion Syndrome [was: Ada Objects Help] 1995-01-28 21:46 ` John DiCamillo @ 1995-01-30 22:50 ` John Volan 1995-02-01 14:33 ` Norman H. Cohen 1995-02-01 22:37 ` Maarten Landzaat 0 siblings, 2 replies; 12+ messages in thread From: John Volan @ 1995-01-30 22:50 UTC (permalink / raw) milod@netcom.com (John DiCamillo) writes: >ka@socrates.hr.att.com (Kenneth Almquist) writes: >>swdecato@cs.nps.navy.mil wrote: >>> Many Ada folks have demonstrated how Ada objects are created and deleted. >>> My argument against the Ada style was that I felt that the C++ syntax more >>> accurately modelled the englist language. >> >>I don't know about you, but when I issue a command in English I place the >>verb before the noun, as in "Mow the lawn." This translates naturally to >>the C or Ada code: >> >> mow(lawn); >> >>The C++ alternative, >> >> lawn->mow(); >> >>is backwards. > >Actually, your example is backwards. An imperative in English has >an implicit subject (usually 'you', that is, the person being commanded) >and an explicit object (in this case, 'lawn'). So the Ada code would >be: > > mow(robot, lawn); > >and the C++ would be: > > robot.mow(lawn); > Actually, in the first C++ example, I'd say that the lawn is the *subject* of the command, not the *object*! The trouble here is that, although C++ is deemed to be "object-oriented" -- it implements inheritance, polymorphism, dynamic binding, etc. -- nevertheless, its method-calling syntax is really *subject* oriented! Let me explain: If you want to interpret a C++ member-function call such as lawn->mow(); as an English imperative sentence, you really have to translate it as: "Hey, Mr. Lawn! Go mow yourself! (Uh, no offense. :-) (Oh, by the way, mow yourself in whatever fashion is appropriate for whatever type of lawn you are.)" As whimsical and anthropomorphic as this sounds, I seriously believe that this represents the kind of mindset you need to adopt in order to program effectively in any language that uses this kind of syntax -- e.g., C++, Smalltalk, Eiffel, etc. The fact that this sort of thing sounds so whimsical and counter-intuitive is, in my view, a serious problem, something which I call "Subject/Object Confusion Syndrome." The ironic thing is that this confusion only arises because of a choice of *programming language* syntax, yet, in my experience, it's resulted no end of difficulties for engineers trying to grasp the concepts of object-oriented *design*. Every computer program has responsibilities to perform certain actions and computations with respect to the "objects" in its problem domain. A good object-oriented design will take all the responsibilities that pertain to a given class of real-world objects and encapsulate them into a single, cohesive software module. But in order to render that into a programming language that uses this "subject-oriented" syntax, you have to imagine that the objects *themselves* are responsible for the actions that the computer has to "do" to them. Now, we all know that it's really the *computer* that's going to "do" these things -- in other words, the computer is really the "subject" of our program's imperative commands. However, because of the syntax involved, you have to pretend that it's actually the "objects" that are the "subjects" of these commands. In the example above, we know that we're really telling the computer to invoke the "mow" function, and the "lawn" object is really an implied parameter to this function (passed in through the so-called "this" pointer). This parameter has some special semantics -- its run-time type information is used to dynamically dispatch to the appropriate implementation of "mow" -- but it's still just a parameter. However, because of the syntax of the call, we're left with the impression that it's the lawn that is the subject that is doing the mowing. In my experience, this confusion between "subject" and "object" is the single most difficult conceptual hurdle you have to overcome in order to master the object-oriented paradigm, whenever you work in languages like C++ or Smalltalk. Because of this confusion, it can be difficult at times to decide where a certain responsibility should go. For instance, in deciding which object should have the responsibility to "mow", you have to keep remind yourself that the "lawn" object is not really the "lawn" itself. It's just the "part-of-the-computer-responsible-for-doing- things-to-the-lawn" -- including, perhaps, mowing it. However, it is very easy to fall into the trap of inventing spurious "functional" objects, whose only role is to "do" things to your objects of interest. For instance, it may seem perfectly reasonable to argue that lawns don't mow themselves in the real world. Don't you need someone or something to actually do the job? Like, maybe, some kind of "robot" object: > robot.mow(lawn); This may sound okay at first: A "robot" object is chunk of software that knows how to mow a lawn. When we want a lawn mowed, we'll just tell a "robot" object to do it. But in reality this design is horrible! The premise was that there are different kinds of lawn that have to be mowed in different ways. Does this "robot" object now have to know about all these different lawn types? Does it have to do some kind of switch-statement to discriminate among them? Or do we now need to have different classes of robot, one for each type of lawn? If so, then what's the point of having different lawn classes anyway? They seem to be just passive data now. The object-oriented goal of encapsulating data and processing together seems to have been lost. The answer, of course, is that this this "robot" idea just doesn't work. The "lawn" object itself is *already* the "thing-that-knows- how-to-mow-a-lawn." Contrast this with languages like CLOS or Ada95. They also implement inheritance, polymorphism, and dynamic binding, so they are also deemed "object-oriented." However, there was no attempt to adopt a "subject-oriented" method-invoking syntax. Instead, these languages took the old, tried-and-true, imperative subprogram-invoking syntax, and added whatever semantic enhancements were needed in order to support polymorphic dynamic dispatching. Consider the Ada95 example: Mow (The_Lawn); Assuming that The_Lawn is a class-wide (polymorphic) tagged-type variable, this could be translated into an English imperative sentence as follows: "Computer! Go mow the lawn! (Shades of Star Trek? :-) (Oh, by the way, mow the lawn in whatever fashion is appropriate for whatever class of lawn it is.)" Here, "the lawn" is the *object* of the sentence -- it is the thing to which the action of the sentence is directed. In the corresponding Ada code, "The_Lawn" is the "object" to which the action of the "Mow" procedure is directed. The "subject" perfoming this action is, of course, the computer itself, just as in every other imperative programming statement. In fact, you could view the exclamation "Computer!" as an implicit part of every single line of code. The only difference between this subprogram call and an "ordinary" subprogram call are semantic differences, not syntactic ones. "The_Lawn" is a special, polymorphic, "controlling" parameter. It has a run-time tag that will be used to dynamically dispatch to the appropriate implementation of Mow. IMHO, using this traditional imperative syntax is much easier to grasp than "subject-oriented" syntax. When used for dynamic dispatching, it achieves exactly the same semantics as C++'s member-function call. Yet it's much clearer what's "really" going on. There's no phantom "this" parameter that you have to know about in order to explain things. There's still the issue of object-oriented encapsulation: How do we convey the fact that the "Mow" procedure is just an integral part of a single cohesive idea known as the "Lawn" class? C++ makes it a "member function" of a class type, with the confusing effect of making it look like a structural component of every single instance object of that class. Ada95 uses packaging to do encapsulation: We can devote a package to describe the "Lawn" class, encapsulating within it everything that pertains to lawns, including an object-oriented (tagged) type and its primitive operations: package Lawn is type Object is tagged private; procedure Mow (The_Lawn : in out Lawn.Object); ... other primitive operations ("member functions" in C++) private type Object is tagged record ... -- lawn components ("member data" in C++) end record; end Lawn; So, in actuality, a call to the Mow procedure needs to include the package name as context: Lawn.Mow (The_Lawn); -- assuming The_Lawn is of type Lawn.Object'Class It's clear that this "Mow" procedure is a modular part of package Lawn, which encapsulates the *class* of Lawns. "Mow" is *not* a structural part of The_Lawn *object* that is being passed into it. Don't confuse this dotted notation with C++'s dotted member notation. "Lawn.Mow" doesn't mean that "Lawn" is some kind of subject for the verb "Mow". The "subject" of the command is still the computer. If anything, "Lawn" here could be interpreted as an *adverb* qualifying the verb "Mow". All it's indicating is the *scope* in which the Mow procedure is defined. The closest equivalent to this in C++ is using a *scope operator*: lawn->Lawn::mow(); assuming: class Lawn { public: void mow (); ... other members }; Lawn lawn; >>Not to make too big a deal about this--either order (noun before verb or >>verb before noun) is readable once you get used to it. I doubt that one >>order is inherently "better" than the other. > >Agreed. > >>However, using both orders >>in the same program seems like a bad idea if you are concerned about >>readability. > >Oh, no. Here I must disagree. The two syntaxes (in C++) represent >operations with different properties, so having a single syntax is >potentially confusing. Note: I don't believe that the amount of >confusion in either case is significant, but I am satisfied with the >C++ (and Eiffel, and Smalltalk, and...) syntax. I agree that, looking at things mechanically, syntax doesn't really matter much, because the semantics wind up being the same anyway. But I'd say that choice of syntax in a language can have a tremendous impact on how readily software engineers can internalize good object-oriented design techniques, without getting confused and falling into semantic traps. Sure, if you're a "guru," you can get used to whimsical things like lawns mowing themselves, or employees paying themselves their salaries, or enemy missiles engaging and destroying themselves. But should every object-oriented software engineer have to be a "guru" in order to be an effective designer? Well, that's just some food for thought, I don't really want to start a language war over this. Don't mow me down! :-) -- John Volan -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Shameless_Controversial_Marketing_Slogan_For_Favorite_Language => "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" & "Inheritance, hierarchical name-space, generic templates, type-safety, " & "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " & "multi-threading, distributed systems, real-time, safety-critical ... " & "<< A d a 9 5 : Y o u n a m e i t , i t ' s i n t h e r e >>", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] 1995-01-30 22:50 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] John Volan @ 1995-02-01 14:33 ` Norman H. Cohen [not found] ` <D3DpJu.4nK@swlvx2.msd.ray.com> 1995-02-01 22:37 ` Maarten Landzaat 1 sibling, 1 reply; 12+ messages in thread From: Norman H. Cohen @ 1995-02-01 14:33 UTC (permalink / raw) In article <D38q48.3yM@swlvx2.msd.ray.com>, jgv@swl.msd.ray.com (John Volan) writes: |> Every computer program has responsibilities to perform certain actions |> and computations with respect to the "objects" in its problem domain. |> A good object-oriented design will take all the responsibilities that |> pertain to a given class of real-world objects and encapsulate them |> into a single, cohesive software module. But in order to render that |> into a programming language that uses this "subject-oriented" syntax, |> you have to imagine that the objects *themselves* are responsible for |> the actions that the computer has to "do" to them. Now, we all know |> that it's really the *computer* that's going to "do" these things -- |> in other words, the computer is really the "subject" of our program's |> imperative commands. However, because of the syntax involved, you |> have to pretend that it's actually the "objects" that are the |> "subjects" of these commands. ... |> |> In my experience, this confusion between "subject" and "object" is the |> single most difficult conceptual hurdle you have to overcome in order |> to master the object-oriented paradigm, whenever you work in languages |> like C++ or Smalltalk. Because of this confusion, it can be difficult |> at times to decide where a certain responsibility should go. For instance, |> in deciding which object should have the responsibility to "mow", you |> have to keep remind yourself that the "lawn" object is not really the |> "lawn" itself. It's just the "part-of-the-computer-responsible-for-doing- |> things-to-the-lawn" -- including, perhaps, mowing it. Thanks for an insightful analysis, which goes right to the heart of the dispute between advocates of the object.operation(...) and operation(object,...) notations. While these observations argue against the object.operation(...) notation in C++, they do not apply to a language like Actors, where objects are truly active. Ada tasks are also active objects, and John's discussion explains the indecision I've often had naming entries of Ada tasks. Where John thinks in terms of the "computer" having responsibility to perform certain actions, I think in terms of tasks having those responsibilities (including the environment task that executes the main subprogram of a single-task program); I think of procedure calls as imperatives addressed to a task. But when a rendezvous is to take place so that a sender task can notify a recipient task that some event has taken place, it is not clear whether the entry call should read as an imperative addressed to the calling task-- Recipient.Notify_Of_Event; -- Yo, Sender! Notify Recipient of the event! --or the called task-- Recipient.Note_Event; -- Yo, Recipient! Note that an event has occurred! In John's terms, should the task name in an entry call be the subject or the object? (By the way, I also think the object.operation(...) notation is justifiable for a language like Self, where different standalone objects of the same class can have different methods. Such methods really are members, hardly distinguishable from data members. My objection to the use of this notation in C++ is that it gives the impression that different objects in the class each have their own member functions when in fact they all have the same function. C++ is pretending to support a paradigm that it does not support in earnest, the way Self does.) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <D3DpJu.4nK@swlvx2.msd.ray.com>]
[parent not found: <D3H7J3.B2x@inmet.camb.inmet.com>]
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <D3H7J3.B2x@inmet.camb.inmet.com> @ 1995-02-06 10:32 ` Robb Nebbe 0 siblings, 0 replies; 12+ messages in thread From: Robb Nebbe @ 1995-02-06 10:32 UTC (permalink / raw) I took comp.lang.c++ off the distribution list. (If they want to read interesting posts they can just read comp.lang.ada :-) In article <D3H7J3.B2x@inmet.camb.inmet.com>, stt@henning.camb.inmet.com (Tucker Taft) writes: |> |> Here is another analogy. In a normal "dispatching" call, the tag |> of the controlling parameters determines how the "order" given by |> the calling task is carried out, but there is no doubt that something |> will happen. In a call on a protected object, not only is the |> interpretation of the call up to the protected object, but whether |> or not the "order" is carried out at all is up to the protected object. This doesn't seem quite right. A protected object has no say about which calls will be executed. It can enforce that it be in a certain state for a call to take place but this is really no more than a temporal pre-condition. In contrast a task must explicity accept a call on an entry and has complete control over such things as the order in which calls are accepted. A task may also perform actions that are not requested by someone else, a protected object may not. I think this is a case where the syntax better represents the implementation than the semantics. However, I do appreciate that protected subprograms requiring multiple synchronizations are probably not "primitve" and is a good enough justification of why the current syntax was adopted. |> |> Kind of like telling a direct underling to do something, versus |> "asking" a peer to do something ;-). "Sorry I'm busy now" is a legitimate |> answer in the latter case... |> With the cooperative synchronization that exists between tasks this seems right. I see the competetive synchronization involved with protected objects as arbitrating the possesion of the object. Thus multiple peers are competing for the right to tell the protected object what to do. In John's terminology a protected object can never be a subject. Robb Nebbe ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <3gu21g$ch@portal.gmu.edu>]
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <3gu21g$ch@portal.gmu.edu> @ 1995-02-06 14:01 ` John Volan 0 siblings, 0 replies; 12+ messages in thread From: John Volan @ 1995-02-06 14:01 UTC (permalink / raw) bsanden@isse.gmu.edu (Bo I. Sanden) writes: >For anyone interested in the subject-object relationship especially >w.r.t. Ada tasking, I respectfully submit that I took exactly that >tack (including the term "subject") in my book, "Software Systems >Construction with Examples in Ada" (Prentice-Hall 1994). Interesting ... I honestly haven't run across your book (yet), else I certainly would have credited you with coining the term for this, er, subject. :-) >Bo Sanden >George Mason University >Fairfax, Virginia -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] 1995-01-30 22:50 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] John Volan 1995-02-01 14:33 ` Norman H. Cohen @ 1995-02-01 22:37 ` Maarten Landzaat [not found] ` <3h1ahp$gf5@gnat.cs.nyu.edu> 1 sibling, 1 reply; 12+ messages in thread From: Maarten Landzaat @ 1995-02-01 22:37 UTC (permalink / raw) John Volan writes: >... excellent stuff on why syntactic sugar IS important. Not many people seem to share this interest in the influence of syntax on design, readability and other important things. When I was learning computer science on the university, I always wondered why I had to say things like Show(Window, 33, 45, over_there, graph); While I could already envision that Show my graph in a standard window at position (33,45). wouldn't be too hard for a computer to translate, especially if I had told him before that Show (object) (how) at position (x,y) was about to show up somewhere in the program. I thought that this was a wonderful idea, but no-one seemed to see the big difference between the two. Still I think that ease of use and understandability can make the difference. Look at the difference between X400 and internet adresses. Look at the success of PCs after Windows came out, compared to the preceding MSDOS. On the same line: I once mentioned in comp.lang.ada that I found the keyword 'tagged' a very confusing and non-intuitive way of expressing object- orientedness. But nobody seemed to mind. I didn't expect that from people interested in a thoroughly designed language as Ada. On "robot.mow(the_lawn)": To my surprise, many projects I've seen that claim to have object oriented designs, have 'objects' like Process_Messages, Initialization, Sender etc. Terrible! It's OK if designs are like this, but calling them object-oriented is just another way of saying "I don't know what OO is, and I don't know the difference between a procedure and a variable". Just some thoughts... -- Maarten Landzaat (gijs@mbase97.xs4all.nl) Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas. Listen to M-BASE music! ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <3h1ahp$gf5@gnat.cs.nyu.edu>]
[parent not found: <3h3jmp$1h1@Starbase.NeoSoft.COM>]
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <3h3jmp$1h1@Starbase.NeoSoft.COM> @ 1995-02-07 14:39 ` John Volan 1995-02-09 2:25 ` David Weller 0 siblings, 1 reply; 12+ messages in thread From: John Volan @ 1995-02-07 14:39 UTC (permalink / raw) dweller@Starbase.NeoSoft.COM (David Weller) writes: > >In article <3h1ahp$gf5@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >> >>You are indeed confused. Tagged does NOT "express object orientedness". It >>merely says that the type contains a runtime tag allowing type extension and >>polymorphism. >> > >Quite right. Much in the same way that templates in C++ are not >explicitly limited to "generic" situations, considering that >templates are frequently used to implement bounded arrays in a manner >that would make Ada people giggle. Dave, You're clearly making a slam against C++, but it sounds like you're also making a slam against Ada in the same breath. Now, I do agree with you that C++'s approach to arrays is inferior to Ada array types. Although a C++ Array template might imitate Ada's constraint checks, such a template would constitute "user-defined" code and would not be intrinsic to the language. Consequently, I seriously doubt whether there are any C++ compilers that are savvy enough to optimize accesses to an array the way Ada compilers typically do -- *without* breaking the safety that Ada-like arrays provide. For instance, are there C++ compilers out there that can *remove* index-constraint checks when they can be proven unnecessary, yet retain them when they are needed? On the other hand, are you also implying that Ada95 tagged types are in some way inferior as a means of implementing object-oriented designs? If so, what do you mean? -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Subject/Object Confusion Syndrome [was: Ada Objects Help] 1995-02-07 14:39 ` John Volan @ 1995-02-09 2:25 ` David Weller 0 siblings, 0 replies; 12+ messages in thread From: David Weller @ 1995-02-09 2:25 UTC (permalink / raw) In article <D3MwqH.LDL@swlvx2.msd.ray.com>, John Volan <jgv@swl.msd.ray.com> wrote: >dweller@Starbase.NeoSoft.COM (David Weller) writes: >>Quite right. Much in the same way that templates in C++ are not >>explicitly limited to "generic" situations, considering that >>templates are frequently used to implement bounded arrays in a manner >>that would make Ada people giggle. > >the safety that Ada-like arrays provide. For instance, are there C++ >compilers out there that can *remove* index-constraint checks when >they can be proven unnecessary, yet retain them when they are needed? > Hmm, this should be crossposted, but I think CodeCenter does. It's been a while now. You see, I've been "C++ Free" since August, 1994 :-) >On the other hand, are you also implying that Ada95 tagged types are >in some way inferior as a means of implementing object-oriented >designs? If so, what do you mean? > Not quite. What I was saying was that I agreed with Dewar's original comment -- tagged types do _not_ imply they are limited to inheritance. There's some extra goodies you get out of using tagged types that go past things like inheritance (RTTI, for instance). What I was _really_ trying to say is that tagged types exhibit the same philosophical flexibility as templates in C++ (or anything else you'd like to creatively do a #define on :-) -- Frustrated with C, C++, Pascal, Fortran? Ada95 _might_ be for you! For all sorts of interesting Ada95 tidbits, run the command: "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ADA Objects Help! [not found] ` <D330pK.M1@nntpa.cb.att.com> 1995-01-28 21:46 ` John DiCamillo @ 1995-01-29 18:19 ` mat [not found] ` <1995Feb5.180601@hobbit> 1 sibling, 1 reply; 12+ messages in thread From: mat @ 1995-01-29 18:19 UTC (permalink / raw) In article <D330pK.M1@nntpa.cb.att.com>, ka@socrates.hr.att.com (Kenneth Almquist) writes: > swdecato@cs.nps.navy.mil wrote: > I don't know about you, but when I issue a command in English I place the > verb before the noun, as in "Mow the lawn." This translates naturally to > the C or Ada code: > > mow(lawn); > > The C++ alternative, > > lawn->mow(); > > is backwards. > > Not to make too big a deal about this--either order (noun before verb or > verb before noun) is readable once you get used to it. ... When something seems backwards, often it is. What you really mean is lawn->be_thou_mowd(); Now, is this part of the interface provided for a lawn mower to access? -- (This man's opinions are his own.) From mole-end Mark Terribile mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ (Training and consulting in C, C++, UNIX, etc.) ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <1995Feb5.180601@hobbit>]
* Subject/Object Confusion Syndrome [was: Ada Objects Help] [not found] ` <1995Feb5.180601@hobbit> @ 1995-02-07 23:04 ` John Volan 0 siblings, 0 replies; 12+ messages in thread From: John Volan @ 1995-02-07 23:04 UTC (permalink / raw) hathawa2@marshall.edu (Mark S. Hathaway) writes: >There has been some discussion recently on comp.object about the question >of what mechanism should be used to bring together two (2) or more objects >to work with and to affect. I've suggested that in such cases it's always >better to have such a "higher authority" than to allocate to an object a >method which doesn't belong. To have a mow() method in a lawn object seems >absurd to me. Since when does a lawn do anything but grow_crab_grass()? Mark, you've fallen right into one of the prime conceptual traps of the object-oriented paradigm: You've swallowed the fallacy that "object-oriented software models the real world." Despite the all-too-frequent hype you might have heard, object-oriented software does *not* model real-world behavior. Object-oriented software -- like *any* computer software -- is a formalized model of the behavior we want to elicit out of a *computer*. Now, there might be a very compelling *analogy* between objects-in-the-real-world and objects-in-the-computer, but it's still nothing more than an *analogy*. Every analogy eventually breaks down if you push it too far. I would submit that the point where the "real-world" analogy breaks down is precisely when you start trying to deal with behavior. Definition: A software object is an encapsulation of a *computer's* responsibilities *with respect to* some real-world object in its problem domain. A software object encapsulates the computer's responsibilities to know things (data) and to do things (processing) *pertaining to* some real-world object. This knowledge and behavior might bear very little resemblance to the actual knowledge and behavior that the real-world object itself might be endowed with. In general, the purpose of computer software is *not* to mimic what real-world entities do. In fact, the whole point is usually to hold the kind of data and to perform the kind of processing that real-world entities are *not* already capable of doing. Otherwise why bother programming? >The authority which mow()s is not the lawn. Of course lawns don't mow themselves -- in the real world. Of course there's always some "higher authority" or "agent" actually responsible for mowing a given lawn -- in the real world. But if we're talking about the real world, isn't our lawn-mowing *software* a *part* of the "real world"? Isn't the program itself that "higher authority" or "agent" you're seeking? Of course, our hypothetical program is probably responsible for mowing a lot of lawns, and for mowing a lot of different *kinds* of lawns, and for doing a lot of other things to/for/with/about/upon lawns, and for doing things to/for/with/about/upon a lot of other things besides lawns. That's a lot of different responsibilities -- things are getting pretty complex. So it would be beneficial if we could to encapsulate all those responsibilities in a nice compartmentalized way. Let's say we take all the responsibilities that pertain just to one particular lawn of one particular type, and concentrate those responsibilities into one cohesive software entity, distinct from everything else in the system. For simplicity, we might call this entity a "lawn" object -- but never in our wildest dreams do we imagine that it's *really* a lawn. (Last time I looked inside my workstation, I didn't see any sod on the motherboard. :-) No, a "lawn" object is really just a particular chunk of our computing resources that happens to be devoted to managing a lawn. The only reason we don't call it a "lawn manager" or a "lawn controller" is that the role of "managing" or "controlling" is something you can assume about *every* software object. That's what software does: it "manages" or "controls" or at least "keeps track of" things. So it would be kind of redundant to tack on that extra verbiage. It should just be understood. Well ... this assumes that programmers actually *understand* what programming is all about ... >Create another object which >can manipulate the mower and lawn objects. How about... > > class lawn_mowin_fool is > -- states: poverty, drunk, out of control :-) > proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ) is > ... > end mow; > end lawn_mowin_fool; > > spirit lawn_mowin_fool is > proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ); > end lawn_mowin_fool; > > proc lawn_care () is > obj lmf is lawn_mowin_fool; > begin > lmf.mow(MyLawn,SearsSpecial); > end lawn_care; > >This way you can command lmf to mow MyLawn yard_of_grass with a >SearsSpecial lawn_mower. > >Is that decent or what? >It beats the heck out of asking a lawn to mow itself! This is silly. Does our hypothetical program have any responsibilities that pertain to some real-world "lawn-mowing fools"? Are there some real human beings out there that the software is supposed to give orders to, telling them what lawns to mow with what lawn mowers? If so, then I suppose I could understand the need for a "lawn_mowing_fool" class. But if the program itself is supposed to control the lawn mowers *directly*, then inventing a lawn_mowing_fool class is just an unnecessary complication. The computer *itself* is supposed to be the "lawn-mowing fool". Or perhaps we've already had experience with a non-computerized system in which "lawn-mowing fools" -- who sometimes get "drunk" or "out of control" -- are employed to mow lawns. Perhaps we're actually trying to *replace* the "lawn-mowing fools" with software that can do the job better. If that's case, then imitating the behavior of "lawn-mowing fools" in software would be not be "cool" or "decent" -- it would be totally *foolish*. :-) The point of this thread was that when you see a C++ member-function call like: theFrontLawn.mowWith(theSearsSpecialMower); or a Smalltalk method call like: theFrontLawn mowWith: theSearsSpecialMower. you should never feel complled to imagine this as meaning "the front lawn will mow itself using the Sears Special lawn mower". Unfortunately, the syntax seems to encourage this kind of interpretation, and a lot of people even *advocate* this kind of thinking as being "cool". However, I (today) believe this is a silly way of interpreting what object-oriented software does. Instead, I'd read this kind of call as meaning "the part of the computer devoted to the front lawn will mow it (the front lawn) using the Sears Special lawn mower." You always have to keep in mind that "theFrontLawn" is just a chunk of *software* responsible for the front lawn -- and I think "mowing the lawn" should be an integral part of its responsibilities, not something off-loaded to another object. The equivalent call in Ada95 might be something like: Lawns.Mow (The_Lawn => The_Front_Lawn, With_Mower => The_Sears_Special_Mower); (assuming "Lawns" is a package containing a tagged type "Lawn" with a primitive procedure "Mow"). With this syntax, I'd wager you'd be much less likely to view "The_Front_Lawn" as somehow "mowing itself". Yet this Ada subprogram-call might have exactly the same dynamic- dispatching semantics as the C++ member function call or the Smalltalk method invocation above. That is, "The_Front_Lawn" might be a special "controlling" parameter, whose run-time type information ("tag" in Ada95 jargon) would determine which overloaded implementation of "Mow" to dispatch to. >Mark S. Hathaway <hathawa2@marshall.edu> -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Shameless_Controversial_Marketing_Slogan_For_Favorite_Language => "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" & "Inheritance, hierarchical name-space, generic templates, type-safety, " & "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " & "multi-threading, distributed systems, real-time, safety-critical ... " & "<< A d a 9 5 : Y o u n a m e i t , i t ' s i n t h e r e >>", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1995-02-10 15:19 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3gtai2$3mq@horus.mch.sni.de> [not found] ` <3gudf1$ia1@network.ucsd.edu> [not found] ` <132301@cup.portal.com> 1995-02-06 15:37 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] Fergus Henderson 1995-02-07 14:43 ` John Volan 1995-02-09 20:58 ` Mike Bates [not found] ` <9503802.3538@mulga.cs.mu.oz.au> 1995-02-10 15:19 ` Jules [not found] <3f9g1u$j4m@nps.navy.mil> 1995-01-22 18:06 ` ADA Objects Help! Robert Dewar 1995-01-24 22:18 ` Norman H. Cohen 1995-01-25 1:26 ` swdecato [not found] ` <D330pK.M1@nntpa.cb.att.com> 1995-01-28 21:46 ` John DiCamillo 1995-01-30 22:50 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] John Volan 1995-02-01 14:33 ` Norman H. Cohen [not found] ` <D3DpJu.4nK@swlvx2.msd.ray.com> [not found] ` <D3H7J3.B2x@inmet.camb.inmet.com> 1995-02-06 10:32 ` Robb Nebbe [not found] ` <3gu21g$ch@portal.gmu.edu> 1995-02-06 14:01 ` John Volan 1995-02-01 22:37 ` Maarten Landzaat [not found] ` <3h1ahp$gf5@gnat.cs.nyu.edu> [not found] ` <3h3jmp$1h1@Starbase.NeoSoft.COM> 1995-02-07 14:39 ` John Volan 1995-02-09 2:25 ` David Weller 1995-01-29 18:19 ` ADA Objects Help! mat [not found] ` <1995Feb5.180601@hobbit> 1995-02-07 23:04 ` Subject/Object Confusion Syndrome [was: Ada Objects Help] John Volan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox