* friend classes in ada95 @ 2000-04-14 0:00 Stefan Folkesson 2000-04-14 0:00 ` Florian Weimer ` (4 more replies) 0 siblings, 5 replies; 91+ messages in thread From: Stefan Folkesson @ 2000-04-14 0:00 UTC (permalink / raw) In ADA95, is there a way to make the private part of one class accessable from another (see friend classes in C++)? The reason I wonder this is because I want to apply the 'Iterator Pattern' in my design. This demands that the Iterator object can access the attributes of the Aggregate object. Is this possible? Is there a pragma to supress the access check or do I have to declare the attributes of the Aggregate class in the public part of the specification. /Stefan ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 friend classes in ada95 Stefan Folkesson @ 2000-04-14 0:00 ` Florian Weimer 2000-04-14 0:00 ` Stefan Folkesson 2000-04-14 0:00 ` swhalen ` (3 subsequent siblings) 4 siblings, 1 reply; 91+ messages in thread From: Florian Weimer @ 2000-04-14 0:00 UTC (permalink / raw) Stefan Folkesson <stefan.folkesson@emw.ericsson.se> writes: > The reason I wonder this is because I want to apply the 'Iterator > Pattern' in my design. This demands that the Iterator object can access > the attributes of the Aggregate object. Can you declare Aggregate and Iterator in the same package? ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 ` Florian Weimer @ 2000-04-14 0:00 ` Stefan Folkesson 0 siblings, 0 replies; 91+ messages in thread From: Stefan Folkesson @ 2000-04-14 0:00 UTC (permalink / raw) Yes, this is what I've done so far, but I'd rather like to separate the different classes logically in the file structure (1 class <==> 1 file). I do not want to mix the operations for two objects in the same package. Another approach I have considered is to let the Iterator package be a child package to Aggregate (the Iterator type does not inherit from the Aggregate type) package Aggregate is type T_Aggregate is private; private . . . end Aggregate; package Aggregate.Iterator is type T_Iterator is private; private . . . end Aggregate.Iterator; This would work, I think, but I want to consider other alternatives if there are any. /Stefan ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 friend classes in ada95 Stefan Folkesson 2000-04-14 0:00 ` Florian Weimer @ 2000-04-14 0:00 ` swhalen 2000-04-14 0:00 ` Julian Day ` (2 subsequent siblings) 4 siblings, 0 replies; 91+ messages in thread From: swhalen @ 2000-04-14 0:00 UTC (permalink / raw) Mathew Heaney has worked through many of the Patterns in Ada95 over in the ACM Patterns Archive. His "Iterator and Factory combined" is at http://www.acm.org/archives/wa.cgi?A2=ind9811&L=patterns&F=&S=&P=100 Steve -- {===--------------------------------------------------------------===} Steve Whalen swhalen@netcom.com {===--------------------------------------------------------------===} ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 friend classes in ada95 Stefan Folkesson 2000-04-14 0:00 ` Florian Weimer 2000-04-14 0:00 ` swhalen @ 2000-04-14 0:00 ` Julian Day 2000-04-14 0:00 ` Steve Folly 2000-04-14 0:00 ` John J. Rusnak 2000-04-15 0:00 ` Jeff Carter 4 siblings, 1 reply; 91+ messages in thread From: Julian Day @ 2000-04-14 0:00 UTC (permalink / raw) Stefan Folkesson wrote: > In ADA95, is there a way to make the private part of one class > accessable from another (see friend classes in C++)? > The technique to use is a hierarchical package structure. package X is ... private ... end X; package X.Y is -- Cannot see X's private part private -- Can see X's private part end X.Y; package body X.Y is -- Can see X's private part end X.Y; > > The reason I wonder this is because I want to apply the 'Iterator > Pattern' in my design. This demands that the Iterator object can access > the attributes of the Aggregate object. > Ah, maybe what you really want is the Iterator procedure in your ADT to be generic, like this: generic with Do_Something ( Item : in out Item_Type); proceudre Iterator (ADT : in out ADT_Type); Then you can just instantiate it in your client with what ever procedure you want... > > Is this possible? Is there a pragma to supress the access check or do I > have to declare the attributes of the Aggregate class in the public part > of the specification. Please don't go down that road. HTH, Julian > > > > /Stefan > ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 ` Julian Day @ 2000-04-14 0:00 ` Steve Folly 2000-04-14 0:00 ` Robert A Duff 0 siblings, 1 reply; 91+ messages in thread From: Steve Folly @ 2000-04-14 0:00 UTC (permalink / raw) "Julian Day" <julianday@geocities.com> wrote in message news:38F6D9F0.F0DE08E4@geocities.com... > Stefan Folkesson wrote: > > > In ADA95, is there a way to make the private part of one class > > accessable from another (see friend classes in C++)? > > > > The technique to use is a hierarchical package structure. > > package X is > ... > private > ... > end X; > > package X.Y is > -- Cannot see X's private part Not true - according to the LRM (I forget which section off the top of my head) child package visibility rules are the same as if you had declared (in this case) Y inside X at the end of it's private part after all other declarations. > private > -- Can see X's private part > end X.Y; > > package body X.Y is > -- Can see X's private part > end X.Y; > <cut the rest> -- Regards, Steve Folly. http://www.spfweb.co.uk/ donationsto:myaccount@mybank.co.uk mailto:steve.folly@mail.com ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 ` Steve Folly @ 2000-04-14 0:00 ` Robert A Duff 2000-04-17 0:00 ` John J. Rusnak 2000-04-18 0:00 ` Steve Folly 0 siblings, 2 replies; 91+ messages in thread From: Robert A Duff @ 2000-04-14 0:00 UTC (permalink / raw) "Steve Folly" <steve.folly@mail.com> writes: > > package X.Y is > > -- Cannot see X's private part > > Not true - according to the LRM (I forget which section off the top of my > head) child package visibility rules are the same as if you had declared (in > this case) Y inside X at the end of it's private part after all other > declarations. If you look up that section, you'll have trouble finding it. ;-) The visible part of a child cannot see the parent's private part, unless it's a private child. - Bob ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 ` Robert A Duff @ 2000-04-17 0:00 ` John J. Rusnak 2000-04-18 0:00 ` Vincent Marciante 2000-04-18 0:00 ` Steve Folly 1 sibling, 1 reply; 91+ messages in thread From: John J. Rusnak @ 2000-04-17 0:00 UTC (permalink / raw) Robert A Duff wrote: > "Steve Folly" <steve.folly@mail.com> writes: > > > > package X.Y is > > > -- Cannot see X's private part > > > > Not true - according to the LRM (I forget which section off the top of my > > head) child package visibility rules are the same as if you had declared (in > > this case) Y inside X at the end of it's private part after all other > > declarations. > > If you look up that section, you'll have trouble finding it. ;-) > > The visible part of a child cannot see the parent's private part, > unless it's a private child. > > - Bob Under GNAT, I have made use of the fact that a child package can see its parent's private part even if it is NOT a private child. This could just be an error in the compiler, though. (I have seen this technique used for implementing something simliar to "protected" elements in C++ or Java as well as friend classes). Does anyone have the section number? -John ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-17 0:00 ` John J. Rusnak @ 2000-04-18 0:00 ` Vincent Marciante 2000-04-18 0:00 ` John Rusnak 0 siblings, 1 reply; 91+ messages in thread From: Vincent Marciante @ 2000-04-18 0:00 UTC (permalink / raw) John J. Rusnak wrote: > > Robert A Duff wrote: <snip> > > If you look up that section, you'll have trouble finding it. ;-) > > > > The visible part of a child cannot see the parent's private part, > > unless it's a private child. > > > > - Bob > > Under GNAT, I have made use of the fact that a child package can see its parent's > private part even if it is NOT a private child. Is the _visible_ (non-private) part of the non-private child seeing the parent's private part? That would be a defect in the compiler. > This could just be an error in > the compiler, though. (I have seen this technique used for implementing > something simliar to "protected" elements in C++ or Java as well as friend > classes). > > Does anyone have the section number? No section says it because it is wrong - that is the joke. Check out http://www.adapower.com/rationale/rat95-p1-2.html#8 > > -John ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Vincent Marciante @ 2000-04-18 0:00 ` John Rusnak 0 siblings, 0 replies; 91+ messages in thread From: John Rusnak @ 2000-04-18 0:00 UTC (permalink / raw) I see! So only the private part of a public child can access the private part of its parent. I guess I never came across a situation where that was necessary. This still represents a way to implement a friend-relationship in Ada, though. Although the public interface to a tagged type in a child package cannot have visiblity into the parent, the implementation defined in the body can. This is usually what I find important on those rare occasions when a "friend" is helpful. -John ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 ` Robert A Duff 2000-04-17 0:00 ` John J. Rusnak @ 2000-04-18 0:00 ` Steve Folly 1 sibling, 0 replies; 91+ messages in thread From: Steve Folly @ 2000-04-18 0:00 UTC (permalink / raw) On Fri, 14 Apr 2000 19:12:45 GMT, Robert A Duff <bobduff@world.std.com> did clatter that keyboard and type: >"Steve Folly" <steve.folly@mail.com> writes: > >> > package X.Y is >> > -- Cannot see X's private part >> >> Not true - according to the LRM (I forget which section off the top of my >> head) child package visibility rules are the same as if you had declared (in >> this case) Y inside X at the end of it's private part after all other >> declarations. > >If you look up that section, you'll have trouble finding it. ;-) > >The visible part of a child cannot see the parent's private part, >unless it's a private child. > >- Bob I stand corrected :-( Steve. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 friend classes in ada95 Stefan Folkesson ` (2 preceding siblings ...) 2000-04-14 0:00 ` Julian Day @ 2000-04-14 0:00 ` John J. Rusnak 2000-04-15 0:00 ` Jeff Carter 4 siblings, 0 replies; 91+ messages in thread From: John J. Rusnak @ 2000-04-14 0:00 UTC (permalink / raw) Stefan Folkesson wrote: > In ADA95, is there a way to make the private part of one class > accessable from another (see friend classes in C++)? > > The reason I wonder this is because I want to apply the 'Iterator > Pattern' in my design. This demands that the Iterator object can access > the attributes of the Aggregate object. > > Is this possible? Is there a pragma to supress the access check or do I > have to declare the attributes of the Aggregate class in the public part > of the specification. > > /Stefan Yes, and no pragma is needed. In fact, a class has no control (that I am aware of) of who its "friends" are. The way to implement a friend relationship is to use a child package. A child package automatically has visibility into the private parts of its parent's spec. The implementation of a friend class through a child package does involve a tighter coupling of the class and its "friend", but this is a good thing. One should only implement a friend relationship if there is a strong need (and a need for strong coupling between the classes). -John ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-14 0:00 friend classes in ada95 Stefan Folkesson ` (3 preceding siblings ...) 2000-04-14 0:00 ` John J. Rusnak @ 2000-04-15 0:00 ` Jeff Carter 2000-04-16 0:00 ` Robert Dewar 4 siblings, 1 reply; 91+ messages in thread From: Jeff Carter @ 2000-04-15 0:00 UTC (permalink / raw) Stefan Folkesson wrote: > > In ADA95, is there a way to make the private part of one class > accessable from another (see friend classes in C++)? From ARM N.6: Class. A class is a set of types that is closed under derivation, which means that if a given type is in the class, then all types derived from that type are also in the class. The set of types of a class share common properties, such as their primitive operations. Therefore, classes do not have private parts. Packages, protected types, and task types have private parts. Others have answered the intent of your question ([private] child packages). I would just like to say that if you try to write C++ in Ada you will find it as ugly and difficult as trying to write Ada in C++. In C++, the class construct provides for type definition and extension, encapsulation, and information hiding. In Ada, packages provide for modularity, encapsulation, and information hiding, while the type system provides for type definition and extension. > Is this possible? Is there a pragma to supress the access check or do In general, unless you are doing something very low level, if you are considering suppressing or bypassing the language checks then you are going about something the wrong way. -- Jeff Carter "You tiny-brained wipers of other people's bottoms!" Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-15 0:00 ` Jeff Carter @ 2000-04-16 0:00 ` Robert Dewar 2000-04-16 0:00 ` Jeff Carter ` (3 more replies) 0 siblings, 4 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-16 0:00 UTC (permalink / raw) In article <38F887AE.8CDA24E0@acm.org>, jrcarter@acm.org wrote: > Stefan Folkesson wrote: > > > > In ADA95, is there a way to make the private part of one class > > accessable from another (see friend classes in C++)? > > From ARM N.6: > > Class. A class is a set of types that is closed under > derivation, which means that if a given type is in the class, > then all types derived from that type are also in the class. > The set of types of a class share common properties, such as > their primitive operations. Some interesting Ada history, probably not known to many readers of this list, since it's quite a while ago now :-) It's always a hard sell when you choose terminology that is arbitrarily different from the cultural norm. It is interesting to recall the big debate at the Salem meeting between Tucker Taft and Jean Ichibiah. Jean argued that Ada 95 would be far more accessible to the object oriented cognoscenti if it was willing to embrace the term class more enthusiastically, and he suggested that type x is tagged record .... be replaced by class type x is record .... The distinguished reviewers had previously voted overwhelmingly approving the idea that the term class should appear in the declaration, although there was somewhat less enthusiasm for the prefix notation (although of course it is quite consistent with the notation used for task types and protected types). Tucker argued strongly (one almost might say frantically :-) that this was a bad idea, since class meant something different in Ada 95. The national delegations at Salem were all a bit appalled by the ferocity of the argument on both sides, and in particular at what was clearly a huge amount of effort the design team had spent in preparing the counter argument. The vote was even, with several countries abstaining, including the US. The US abstention reflected substantial disagreement in the US delegation (I can't rememeber everyone's individual positions, and indeed it would not be appropriate for me to divulge them in any case, but I can say I strongly supported the use of the term CLASS in this context, and not suprisingly Tucker strongly opposed it). The US delegation decided in advance that it would support the winning side. When the vote was tied, I got up and said: "Since it would take a majority decision to undo a previous decision, this means that the motion (to change to using class) fails, and the US delegation therefore changes its vote to opposed." I knew perfectly well at the time that if I had instead said "I really think we cannot have an important issue like this left open with an even vote, I propose that we discuss this further and revote, that then most likely CLASS would have been approved." But I worried about the dynamics. For whatever reason it was clear that the Ada 95 design team was truly ferociously opposed (in fact it reminded me of Jean's opposition to the unanimous recommendation of the Ada 83 DR's for removing derived types from Ada 83). Jean's motion was rejected partly because he insisted on the prefix notation. Indeed the Japanese delegation voted against it solely on this basis, and I think if they had realized that tactically their negative vote would sink the whole proposal, they would have reconsidered. Even if they had abstained, then the motion would have carried (by a majority of 2 countries, since the US would then have voted FOR the motion.) I tried before the discussion to get Jean to separate the two points, but he refused. I knew that was a tactical error, based on previous discussions in the DR group, but he was adamant. Personally I prefer the prefix notation, but I knew others were quite opposed to it. The history at that point is that Jean was so fed up with what he felt was a significantly bad decision that would affect acceptance of Ada 95 that he gave up on participation in the design effort. All water under the bridge of course, but everytime I see the kind of confusion that this decision causes among OO folks seeing Ada for the first time, I wonder whether the DR's who voted in favor of putting CLASS into the declaration and doing away with TAGGED might have been right. I think Jean was wrong in his fear that this "mistake" would cause major disaffectation with Ada 95, and I think that history has shown that this was not the case, but still the odd word TAGGED still does cause a lot of raised eyebrows for people coming to the language for the first time. There are many other intersting stories in the Ada 95 design process, but the Salem vote on class was probably the high point in drama :-) If any of the other participants wish to add details, or correct me if they think I got any details wrong, feel free (it's quite a while ago and perhaps I have forgotten some details). Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` Robert Dewar @ 2000-04-16 0:00 ` Jeff Carter 2000-04-16 0:00 ` David Botton 2000-04-16 0:00 ` David Botton ` (2 subsequent siblings) 3 siblings, 1 reply; 91+ messages in thread From: Jeff Carter @ 2000-04-16 0:00 UTC (permalink / raw) Robert Dewar wrote: [discussion of the debate and vote on "class" v "tagged" deleted] > There are many other intersting stories in the Ada 95 design > process, but the Salem vote on class was probably the high > point in drama :-) Personally I find this kind of history interesting. All I saw at the time was Ichbiah's article on "Ada with null", which did not help me understand very well his objections that lead to his leaving the revision process entirely. Too bad there isn't a web site with all this history that weirdoes like me could read. -- Jeff Carter "Perfidious English mouse-dropping hoarders." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` Jeff Carter @ 2000-04-16 0:00 ` David Botton 2000-04-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 91+ messages in thread From: David Botton @ 2000-04-16 0:00 UTC (permalink / raw) Most of the time when articles of this nature are posted and I ask for permission to put them up on AdaPower, I get negative responces. Even though I feel that it is important to understand these points and other points of history to be a supportive member of the Ada community who came after the 83 and 95 process has long since past, I can respect that many people take issues to heart and putting them on a web page only serves to resurface hard feelings. David Botton Jeff Carter wrote in message <38F9F4E5.10C13CAD@acm.org>... >Too bad there isn't a web site with all this history that weirdoes like >me could read. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` David Botton @ 2000-04-17 0:00 ` Robert Dewar 2000-04-17 0:00 ` Hyman Rosen 0 siblings, 1 reply; 91+ messages in thread From: Robert Dewar @ 2000-04-17 0:00 UTC (permalink / raw) In article <rBnK4.4959$I75.3624892@news-east.usenetserver.com>, "David Botton" <David@Botton.com> wrote: > Most of the time when articles of this nature are posted and I ask for > permission to put them up on AdaPower, I get negative responces. Even though > I feel that it is important to understand these points and other points of > history to be a supportive member of the Ada community who came after the 83 > and 95 process has long since past, I can respect that many people take > issues to heart and putting them on a web page only serves to resurface hard > feelings. > > David Botton > It is not just that, it is that copyrighted articles posted to newsgroups (yes, they are all copyrighted by default, that's the way the copyright law works) are often informal opinions and descriptions, not edited or checked, and not suitable for republication. In the context of an original usenet discussion they are taken in context, but when republished in another forum, they can take on the unwelcome appearence of carefully thought out articles, or statements of fact :-) Note that posting an article on a newsgroup can never be taken as implicit permission to republish in any other context. To do so is a clear violation of the copyright law. Of course, David is always very careful to ask for permission, and he takes great care to make sure that adapower has only articles which can be appropriately republished, but it does not surprise me that many people are reluctant to see their informal off-the-cuff posts to threads be elevated to the status of permanently-preservable articles :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-17 0:00 ` Robert Dewar @ 2000-04-17 0:00 ` Hyman Rosen 2000-04-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 91+ messages in thread From: Hyman Rosen @ 2000-04-17 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > it does not surprise me that many people are reluctant to see their > informal off-the-cuff posts to threads be elevated to the status of > permanently-preservable articles Considering that you post from deja.com, I'm surprised that you didn't add that such reluctance is entirely futile. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-17 0:00 ` Hyman Rosen @ 2000-04-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-17 0:00 UTC (permalink / raw) In article <t766tgsjeq.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> wrote: > Robert Dewar <robert_dewar@my-deja.com> writes: > > it does not surprise me that many people are reluctant to see their > > informal off-the-cuff posts to threads be elevated to the status of > > permanently-preservable articles > > Considering that you post from deja.com, I'm surprised that > you didn't add that such reluctance is entirely futile. Sorry, I don't understand. It is one thing to have the posts preserved as contributions to the newsgroup, but I (and the law) would consider it a violation of my copyright if someone were to publish articles in another context, such as a printed journal. So you misunderstood what I was saying. I think of what I write here as simply newsgroup posts, not journal articles :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` Robert Dewar 2000-04-16 0:00 ` Jeff Carter @ 2000-04-16 0:00 ` David Botton 2000-04-17 0:00 ` Robert Dewar 2000-04-18 0:00 ` Geoff Bull 2000-04-17 0:00 ` Robert I. Eachus 2000-04-19 0:00 ` Alfred Hilscher 3 siblings, 2 replies; 91+ messages in thread From: David Botton @ 2000-04-16 0:00 UTC (permalink / raw) If I had the time I would modify GNAT even if just for my own use to add support for something like: class type X is new Y with interface A, B record new_var : abc; end record; and interface type ABC; procedure A_Func (This : ABC) is abstract; interface type DEF is new ABC; procedure B_Func (This : ABC) is abstract; You could then have vars like: A : ABC'Class := An_X object; type ABC_Pointer is access all ABC'Class; I would have a syntax for OO that was not embarassing to talk about in public and would stop turning purple when confronted by OO people about MI since I have at least interface inheritance _directly_ suported by the language. On Win32 I would implement the interfaces using the same "vtbl" style used by MSVC++ and therefore COM. Perhaps some day...... (Ok, enough day dreaming, I've got to get back to work...) David Botton Robert Dewar wrote in message <8dc8oi$kda$1@nnrp1.deja.com>... > class type x is record .... ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` David Botton @ 2000-04-17 0:00 ` Robert Dewar 2000-04-17 0:00 ` David Botton 2000-04-17 0:00 ` David Botton 2000-04-18 0:00 ` Geoff Bull 1 sibling, 2 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-17 0:00 UTC (permalink / raw) In article <mvnK4.4943$I75.3573293@news-east.usenetserver.com>, "David Botton" <David@Botton.com> wrote: > class type X is new Y with > interface > A, B > record > new_var : abc; > end record; I can't even guess what the intention is here I must admit, this seems completely obscure to me. > I would have a syntax for OO that was not embarassing to talk > about in public and would stop turning purple when confronted > by OO people about MI since I have at least interface > inheritance _directly_ suported by the > language. I find your proposal very confusing, and I perfectly understand interface inheritance. I think you need to properly fill out your proposal and describe it in RM terms so that we can have some chance of understanding what you are talking about. It looks like a real mishmash of ideas to me, but perhaps that's because it is unclear. > On Win32 I would implement the interfaces using the same > "vtbl" style used by MSVC++ and therefore COM. Well tagged types use this *identical* implementation approach so I really can't understand the distinction you are trying to make here. Just to be clear, Jean's proposal was a simple syntactic transformation, completely unrelated (I think :-) to David's sketch here. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-17 0:00 ` Robert Dewar @ 2000-04-17 0:00 ` David Botton 2000-04-17 0:00 ` David Botton 1 sibling, 0 replies; 91+ messages in thread From: David Botton @ 2000-04-17 0:00 UTC (permalink / raw) The relation to Jean's proposal is the use of the prefix class instead of tagged. My additions if I can relate them well enough for some one to understand (and perhaps that person would re-write it in a more formal language that captures the idea, as I am lacking in that department, but always ready to work on it.) are: The interface section : class type X is new Y with interface A, B record new_var : abc; end record; This designates that class type X (aka tagged type X) implements interfaces A and B. It also states that objects of class type X may be cast to objects of type A'Class and B'Class where A and B are (see below) interface types. The interface type: interface type A; or interface type A is new F; This designates an abstract tagged type used to define the subprograms for the interface. David Botton Robert Dewar <robert_dewar@my-deja.com> wrote in message news:8df6fb$mm3$1@nnrp1.deja.com... > I find your proposal very confusing, and I perfectly understand > interface inheritance. I think you need to properly fill out > your proposal and describe it in RM terms so that we can have > some chance of understanding what you are talking about. > > It looks like a real mishmash of ideas to me, but perhaps that's > because it is unclear. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-17 0:00 ` Robert Dewar 2000-04-17 0:00 ` David Botton @ 2000-04-17 0:00 ` David Botton 2000-04-18 0:00 ` friend classes in ada95 (long) tmoran 1 sibling, 1 reply; 91+ messages in thread From: David Botton @ 2000-04-17 0:00 UTC (permalink / raw) The format / approach of the tagged type doesn't matter to me. It is the interfaces format that matters. What I would like to do would look something like this in today's Ada with a twist: -- Interface IUnknown type IUnknown is abstract tagged null record; -- I like the prefix idea so I would use: interface type IUnknown; type PUnknown is access all IUnknown; function QueryInterface (This : IUnknown, etc ...) return Interfaces.C.long is abstract; pragma Convention (C, QueryInterface); function AddRef (This : IUnknown) return Interfaces.C.unsigned is abstract; pragma Convention (C, AddRef); function Release (This : IUnknown) return Interfaces.C.unsigned is abstract; pragma Convention (C, Release); -- Interface IBeep type IBeep is new abstract IUnknown with null record; -- I want to be able to extend interface definitions so I need something that does this -- I would put here: interface type IBeep is new IUnknown; type PBeep is access all IBeep; function Beep (This : IBeep) return Interfaces.C.unsigned is abstract; pragma Convention (C, Beep); -- Interface IMessage type IMessage is new abstract IUnknown with null record; type PMessage is access all IMessage; function Message (This : IMessage) return Interfaces.C.unsigned is abstract; pragma Convention (C, Beep); type Beep_Class is tagged -- class type Beep_Class is would be so much nicer here. -- Some how designate that Beep_Class implements IBeep and IMessage say with the interface section I mentioned like: -- Interface -- IBeep, IMessage record Ref_Count : Interfaces.C.long; end record; -- Implements IUnknown for both IBeep and IMessage function QueryInterface (This : Beep_Class, etc ...) return Interfaces.C.long; function AddRef (This : Beep_Class) return Interfaces.C.unsigned; function Release (This : Beep_Class) return Interfaces.C.unsigned; -- Implements IBeep function Beep (This : Beep_Class) return Interfaces.C.unsigned; -- Implements IMessage function Message (This : IMessage) return Interfaces.C.unsigned; The I could do: P1 : PUnknown := new Beep_Class; P2 : PMessage := PMessage (P1); P3 : PBeep := PBeep (P1); hr := AddRef (P1); hr := Beep (P2); etc. I would then make P1 guts look like a pointer to: record QueryInterface : System.Address; AddRef : System.Address; Release : System.Address; Object : System.Address; end record; P2 like record QueryInterface : System.Address; AddRef : System.Address; Release : System.Address; Beep : System.Address; Object : System.Address; end record; etc. Or comething like that where I could pass a pointer to a clean table of functions. and still get back to my object when needed. The layout of Beep_Class doesn't matter to me. David Botton Robert Dewar <robert_dewar@my-deja.com> wrote in message news:8df6fb$mm3$1@nnrp1.deja.com... > > On Win32 I would implement the interfaces using the same > > "vtbl" style used by MSVC++ and therefore COM. > > Well tagged types use this *identical* implementation approach > so I really can't understand the distinction you are trying > to make here. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-17 0:00 ` David Botton @ 2000-04-18 0:00 ` tmoran 2000-04-18 0:00 ` David Botton 0 siblings, 1 reply; 91+ messages in thread From: tmoran @ 2000-04-18 0:00 UTC (permalink / raw) > -- Interface IUnknown > ... How about making a hidden MSWindows COM object to serve as the nucleus of a higher level Ada object instead of adding syntax to tell the Ada compiler to create today's low level MS Windows binary to access COM objects. with Interfaces.C; package COM_Stuff is end COM_Stuff; private package COM_Stuff.Types is type Reference_Count_Type is new Interfaces.C.Unsigned; type HResult is new Interfaces.C.Long; end COM_Stuff.Types; with COM_Stuff.Types; use COM_Stuff.Types; private package COM_Stuff.IUnknown_Interface is type IUnknown is abstract tagged null record; type Interface_Pointer is access IUnknown'class; function QueryInterface (This : IUnknown; RIID : Integer; ppvObject: access Interface_Pointer) return HResult is abstract; function AddRef (This : IUnknown) return Reference_Count_Type is abstract; function Release (This : IUnknown) return Reference_Count_Type is abstract; end COM_Stuff.IUnknown_Interface; with COM_Stuff.Types, COM_Stuff.IUnknown_Interface; use COM_Stuff.Types; private package COM_Stuff.IBeep_Interface is type IBeep is abstract new COM_Stuff.IUnknown_Interface.IUnknown with null record; function Beep (This : IBeep) return HResult is abstract; end COM_Stuff.IBeep_Interface; with COM_Stuff.Types, COM_Stuff.IUnknown_Interface; use COM_Stuff.Types; private package COM_Stuff.IMessage_Interface is type IMessage is abstract new COM_Stuff.IUnknown_Interface.IUnknown with null record; function Message (This : IMessage) return HResult is abstract; end COM_Stuff.IMessage_Interface; with COM_Stuff.Types, COM_Stuff.IUnknown_Interface, COM_Stuff.IBeep_Interface, COM_Stuff.IMessage_Interface; use COM_Stuff.Types; private package COM_Stuff.Beeper is type Beep_Interface_Part is new COM_Stuff.IBeep_Interface.IBeep with null record; function QueryInterface (This : Beep_Interface_Part; RIID : Integer; ppvObject: access Interface_Pointer) return HResult; function AddRef (This : Beep_Interface_Part) return Reference_Count_Type; function Release (This : Beep_Interface_Part) return Reference_Count_Type; function Beep (This : Beep_Interface_Part) return HResult; type Message_Interface_Part is new IMessage_Interface.IMessage with null record; function QueryInterface (This : Message_Interface_Part; RIID : Integer; ppvObject: access Interface_Pointer) return HResult; function AddRef (This : Message_Interface_Part) return Reference_Count_Type; function Release (This : Message_Interface_Part) return Reference_Count_Type; function Message (This : Message_Interface_Part) return HResult is abstract; type Beeper_Type is new COM_Stuff.IUnknown_Interface.IUnknown with record Beeper : aliased Beep_Interface_Part; Message: aliased Message_Interface_Part; Ref_Count : Reference_Count_Type := 0; end record; function QueryInterface (This : Beeper_Type; RIID : Integer; ppvObject: access Interface_Pointer) return HResult; function AddRef (This : Beeper_Type) return Reference_Count_Type; function Release (This : Beeper_Type) return Reference_Count_Type; end COM_Stuff.Beeper; -- package body COM_Stuff.Beeper; -- TBD ---------- All the above to aid implementation of the Ada style: with Ada.Finalization; package COM_Stuff.Public_Beeper is type Beeper_Type is new Ada.Finalization.Limited_Controlled with private; procedure Beep(This : in out Beeper_Type); procedure Message(This : in out Beeper_Type); private type Beeper_Type is new Ada.Finalization.Limited_Controlled with null record; -- encapsulate and hide the stuff to Create/Reference count/Destroy -- and handle thread safety for COM_Stuff.Beeper.Beeper_Type procedure Initialize(This : in out Beeper_Type); procedure Finalize(This : in out Beeper_Type); end COM_Stuff.Public_Beeper; -- allowing the programmer using this to write things like: with COM_Stuff.Public_Beeper; procedure Main is begin if 2+2 = 4 then declare use COM_Stuff.Public_Beeper; Beeper : Beeper_Type; begin Beep(Beeper); Message(Beeper); end; end if; end Main; ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-18 0:00 ` friend classes in ada95 (long) tmoran @ 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` friend classes in ada95 Stanley R. Allen ` (2 more replies) 0 siblings, 3 replies; 91+ messages in thread From: David Botton @ 2000-04-18 0:00 UTC (permalink / raw) GNATCOM already does that very well and its tools build all the code for you from start finish, you just have to fill in the bodies for the COM objects. As for using the COM objects you run BindCOM or use the dynamic interface, and wiz bang you are on your way. What I am looking to do is introduce interface MI in to Ada syntax. And if I am already going to implement it, I might as well do it in a way that would make it easier to write a COM object in raw Ada. I would still never suggest any one try and write COM objects with out a framework like GNATCOM, much as most people would never write COM objects in C++ with out ATL or MFC. Of course, I can already do interface MI in Ada already, so this is really just about syntax. I am not happy that Ada comes out looking bad in OO circles, since most people can not bridge the gap from "class X" to "type X is tagged", even though there is none. David Botton <tmoran@bix.com> wrote in message news:TSSK4.73$vE6.38666@news.pacbell.net... > > -- Interface IUnknown > > ... > > How about making a hidden MSWindows COM object to serve as the nucleus > of a higher level Ada object instead of adding syntax to tell the > Ada compiler to create today's low level MS Windows binary to > access COM objects. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` David Botton @ 2000-04-18 0:00 ` Stanley R. Allen 2000-04-19 0:00 ` friend classes in ada95 (long) Brian Rogoff 2000-04-19 0:00 ` MI, was Re: friend classes in ada95 tmoran 2 siblings, 0 replies; 91+ messages in thread From: Stanley R. Allen @ 2000-04-18 0:00 UTC (permalink / raw) David Botton wrote: > > Of course, I can already do interface MI in Ada already, so this is really > just about syntax. I am not happy that Ada comes out looking bad in OO > circles, since most people can not bridge the gap from "class X" to "type X > is tagged", even though there is none. > If they can't bridge this gap, it may be because prejudice is in the way. If that's not the problem, then the barrier may be that they are attempting to make a direct leap from the C++ (or Java) model to Ada 95. It's a common mistake C++ people make when learning Java, and we've seen more than a few questions here on c.l.a reflecting that kind of confusion. I like the approach N. Cohen uses in the second edition of "Ada as a Second Language" to present the topic -- building up a complete picture of the Ada model based on a discussion of derived types, leaving comparisons to other languages until the end. -- Stanley Allen mailto:Stanley_R_Allen-NR@raytheon.com P.S. I'm still waiting for a good, thorough book focused on advanced OO programming in Ada 95. The general Ada textbooks are mostly for beginners. The discussions in the Rationale are a good starting point, but obviously every aspect of the topic could not be discussed in the space provided there. Matthew Heaney's patterns articles contain many of the things one would like to see in an "OO techniques for Ada 95" book. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` friend classes in ada95 Stanley R. Allen @ 2000-04-19 0:00 ` Brian Rogoff 2000-04-19 0:00 ` Hyman Rosen 2000-04-19 0:00 ` David Botton 2000-04-19 0:00 ` MI, was Re: friend classes in ada95 tmoran 2 siblings, 2 replies; 91+ messages in thread From: Brian Rogoff @ 2000-04-19 0:00 UTC (permalink / raw) On Tue, 18 Apr 2000, David Botton wrote: > What I am looking to do is introduce interface MI in to Ada syntax. And if I > am already going to implement it, I might as well do it in a way that would > make it easier to write a COM object in raw Ada. I would still never suggest > any one try and write COM objects with out a framework like GNATCOM, much as > most people would never write COM objects in C++ with out ATL or MFC. > > Of course, I can already do interface MI in Ada already, so this is really > just about syntax. Hmmm. I find that interface MI is very clumsy in Ada. Are you saying that you find it as easy in Ada as in Java? Somehow I think I must be misunderstanding you; please give an example of interface MI in Ada. There was some work at grafting interface MI into C++, indeed I believe that GNU C++ may still support the "signature" proposal of Russo and Baumgartner. I thought that stuff was neat, and hope something similar finds its way into the next Ada. Ada already handles implementation MI well enough IMO, with generics and the access discriminant trick. > I am not happy that Ada comes out looking bad in OO > circles, since most people can not bridge the gap from "class X" to "type X > is tagged", even though there is none. I guess I am one of those people who, for the most part, liked the Ada "tagged" keyword and syntax since I first learned it, so this kind of change is uninteresting to me. -- Brian ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-19 0:00 ` friend classes in ada95 (long) Brian Rogoff @ 2000-04-19 0:00 ` Hyman Rosen 2000-04-19 0:00 ` Brian Rogoff 2000-04-19 0:00 ` David Botton 1 sibling, 1 reply; 91+ messages in thread From: Hyman Rosen @ 2000-04-19 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > There was some work at grafting interface MI into C++, indeed I believe > that GNU C++ may still support the "signature" proposal of Russo and > Baumgartner. I thought that stuff was neat, and hope something similar > finds its way into the next Ada. Signatures are being removed from the latest version of GNU C++. There is no need to "graft interface MI" into C++ because C++ fully supports interface MI as it stands. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-19 0:00 ` Hyman Rosen @ 2000-04-19 0:00 ` Brian Rogoff 2000-04-23 0:00 ` Hyman Rosen 0 siblings, 1 reply; 91+ messages in thread From: Brian Rogoff @ 2000-04-19 0:00 UTC (permalink / raw) On 19 Apr 2000, Hyman Rosen wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > There was some work at grafting interface MI into C++, indeed I believe > > that GNU C++ may still support the "signature" proposal of Russo and > > Baumgartner. I thought that stuff was neat, and hope something similar > > finds its way into the next Ada. > > Signatures are being removed from the latest version of GNU C++. > There is no need to "graft interface MI" into C++ because C++ > fully supports interface MI as it stands. I disagree with your assertion. GNU C++ signatures allowed subtyping *independent* of class hierarchy, and even allowed the extraction of a signature from an existing class using a "sigof" operator, something even Java doesn't have. -- Brian ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-19 0:00 ` Brian Rogoff @ 2000-04-23 0:00 ` Hyman Rosen 2000-04-23 0:00 ` Brian Rogoff 0 siblings, 1 reply; 91+ messages in thread From: Hyman Rosen @ 2000-04-23 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > > Signatures are being removed from the latest version of GNU C++. > > There is no need to "graft interface MI" into C++ because C++ > > fully supports interface MI as it stands. > > I disagree with your assertion. GNU C++ signatures allowed subtyping > *independent* of class hierarchy, and even allowed the extraction of > a signature from an existing class using a "sigof" operator, something > even Java doesn't have. Which assertion? Signatures are definitely being removed from GNU C++. This has been proclaimed on the official mailing lists by official maintainers. As to the other, the message to which I responded was talking about Java, so I meant that C++ has interface MI which is the equal of Java (nearly, with an exception I've posted before). It certainly needs no "grafting". ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-23 0:00 ` Hyman Rosen @ 2000-04-23 0:00 ` Brian Rogoff 2000-04-24 0:00 ` Hyman Rosen 0 siblings, 1 reply; 91+ messages in thread From: Brian Rogoff @ 2000-04-23 0:00 UTC (permalink / raw) On 23 Apr 2000, Hyman Rosen wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > > Signatures are being removed from the latest version of GNU C++. > > > There is no need to "graft interface MI" into C++ because C++ > > > fully supports interface MI as it stands. > > > > I disagree with your assertion. GNU C++ signatures allowed subtyping > > *independent* of class hierarchy, and even allowed the extraction of > > a signature from an existing class using a "sigof" operator, something > > even Java doesn't have. > > Which assertion? Signatures are definitely being removed from GNU C++. > This has been proclaimed on the official mailing lists by official > maintainers. Obviously not that one. > As to the other, the message to which I responded was talking > about Java, so I meant that C++ has interface MI which is the equal of > Java (nearly, with an exception I've posted before). The assertion that C++ fully suports MI of interface. Since you were responding to my message about GNU C++ signatures, I foolishly assumed that you were talking about GNU C++ signatures, not Java. Silly me! > It certainly needs no "grafting". It seems that I ruffled your feathers by using that word in the context of your favorite language. Sorry. I actually liked the signature extension of C++. I'd love to see such a feature grafted onto Ada. -- Brian ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-23 0:00 ` Brian Rogoff @ 2000-04-24 0:00 ` Hyman Rosen 2000-04-25 0:00 ` Brian Rogoff 0 siblings, 1 reply; 91+ messages in thread From: Hyman Rosen @ 2000-04-24 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > It seems that I ruffled your feathers by using that word in the context of > your favorite language. Sorry. I actually liked the signature extension of > C++. I'd love to see such a feature grafted onto Ada. Sorry about that. My antennae sometimes get a little hyperextended in c.l.a. But as to signatures, I don't much care for them. It seems to me that they are there to take advantage of accidents in function naming, whereas interfaces are part of a design. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-24 0:00 ` Hyman Rosen @ 2000-04-25 0:00 ` Brian Rogoff 2000-04-25 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 91+ messages in thread From: Brian Rogoff @ 2000-04-25 0:00 UTC (permalink / raw) On 24 Apr 2000, Hyman Rosen wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > It seems that I ruffled your feathers by using that word in the context of > > your favorite language. Sorry. I actually liked the signature extension of > > C++. I'd love to see such a feature grafted onto Ada. > > Sorry about that. My antennae sometimes get a little hyperextended in > c.l.a. You'll probably have to develop a thicker skin, or tougher antennae, because this is com.lang.ada after all. I'm similarly annoyed by the gratuitous C++ slamming, even though I prefer Ada to C++ for most tasks, but that's the nature of comp.lang.* > But as to signatures, I don't much care for them. It seems to > me that they are there to take advantage of accidents in function > naming, whereas interfaces are part of a design. Is that from actual use, or just reading and inference? I don't have any real data myself, I just read about GNU C++ signatures. I did use Sather for a while, which also had a powerful signature-like mechanism that permitted the addition of signatures (types in Sather parlance) above an existing class. This feature was mainly used to define type bounds in generic classes. Since C++ doesn't have constrained parametric polymorphism (yes, I know how to simulate it inelegantly in C++) this isn't as important there. The real revolutionary aspect of standard C++ which I wish Ada would copy is automatic generic/template instantiation. I think the modification to Ada (read "An Ada like language") would be better off omitting the full power of templates to do compile time calculations, and therefore omitting "template metaprogramming", but would still enhance Ada's abilities in a number of interesting ways. -- Brian ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-25 0:00 ` Brian Rogoff @ 2000-04-25 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 91+ messages in thread From: Ole-Hjalmar Kristensen @ 2000-04-25 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > On 24 Apr 2000, Hyman Rosen wrote: > > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > > It seems that I ruffled your feathers by using that word in the context of > > > your favorite language. Sorry. I actually liked the signature extension of > > > C++. I'd love to see such a feature grafted onto Ada. > > > > Sorry about that. My antennae sometimes get a little hyperextended in > > c.l.a. > > You'll probably have to develop a thicker skin, or tougher antennae, > because this is com.lang.ada after all. I'm similarly annoyed by the > gratuitous C++ slamming, even though I prefer Ada to C++ for most tasks, > but that's the nature of comp.lang.* > > > But as to signatures, I don't much care for them. It seems to > > me that they are there to take advantage of accidents in function > > naming, whereas interfaces are part of a design. > > Is that from actual use, or just reading and inference? I don't have any > real data myself, I just read about GNU C++ signatures. I did use Sather > for a while, which also had a powerful signature-like mechanism that > permitted the addition of signatures (types in Sather parlance) above > an existing class. This feature was mainly used to define type bounds in > generic classes. Since C++ doesn't have constrained parametric > polymorphism (yes, I know how to simulate it inelegantly in C++) this > isn't as important there. > > The real revolutionary aspect of standard C++ which I wish Ada would copy > is automatic generic/template instantiation. I think the modification to > Ada (read "An Ada like language") would be better off omitting the full > power of templates to do compile time calculations, and therefore omitting > "template metaprogramming", but would still enhance Ada's abilities in a > number of interesting ways. > > -- Brian > > Yes, I think it's sensible to restrict the power of templates, at least from an implementation view. I've seen so many C++ compilers that either fail to compile, or generate wrong code for complex templates. I still feel I cannot really trust C++ templates. -- E pluribus Unix ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 (long) 2000-04-19 0:00 ` friend classes in ada95 (long) Brian Rogoff 2000-04-19 0:00 ` Hyman Rosen @ 2000-04-19 0:00 ` David Botton 1 sibling, 0 replies; 91+ messages in thread From: David Botton @ 2000-04-19 0:00 UTC (permalink / raw) Brian Rogoff wrote in message ... >Hmmm. I find that interface MI is very clumsy in Ada. Are you saying that >you find it as easy in Ada as in Java? Somehow I think I must be >misunderstanding you; please give an example of interface MI in Ada. It certainly is not as easy, just that it can be done. I was saying that if I had the time I would make a non-standard Ada if need be to make it easier until some one high up there did. With true respect, I am sure that you can create a better example then I. > >There was some work at grafting interface MI into C++, indeed I believe >that GNU C++ may still support the "signature" proposal of Russo and >Baumgartner. I thought that stuff was neat, and hope something similar >finds its way into the next Ada. Exactly what I would love to see happen. >Ada already handles implementation MI well enough IMO, with generics and >the access discriminant trick. Agreed. I try and avoid implementation MI anyways when possible and like the control of roll your own solutions for implementation MI. David Botton ^ permalink raw reply [flat|nested] 91+ messages in thread
* MI, was Re: friend classes in ada95 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` friend classes in ada95 Stanley R. Allen 2000-04-19 0:00 ` friend classes in ada95 (long) Brian Rogoff @ 2000-04-19 0:00 ` tmoran 2000-04-19 0:00 ` David Botton 2 siblings, 1 reply; 91+ messages in thread From: tmoran @ 2000-04-19 0:00 UTC (permalink / raw) > What I am looking to do is introduce interface MI in to Ada syntax. > And if I am already going to implement it, I might as well do it in a > way that would make it easier to write a COM object in raw Ada. I'm confused. It seems you 1) want MI Interfaces; 2) want them in a binary compatible way (at least on Windows) with COM; 3) but "Inheritance and reusability are terms with specific meanins for the developer of object-oriented code. These terms refer to the capability of deriving your own classes from the base classes, replacing methods with customized versions, and adding methods of your own. None of this is available with respect to COM objects." Visual C++ 5 Unleashed, p 510. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: MI, was Re: friend classes in ada95 2000-04-19 0:00 ` MI, was Re: friend classes in ada95 tmoran @ 2000-04-19 0:00 ` David Botton 0 siblings, 0 replies; 91+ messages in thread From: David Botton @ 2000-04-19 0:00 UTC (permalink / raw) I want 1 and if I have 1 on Windows it would be nice if it did 2 so that I could do COM. I want 1 because I want 1, I already have COM with GNATCOM, I don't need 2, but if I get 1 on Windows, it would be nice if it conformed to MSVC++/COM style VTBLs. I need to have some one reread my posts before sending for clarity, I still don't see what is difficult about the above. COM ain't Corba, COM as stated in my first ever COM announcement a year ago is over glorified OO RPC. What I am looking for is direct support of MI Interfaces in Ada, if I don't get 2 then who cares. David Botton tmoran@bix.com wrote in message ... >> What I am looking to do is introduce interface MI in to Ada syntax. >> And if I am already going to implement it, I might as well do it in a >> way that would make it easier to write a COM object in raw Ada. > > I'm confused. It seems you 1) want MI Interfaces; 2) want them in a >binary compatible way (at least on Windows) with COM; 3) but >"Inheritance and reusability are terms with specific meanins for the >developer of object-oriented code. These terms refer to the capability >of deriving your own classes from the base classes, replacing methods >with customized versions, and adding methods of your own. None of this >is available with respect to COM objects." Visual C++ 5 Unleashed, p 510. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` David Botton 2000-04-17 0:00 ` Robert Dewar @ 2000-04-18 0:00 ` Geoff Bull 2000-04-18 0:00 ` Jean-Pierre Rosen 2000-04-18 0:00 ` David Botton 1 sibling, 2 replies; 91+ messages in thread From: Geoff Bull @ 2000-04-18 0:00 UTC (permalink / raw) David Botton wrote: > > If I had the time I would modify GNAT even if just for my own use to add > support for something like: > > class type X is new Y with > interface > A, B > record > new_var : abc; > end record; > > and can this degenerate to (when not implementing an interface): class type X is new Y with record new_var : abc; end record; ? In this case the class keyword is not needed. Also I am worried that you could write class type X is record ... and means exactly the same as type X is tagged record ... I.E. we would have two ways of doing the same thing. Or, if they didn't do the same thing it would become confusing as to when to use "class type" and when to use "type X is tagged" > > interface type ABC; You could also have: type ABC is interface; It seems to me you can probably do this without introducing a new keyword. This is off the top of my head without thinking through, but ... an abstract tagged type with a null record and abstract primitive subprograms looks to me an awful lot like an interface. type ABC is abstract tagged null record; procedure A_Func (This : ABC) is abstract; type DEF is abstract new ABC; procedure B_Func (This : ABC) is abstract; type Y is tagged record ... type X is new X, ABC, DEF with -- maximum of one non "interface" type record ... end record; Ok, the idea of a new keyword is growing on me :-) > I would have a syntax for OO that was not embarassing to talk about in > public What is embarrassing about tagged types? (at least we don't have the C++ rtti mess, or that abstract virtual function syntax) Presumably some people must have argued for compromise syntax: tagged type X is record Cheers Geoff ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Geoff Bull @ 2000-04-18 0:00 ` Jean-Pierre Rosen 2000-04-18 0:00 ` David Botton ` (3 more replies) 2000-04-18 0:00 ` David Botton 1 sibling, 4 replies; 91+ messages in thread From: Jean-Pierre Rosen @ 2000-04-18 0:00 UTC (permalink / raw) Can't resist to provide my 0.02 on the tagged/class issue, or how I present it in my courses. A tagged type is not a class. A tagged type is a programming construct that can be used to build classes. This is what the building block approach is about. A class in the usual OOP sense is a *design pattern*, where you put a tagged type and its associated primitive operations (the methods) in a package specification. Ada allows you to build other design patterns, that have no equivalent in other languages, like putting several tagged types in a single package (a bit like friends, but not exactly similar). -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Jean-Pierre Rosen @ 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` tmoran ` (2 subsequent siblings) 3 siblings, 0 replies; 91+ messages in thread From: David Botton @ 2000-04-18 0:00 UTC (permalink / raw) That is what I like best about Ada's OO :-) David Botton Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote in message news:8dh37m$qef$2@wanadoo.fr... > A tagged type is not a class. A tagged type is a programming construct that > can be used to build classes. This is what the building block approach is > about. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Jean-Pierre Rosen 2000-04-18 0:00 ` David Botton @ 2000-04-18 0:00 ` tmoran 2000-04-18 0:00 ` John J. Rusnak 2000-04-18 0:00 ` John Rusnak 2000-04-18 0:00 ` Pascal Obry 3 siblings, 1 reply; 91+ messages in thread From: tmoran @ 2000-04-18 0:00 UTC (permalink / raw) > A tagged type is not a class. A tagged type is a programming construct When first trying to understand this stuff, I personally found thinking of a tag on a record etc to be much easier to understand than all the OO stuff about classes and objects. "class" and "object" are such vague terms they convey little information. Also they are used for a variety of *different* things (see mathematics, or MS's use of "class" in COM). OTOH, if one's intent is to certify membership in an exclusive club by the use of code words known only to the members, then "class" is as good as anything. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` tmoran @ 2000-04-18 0:00 ` John J. Rusnak 2000-04-19 0:00 ` Geoff Bull ` (2 more replies) 0 siblings, 3 replies; 91+ messages in thread From: John J. Rusnak @ 2000-04-18 0:00 UTC (permalink / raw) I'd have to weigh in on the opposite side. "Class" and "object" are rather easy terms to grasp. And I can tell you through exeperience that the Ada model has been difficult for many I have seen coming into the language to grasp. (Some with OO backgrounds and some without). But to each their own I suppose. I agree with the comment on "code words", though. -John tmoran@bix.com wrote: > > A tagged type is not a class. A tagged type is a programming construct > When first trying to understand this stuff, I personally found thinking > of a tag on a record etc to be much easier to understand than all the > OO stuff about classes and objects. "class" and "object" are such > vague terms they convey little information. Also they are used for > a variety of *different* things (see mathematics, or MS's use of "class" > in COM). OTOH, if one's intent is to certify membership in an > exclusive club by the use of code words known only to the members, > then "class" is as good as anything. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` John J. Rusnak @ 2000-04-19 0:00 ` Geoff Bull 2000-04-19 0:00 ` Robert Dewar ` (3 more replies) 2000-04-19 0:00 ` Jean-Pierre Rosen 2000-04-19 0:00 ` Robert Dewar 2 siblings, 4 replies; 91+ messages in thread From: Geoff Bull @ 2000-04-19 0:00 UTC (permalink / raw) "John J. Rusnak" wrote: > > I'd have to weigh in on the opposite side. "Class" and "object" are rather > easy terms to grasp. And I can tell you through exeperience that the Ada > model has been difficult for many I have seen coming into the language to > grasp. (Some with OO backgrounds and some without). But to each their own > I suppose. > For people coming from other languages, changing the word tagged to class is going to help not zero. The problem they face is overcoming the assumptions they have made about how oo is implemented. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Geoff Bull @ 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Ehud Lamm ` (2 subsequent siblings) 3 siblings, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <38FD1C9E.7C2B7756@research.canon.com.au>, Geoff Bull <geoff@research.canon.com.au> wrote: > For people coming from other languages, changing the word > tagged to class is going to help not zero. one too many negatives here??? :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Geoff Bull 2000-04-19 0:00 ` Robert Dewar @ 2000-04-19 0:00 ` Ehud Lamm 2000-04-19 0:00 ` Jeff Susanj 2000-04-19 0:00 ` David Botton 3 siblings, 0 replies; 91+ messages in thread From: Ehud Lamm @ 2000-04-19 0:00 UTC (permalink / raw) My experience (I guess every teacher has his own views) is that many of those finding Ada OO model difficult simply don't really understand ANY OO model. They understand the "surface structure" (i.e., the syntax) which is naturally different between languages. A minority who is well versed in some other language (C++/Java) can have problems with the the Ada way of doing things, but usually can overcome this pretty easily. I also tend to agree that people seem to understand the Ada way of doing things faster, but than I haven't taught C++ recently - so maybe if *I* teach C++ it will understood better and faster too. Lastly, I think that it is helpful to know that there is more than one way to skin a cat (not to mention that there are so many cats), so being exposed to a language like Ada, with its own unique ways, should be seen as a bonus, not as a problem. obstacle. Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Geoff Bull 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Ehud Lamm @ 2000-04-19 0:00 ` Jeff Susanj 2000-04-19 0:00 ` Bill Greene ` (2 more replies) 2000-04-19 0:00 ` David Botton 3 siblings, 3 replies; 91+ messages in thread From: Jeff Susanj @ 2000-04-19 0:00 UTC (permalink / raw) In OO a class is data and the operations associated with that data. Therefore, Ada doesn't explicitly have classes because the data and the operations are not explicitly bound together. If we consider a class to be the tagged record and all of those operations that have access to the tagged record then viola, there is a class. Jeff S. Geoff Bull wrote in message <38FD1C9E.7C2B7756@research.canon.com.au>... >"John J. Rusnak" wrote: >> >> I'd have to weigh in on the opposite side. "Class" and "object" are rather >> easy terms to grasp. And I can tell you through exeperience that the Ada >> model has been difficult for many I have seen coming into the language to >> grasp. (Some with OO backgrounds and some without). But to each their own >> I suppose. >> >For people coming from other languages, changing the word tagged to class >is going to help not zero. >The problem they face is overcoming the assumptions they have made >about how oo is implemented. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Jeff Susanj @ 2000-04-19 0:00 ` Bill Greene 2000-04-19 0:00 ` tmoran 2000-04-19 0:00 ` Robert Dewar 2 siblings, 0 replies; 91+ messages in thread From: Bill Greene @ 2000-04-19 0:00 UTC (permalink / raw) Jeff Susanj wrote: > > In OO a class is data and the operations associated with that data. > Therefore, Ada doesn't explicitly have classes because the data and the > operations are not explicitly bound together. ... This is the definition of an abstract data type. Ada certainly does support ADTs via the package mechanism. -- William R. Greene 1100 Perimeter Park Drive Ganymede Software, Inc. Suite 104 http://www.ganymede.com Morrisville, NC 27560 USA Phone: (919) 469-0997, ext. 280 Fax: (919) 469-5553 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Jeff Susanj 2000-04-19 0:00 ` Bill Greene @ 2000-04-19 0:00 ` tmoran 2000-04-19 0:00 ` Robert Dewar 2 siblings, 0 replies; 91+ messages in thread From: tmoran @ 2000-04-19 0:00 UTC (permalink / raw) >In OO a class is data and the operations associated with that data. >Therefore, Ada doesn't explicitly have classes because the data and the >operations are not explicitly bound together. "Defined in the same package spec, and the operations take a parameter of the (tagged) type" isn't sufficiently explicitly bound together? >If we consider a class to be the tagged record and all of those >operations that have access to the tagged record then viola, there is a >class. So any user of the tagged record, even if it's an application that merely passes the object as a black box, is part of the class? Or if "access to the tagged record" means "knows about and can access the record's components", then everything in the package body, and, if the tagged record is not "is private", but rather is in the public part of the spec, then any application code, is part of the class? The dictionary definition of a class is a set of things grouped together because of a common trait. What is common to the definition of a data layout, or a data record, and a set of procedures? One is passive data, the other is active code. OTOH, a collection of things all deriving from the same ancestor, and thus sharing certain traits, the Ada usage of "class", clearly fits the dictionary definition. I guess a "proper" OOer would have to say "The class Mammalia, nursing, and live birth, are a class". Obfuscation, IMHO. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Jeff Susanj 2000-04-19 0:00 ` Bill Greene 2000-04-19 0:00 ` tmoran @ 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Jeff Carter 2 siblings, 1 reply; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <Ft9rpt.4AF@news.boeing.com>, "Jeff Susanj" <jeffrey.l.susanj@boeing.com> wrote: > In OO a class is data and the operations associated with that > data. This is a classical definition of an abstract data type, as has been well understood since the early 60's. If you really accept this as a definition of object, then that seems very very confused to me! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Robert Dewar @ 2000-04-19 0:00 ` Jeff Carter 2000-04-19 0:00 ` Ray Blaak 2000-04-20 0:00 ` Robert Dewar 0 siblings, 2 replies; 91+ messages in thread From: Jeff Carter @ 2000-04-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <Ft9rpt.4AF@news.boeing.com>, > "Jeff Susanj" <jeffrey.l.susanj@boeing.com> wrote: > > In OO a class is data and the operations associated with that > > data. > > This is a classical definition of an abstract data type, as > has been well understood since the early 60's. > > If you really accept this as a definition of object, then that > seems very very confused to me! Wirth, in accepting OO for Oberon, said that it's simply ADTs under another name. When I first looked into OO about 1984, once I finally understood what was going on, I didn't find anything new, except that the mechanism used made the code less readable than if composition had been used. I suspected that the OO people made up new terms for well established concepts such as type (class) and subprogram (methods) to mask this lack of original content. I later learned that class came from Simula, but have yet to learn any earlier use of method or message for subprogram or call. -- Jeff Carter "English bed-wetting types." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Jeff Carter @ 2000-04-19 0:00 ` Ray Blaak 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Robert Dewar 1 sibling, 2 replies; 91+ messages in thread From: Ray Blaak @ 2000-04-19 0:00 UTC (permalink / raw) Jeff Carter <jrcarter@acm.org> writes: > Robert Dewar wrote: > Wirth, in accepting OO for Oberon, said that it's simply ADTs under > another name. > > When I first looked into OO about 1984, once I finally understood what > was going on, I didn't find anything new, except that the mechanism used > made the code less readable than if composition had been used. I > suspected that the OO people made up new terms for well established > concepts such as type (class) and subprogram (methods) to mask this lack > of original content. OO programming being essentially about ADTs covers the most important and worthwhile point. What makes OO programming different from ADTs, in least in my opinion, is language support for inheritance and polymorphism. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Ray Blaak @ 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ray Blaak 2000-04-20 0:00 ` Robert Dewar 1 sibling, 2 replies; 91+ messages in thread From: Jean-Pierre Rosen @ 2000-04-20 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 931 bytes --] Ray Blaak <blaak@infomatch.com> a �crit dans le message : m3hfcxjt22.fsf@ns58.infomatch.bc.ca... > OO programming being essentially about ADTs covers the most important and > worthwhile point. What makes OO programming different from ADTs, in least in my > opinion, is language support for inheritance and polymorphism. Certainly not. What you describe is classification, which is one way of organizing objects. Composition is another one, and there might be others to be invented. I would rather say that what makes OO is the fact that ADT's represent and are modelled after real-life objects, i.e. that a program is no more defined as a sequence of actions to be performed by a computer, but as a representation, a modelization, of the real world. FWIW. -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Jean-Pierre Rosen @ 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` BSCrawford ` (2 more replies) 2000-04-20 0:00 ` Ray Blaak 1 sibling, 3 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-20 0:00 UTC (permalink / raw) In article <8dmj62$4i7$1@wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > i.e. that a program is > no more defined as a sequence of actions to be performed by a > computer, but as a representation, a modelization, of the real > world. FWIW. No, that's much too broad, the object oriented approach is only one particular way of representing or modeling the world. COBOL programs have traditionally modeled the accounting world for example, pretty literally, but often in ways that are purely procedural (the real world does contain procedures as well as objects :-) Indeed this points out the ultimate weakness of relying on the OO paradign for everything. Obviously you can do any computing task using any computation approach, we all know that. Therefore, Q.E.D. you can do anything using an object oriented approach, so we all know that too, and it proves nothing. The point is that the OO approach is most often useful ONLY if it does indeed model the real world, so if your real world problem is not naturally "object oriented", then forcing it into the OO paradigm may considerably distort the model. The fact that there are those around (some in this thread) who think OO is all about ADT features in languages further confuses the issue, and results in a lot of confused code! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` BSCrawford 2000-04-20 0:00 ` Brian Rogoff 2000-04-20 0:00 ` Jean-Pierre Rosen 2 siblings, 0 replies; 91+ messages in thread From: BSCrawford @ 2000-04-20 0:00 UTC (permalink / raw) Robert, you said >No, that's much too broad, the object oriented approach is >only one particular way of representing or modeling the >world. You have pointed out that several commonr notions of what the object oriented approach is are wrong. Could you please give us a brief characterization of what it is? For example, how is it different from an approach based on ADT's classified using inheritance hierarchies? Bard Crawford ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` BSCrawford @ 2000-04-20 0:00 ` Brian Rogoff 2000-04-20 0:00 ` Jean-Pierre Rosen 2 siblings, 0 replies; 91+ messages in thread From: Brian Rogoff @ 2000-04-20 0:00 UTC (permalink / raw) On Thu, 20 Apr 2000, Robert Dewar wrote: > In article <8dmj62$4i7$1@wanadoo.fr>, > "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > > i.e. that a program is > > no more defined as a sequence of actions to be performed by a > > computer, but as a representation, a modelization, of the real > > world. FWIW. > > No, that's much too broad, the object oriented approach is > only one particular way of representing or modeling the > world. > > COBOL programs have traditionally modeled the accounting > world for example, pretty literally, but often in ways that > are purely procedural (the real world does contain procedures > as well as objects :-) > > Indeed this points out the ultimate weakness of relying on the > OO paradign for everything. > > Obviously you can do any computing task using any computation > approach, we all know that. > > Therefore, Q.E.D. you can do anything using an object oriented > approach, so we all know that too, and it proves nothing. > > The point is that the OO approach is most often useful ONLY > if it does indeed model the real world, so if your real world > problem is not naturally "object oriented", then forcing it > into the OO paradigm may considerably distort the model. I would have guessed that you are American, not Scandinavian :-) For those who don't get the reference, the Scandinavians, that is, the designers of Simula and BETA, refer to two different views of OO which they call the "Scandinavian" and "American" views, where the Scandinavian view is concerned with "real world" (whatever that is) modeling and the American with using OO as a software engineering tool concerned with the structure of the source code. This is an oversimplification of course, if you want the full story read one of the books by Madsen on the topic, like the BETA book. Since I have no idea what this "real world" is and how it helps me write code, I'm pretty much an American. I'm certainly looking forward to reading Robert's contrary views on OOP. I suspect that we won't be able to get a hard and fast definition of OOP or OOPL that everyone agrees on. -- Brian ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` BSCrawford 2000-04-20 0:00 ` Brian Rogoff @ 2000-04-20 0:00 ` Jean-Pierre Rosen 2 siblings, 0 replies; 91+ messages in thread From: Jean-Pierre Rosen @ 2000-04-20 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 824 bytes --] Robert Dewar <robert_dewar@my-deja.com> a �crit dans le message : 8dmm12$1j7$1@nnrp1.deja.com... > The point is that the OO approach is most often useful ONLY > if it does indeed model the real world, so if your real world > problem is not naturally "object oriented", then forcing it > into the OO paradigm may considerably distort the model. > Absolutely. I have a book about Eiffel that takes as a first example of OOP... an expression evaluator. Every time you encounter a (sub)expression, you create an "expression" object, call its "evaluate" method, and then destroy the object... Like M. Gauthier likes to say: "not everything is an object" -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-20 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Ray Blaak 2000-04-20 0:00 ` Jean-Pierre Rosen 1 sibling, 1 reply; 91+ messages in thread From: Ray Blaak @ 2000-04-20 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > I would rather say that what makes OO is the fact that ADT's represent and > are modelled after real-life objects, i.e. that a program is no more defined > as a sequence of actions to be performed by a computer, but as a > representation, a modelization, of the real world. FWIW. I have always disagreed with this. After all, you can use the OO paradigm to model abstract concepts that don't exist in the real world. That real-world objects are often most easily modelled using the OO paradigm is instead a matter of a good application of OO, as opposed to a definition of OO. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Ray Blaak @ 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-24 0:00 ` Ray Blaak 0 siblings, 1 reply; 91+ messages in thread From: Jean-Pierre Rosen @ 2000-04-20 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1183 bytes --] Ray Blaak <blaak@infomatch.com> a �crit dans le message : ug0sg4vmk.fsf@infomatch.com... > "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > > I would rather say that what makes OO is the fact that ADT's represent and > > are modelled after real-life objects, i.e. that a program is no more defined > > as a sequence of actions to be performed by a computer, but as a > > representation, a modelization, of the real world. FWIW. > > I have always disagreed with this. After all, you can use the OO paradigm to > model abstract concepts that don't exist in the real world. That real-world > objects are often most easily modelled using the OO paradigm is instead a > matter of a good application of OO, as opposed to a definition of OO. > By "real world", I mean things that normal people (i.e. not computer wizzards) can deal with; of course it includes abstract concepts. What I mean is that you think in terms of "catalog of goods", not in terms of "hash-table of unique references in the data base". -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Jean-Pierre Rosen @ 2000-04-24 0:00 ` Ray Blaak 0 siblings, 0 replies; 91+ messages in thread From: Ray Blaak @ 2000-04-24 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > By "real world", I mean things that normal people (i.e. not computer > wizzards) can deal with; of course it includes abstract concepts. What I > mean is that you think in terms of "catalog of goods", not in terms of > "hash-table of unique references in the data base". Ok, fair enough. I would instead say "think in terms of entities of the problem domain", however. One can implement the catalog of goods using a hash-table, but for the implementor of the hash-table service, the problem domain becomes indeed "wizard" concepts. I don't see any reason why a certain class of abstractions (i.e. programming ones) is not appropriate for OO conceptualization just like any other. The real point is to use the appropriate abstractions for the domain. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Ray Blaak 2000-04-20 0:00 ` Jean-Pierre Rosen @ 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ray Blaak 1 sibling, 1 reply; 91+ messages in thread From: Robert Dewar @ 2000-04-20 0:00 UTC (permalink / raw) In article <m3hfcxjt22.fsf@ns58.infomatch.bc.ca>, Ray Blaak <blaak@infomatch.com> wrote: > OO programming being essentially about ADTs covers the most > important and worthwhile point. What makes OO programming > different from ADTs, in least in my opinion, is language > support for inheritance and polymorphism. nope! that has nothing to do with object oriented programming. inheritance and polymorphism are concepts that perfectly well fit into the general world of ADT's. Example. Suppose we define an abstract algebra as a tagged type. The operations are purely value oriented (e.g. operation + on two elements computes a third element). The notion of extending the abstract algebra to a concrete field makes perfect sense, and the notion of dynamic dispatching to allow routines to deal with different algebras also makes sense. What does not make sense is to think of this as object oriented programming, since the two fundamental components of objects: 1. state, so that objects can be changed 2. methods with message passing semantics so that the operations are viewed as passing a message to the distinguished object (the prefix in languages that use this syntax) are completely missing. When Simula-67 was introduced, ADT's were of course very well known and understood (this was after all a decade after Algol-60 was introduced!) Simula-67 had something original and interesting to add to the programmer's knowledge base. If you think that OO is simply about ADT's then you are back in the 60's and have missed something :-) On the other hand, if you think that type extension, information hiding, and dynamic dispatching are ONLY about object oriented programming, then you have also missed something! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Ray Blaak 2000-04-20 0:00 ` Charles Hixson 0 siblings, 1 reply; 91+ messages in thread From: Ray Blaak @ 2000-04-20 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <m3hfcxjt22.fsf@ns58.infomatch.bc.ca>, > Ray Blaak <blaak@infomatch.com> wrote: > > OO programming being essentially about ADTs covers the most > > important and worthwhile point. What makes OO programming > > different from ADTs, in least in my opinion, is language > > support for inheritance and polymorphism. > > nope! that has nothing to do with object oriented programming. Well, "nothing to do" is a little strong. All of the OO languages give exactly these features, and saying a language is an "Object-Oriented" language has some meaning precisely because of this fact. > Example. Suppose we define an abstract algebra as a tagged > type. The operations are purely value oriented (e.g. operation > + on two elements computes a third element). I am perfectly comfortable with calling this OO. > What does not make sense is to think of this as object > oriented programming, since the two fundamental components > of objects: > > 1. state, so that objects can be changed Are you saying that only mutable things can be considered as objects? That seems extreme to me. > 2. methods with message passing semantics so that the > operations are viewed as passing a message to the > distinguished object (the prefix in languages that > use this syntax) I think I agree with this one (that it is fundamental to OO), although I point out that there does not have to be a single distinguished object (e.g. Common Lisp's object system works in general with multiple distinguished objects). The important thing is the conceptualization of the problem into a collection of entities that are responsible for doing things to themselves and each other. > are completely missing. I would assert that your example actually has both of the characteristics. With regards to state, even if there is no specifically modelled state, one still has object identity in relation to other objects (e.g. A+B is (often) different from both A and B). With regards to message semantics, the "+" operator would presumably be implemented by doing some sort of evaluation of its arguments, "asking" them questions about themselves ("who are you?" at the very least). > If you think that OO is simply about ADT's then you are back > in the 60's and have missed something :-) > > On the other hand, if you think that type extension, information > hiding, and dynamic dispatching are ONLY about object oriented > programming, then you have also missed something! It's a matter of semantics. "Object-Oriented" as a term tends to be fairly vague, which is why we have threads like this. I like programming by conceptualizing the problem in terms of "objects", and using type extension, information hiding and dynamic dispatching. I don't necessarily use all of these features simultaneously. I call it OO anyway. I don't think I am alone, but I am not that worried about it. The important thing for me is to make robust, well-designed and maintainable software. OO as a term is really only important to me during job interviews. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Ray Blaak @ 2000-04-20 0:00 ` Charles Hixson 2000-04-21 0:00 ` Jean-Pierre Rosen 2000-04-21 0:00 ` Jon S Anthony 0 siblings, 2 replies; 91+ messages in thread From: Charles Hixson @ 2000-04-20 0:00 UTC (permalink / raw) My original definition of an Object (I was coming to C++ from C after being exposed to Apple's Object Pascal) was: An object is a data structure combined with the methods defined to access it. It is made useful by inheritance. I still think that this is the "basic" definition in most languages, however Ada and Lisp parse the world very differently. In their view, the methods are NOT a part of the object. So we are left with Tagged ADT's which are made useful through inheritance. Personally, I think that it makes a reasonable amount of sense to chunk the methods with the object, but I'm not vehement on the point, and I'm still very new to Ada, so perhaps my opinion will change. However, in Ada an object appears to be a tagged abstract data type. This is a language dependent definition, but ANY workable definition of a computer language object WILL BE language dependent. (Or so it seems to me.) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Charles Hixson @ 2000-04-21 0:00 ` Jean-Pierre Rosen 2000-04-29 0:00 ` Aidan Skinner 2000-04-21 0:00 ` Jon S Anthony 1 sibling, 1 reply; 91+ messages in thread From: Jean-Pierre Rosen @ 2000-04-21 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 708 bytes --] Charles Hixson <charleshixsn@earthlink.net> a �crit dans le message : 38FF3914.839040E2@earthlink.net... > > My original definition of an Object (I was coming to C++ from C after being > exposed to Apple's Object Pascal) was: > An object is a data structure combined with the methods defined to access it. It > is made useful by inheritance. This seems to imply that an object is not "useful" unless you use inheritance. I'd like some evidence to support that claim (the fact that many gurus do it is not supporting evidence to me). -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-21 0:00 ` Jean-Pierre Rosen @ 2000-04-29 0:00 ` Aidan Skinner 2000-04-29 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 91+ messages in thread From: Aidan Skinner @ 2000-04-29 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > This seems to imply that an object is not "useful" unless you use > inheritance. > I'd like some evidence to support that claim (the fact that many gurus do it > is not supporting evidence to me). I'd tend to think that an object *shouldn't* be useful unless it's a descendent of a more abstract one. I like to have a base class which is abstract and then inherit from that, even if I've only got one descendant at the time and I don't forsee the need for any more. It saves having to rework stuff later. - Aidan -- http://www.reality.co.uk/ http://www.skinner.demon.co.uk/aidan/ "I could always suspend a few hundred accounts and watch what happens" ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-29 0:00 ` Aidan Skinner @ 2000-04-29 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 91+ messages in thread From: Robert I. Eachus @ 2000-04-29 0:00 UTC (permalink / raw) Aidan Skinner wrote: > I'd tend to think that an object *shouldn't* be useful unless it's a > descendent of a more abstract one. I like to have a base class which > is abstract and then inherit from that, even if I've only got one > descendant at the time and I don't forsee the need for any more. It > saves having to rework stuff later. Hmmm... I like to say that Ada class hierarchies are bushier. It seems to turn out that if you take, say a Smalltalk class hierarchy and re-implement it in Ada, you end up with a forest instead of a single tree (no surprise), and most of the public derivation trees have either a single entry or a root and a number of child classes. In the private (implementation) part of the hierarchy there may be intermediate classes, but unless you are extensively using generic mix-ins, the trees are still short and fat. (And yes I am working on a paper on this right now. And the funny thing is, it ends up recommending mix-ins all over the implementation space. But the public model is stays sparse, and does not make much use of multi-level inheritance.) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Charles Hixson 2000-04-21 0:00 ` Jean-Pierre Rosen @ 2000-04-21 0:00 ` Jon S Anthony 1 sibling, 0 replies; 91+ messages in thread From: Jon S Anthony @ 2000-04-21 0:00 UTC (permalink / raw) Charles Hixson wrote: > My original definition of an Object (I was coming to C++ from C > after being exposed to Apple's Object Pascal) was: An object is a > data structure combined with the methods defined to access it. It > is made useful by inheritance. Or true delegation (you don't need to have class based "oo" to have "oo", ;-) > I still think that this is the "basic" definition in most languages, > however Ada and Lisp parse the world very differently. In their > view, the methods are NOT a part of the object. They are just being more "honest" - the methods are not part of the object in nearly any of these other languages either. About the only exceptions to this are some CL based methods-per-object object systems and Object Logo. Note that building a standard simple "distinguished object" version of OO in CL is about 4 or 5 pages of code. Complete with standard module/class conflation, er constructs, method definition, etc. Even includes MI. > So we are left with Tagged ADT's which are made useful In Ada. In CLOS you have: generic functions and true multiple dispatch (+ the MOP, with which you can decide your own method dispatch protocol if need be). > through inheritance. Personally, I think that it makes a reasonable > amount of sense to chunk the methods with the object, but I'm not > vehement on the point, It is the naive and simplistic way. It is also rather limited (and limiting) and a poor way if you really are interested in creating highly expressive systems, i.e., solving problems and not just interested in towing the standard simplistic OO line. Frankly, the standard OO line is highly overrated and rather boring. /Jon -- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Jeff Carter 2000-04-19 0:00 ` Ray Blaak @ 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Jeff Carter 1 sibling, 1 reply; 91+ messages in thread From: Robert Dewar @ 2000-04-20 0:00 UTC (permalink / raw) In article <38FE365D.31C893A6@acm.org>, jrcarter@acm.org wrote: > Wirth, in accepting OO for Oberon, said that it's simply ADTs > under another name. If that's accurately stated, he is missing something! > When I first looked into OO about 1984, once I finally > understood what was going on, I didn't find anything new, > except that the mechanism use made the code less readable than > if composition had been used. Well seeing as it is Simula-*67* you would hardly expect to find anything new in 1984! > I suspected that the OO people made up new terms for well > establishe concepts such as type (class) and subprogram > (methods) to mask this lack of original content. Then you are missing something too. The object oriented programming paradigm, involving objects with state, with a message passing discipline between objects, is a valuable one with many applications (although trying to bend it to all applications is unfortunate). I know these two positions well: All abstract data types are objects, and anything I do with ADT's is OO programming. There is no such thing as OO, it's all hype. But neither of these is a helpful illuminating position! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Jeff Carter 2000-04-21 0:00 ` Robert Dewar 0 siblings, 1 reply; 91+ messages in thread From: Jeff Carter @ 2000-04-20 0:00 UTC (permalink / raw) Robert Dewar wrote: > > I suspected that the OO people made up new terms for well > > establishe concepts such as type (class) and subprogram > > (methods) to mask this lack of original content. > > Then you are missing something too. That's certainly possible, but so far no one has been able to show me what. It's also important to differentiate between the two common meanings of OO. One means "object oriented", as in OOD. The other means "implemented using inheritance and dispatching", as in OOP. Obviously, there is nothing inherently object oriented about the latter, and I have seen plenty of "OO" code that had nothing object oriented about it. -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Jeff Carter @ 2000-04-21 0:00 ` Robert Dewar 2000-04-21 0:00 ` Jon S Anthony 2000-04-21 0:00 ` Ken Garlington 0 siblings, 2 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-21 0:00 UTC (permalink / raw) In article <38FF804E.BB59D751@acm.org>, jrcarter@acm.org wrote: > and I have seen > plenty of "OO" code that had nothing object oriented about it. OO *means* object oriented, so the above is a contradiction in terms. To describe code that has nothing object oriented about it as OO is simply wrong. Yes, a lot of people are confused, but what else is new? Most of the people writing C++ today are very seriously confused about a lot of things! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-21 0:00 ` Robert Dewar @ 2000-04-21 0:00 ` Jon S Anthony 2000-04-22 0:00 ` Robert Dewar 2000-04-21 0:00 ` Ken Garlington 1 sibling, 1 reply; 91+ messages in thread From: Jon S Anthony @ 2000-04-21 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <38FF804E.BB59D751@acm.org>, > jrcarter@acm.org wrote: > > and I have seen > > plenty of "OO" code that had nothing object oriented about it. > > OO *means* object oriented, so the above is a contradiction > in terms. To describe code that has nothing object oriented > about it as OO is simply wrong. You missed the scare-quotes around "OO" (here the quotes are _not_ scare quotes!) /Jon -- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-21 0:00 ` Jon S Anthony @ 2000-04-22 0:00 ` Robert Dewar 0 siblings, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-22 0:00 UTC (permalink / raw) In article <3900FFF9.51C9@synquiry.com>, Jon S Anthony <jsa@synquiry.com> wrote: > You missed the scare-quotes around "OO" (here the quotes are > _not_ scare quotes!) Ah, I got it! As in C++ is an "OO" language :-) or "look at me, I used // for comments so this is an "OO" program :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-21 0:00 ` Robert Dewar 2000-04-21 0:00 ` Jon S Anthony @ 2000-04-21 0:00 ` Ken Garlington 1 sibling, 0 replies; 91+ messages in thread From: Ken Garlington @ 2000-04-21 0:00 UTC (permalink / raw) "Robert Dewar" <robert_dewar@my-deja.com> wrote in message news:8dq859$sae$1@nnrp1.deja.com... > In article <38FF804E.BB59D751@acm.org>, > jrcarter@acm.org wrote: > > and I have seen > > plenty of "OO" code that had nothing object oriented about it. > > > OO *means* object oriented, so the above is a contradiction > in terms. But does "OO" (vs. OO) mean object oriented? (e.g., the Mafia "persuaded" the witness to not testify.) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Geoff Bull ` (2 preceding siblings ...) 2000-04-19 0:00 ` Jeff Susanj @ 2000-04-19 0:00 ` David Botton 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Robert Dewar 3 siblings, 2 replies; 91+ messages in thread From: David Botton @ 2000-04-19 0:00 UTC (permalink / raw) The first step is getting them to come over from other languages and/or to think of Ada as even a possibility. The lack of the _code_word_ "class" is a huge wall, and since the introduction of Java, the lack of direct support for at least MI with interfaces is another. David Botton Geoff Bull wrote in message >For people coming from other languages, changing the word tagged to class >is going to help not zero. >The problem they face is overcoming the assumptions they have made >about how oo is implemented. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` David Botton @ 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Robert Dewar 1 sibling, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <xAbL4.310$up5.205418@news-east.usenetserver.com>, "David Botton" <David@Botton.com> wrote: > The first step is getting them to come over from other > languages and/or to think of Ada as even a possibility. The > lack of the _code_word_ "class" is a huge wall, and since the > introduction of Java, the lack of direct support > for at least MI with interfaces is another. Anyone for whom this is a "huge wall" is very poorly educated about programming and programming languages -- yes I agree this applies to lots of people, but I must say I have no trouble introducing Ada notions to a large segment of graduate students. That's at least one step of data above a completely unsupported claim like the above. I am completely unconvinced by the MI claim ... again it seems quite unsubstantiated to me. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` David Botton 2000-04-19 0:00 ` Robert Dewar @ 2000-04-19 0:00 ` Robert Dewar 2000-04-20 0:00 ` Geoff Bull 1 sibling, 1 reply; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <xAbL4.310$up5.205418@news-east.usenetserver.com>, "David Botton" <David@Botton.com> wrote: > The first step is getting them to come over from other > languages and/or to think of Ada as even a possibility. The > lack of the _code_word_ "class" is a huge wall, and since the > introduction of Java, the lack of direct support > for at least MI with interfaces is another. Anyone for whom this is a "huge wall" is very poorly educated about programming and programming languages -- yes I agree this applies to lots of people, but I must say I have no trouble introducing Ada notions to a large segment of graduate students. That's at least one step of data above a completely unsupported claim like the above. I am completely unconvinced by the MI claim ... again it seems quite unsubstantiated to me. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Geoff Bull 0 siblings, 0 replies; 91+ messages in thread From: Geoff Bull @ 2000-04-20 0:00 UTC (permalink / raw) Robert Dewar wrote: > I am completely unconvinced by the MI claim Me too - first you have to get 'em to the stage where they might even notice there is no MI. Also, Java would be a sorry language without interfaces, but with Ada there is usually another (often better) way, e.g. generics. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` John J. Rusnak 2000-04-19 0:00 ` Geoff Bull @ 2000-04-19 0:00 ` Jean-Pierre Rosen 2000-04-19 0:00 ` Robert Dewar 2 siblings, 0 replies; 91+ messages in thread From: Jean-Pierre Rosen @ 2000-04-19 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1083 bytes --] John J. Rusnak <john.rusnak@mindspring.com> a �crit dans le message : 38FD1830.949F5E81@mindspring.com... > I'd have to weigh in on the opposite side. "Class" and "object" are rather > easy terms to grasp. And I can tell you through exeperience that the Ada > model has been difficult for many I have seen coming into the language to > grasp. (Some with OO backgrounds and some without). But to each their own > I suppose. > I beg to differ. My experience is that Ada'OO model is quite easy to understand (and FYI, training in Ada is my primary business). Especially, dispatching is easier to explain than in other language: "If something is of a class wide type, the actual type is not known at compile time; therefore, overloading resolution is done at execution time, when the type is known". I have seen people who never quite understood dispatching in C++ that easily understood this explanation. -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` John J. Rusnak 2000-04-19 0:00 ` Geoff Bull 2000-04-19 0:00 ` Jean-Pierre Rosen @ 2000-04-19 0:00 ` Robert Dewar 2 siblings, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <38FD1830.949F5E81@mindspring.com>, "John J. Rusnak" <john.rusnak@mindspring.com> wrote: > I'd have to weigh in on the opposite side. "Class" and > "object" are rather easy terms to grasp. A tagged object in Ada is NOT a class in the OO sense, and oddly this is true of a class in C++. Just because you call something a class in C++ does not mean you are defining an object or class in the OO sense. I find that pretty confusing in C++ I must say, and it definitely leads people into the realms of mega-confusion. I often see people who define "classes" in C++ and thinking they are doing object oriented programming, when they are just defining abstract data types. Class and object may be easy terms for you to grasp, but most C++ programmers seem quite confused if you ask them to define the difference between an abstract data type and an object. Tagged types are simply types with particular properties that are useful for many programming purposes (e.g. one use is to simply ensure that objects (in the Ada sense!) of the type are passed by reference, there are many many other uses, including the fact that tagged types are suitable for representing certain kinds of objects (in the OO sense). > And I can tell you through exeperience that the Ada > model has been difficult for many I have seen coming into the > language to grasp. Anyone who understands what types and abstract data types are about should have no trouble with the Ada type model. If you are talking about the "object" model of Ada, then my response is that this is VERY confused thinking. Object oriented programming is about a paradigm for program design, it is not a language construct! (Some with OO backgrounds and some without). But to each their own > I suppose. > > I agree with the comment on "code words", though. > > -John > > tmoran@bix.com wrote: > > > > A tagged type is not a class. A tagged type is a programming construct > > When first trying to understand this stuff, I personally found thinking > > of a tag on a record etc to be much easier to understand than all the > > OO stuff about classes and objects. "class" and "object" are such > > vague terms they convey little information. Also they are used for > > a variety of *different* things (see mathematics, or MS's use of "class" > > in COM). OTOH, if one's intent is to certify membership in an > > exclusive club by the use of code words known only to the members, > > then "class" is as good as anything. > > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Jean-Pierre Rosen 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` tmoran @ 2000-04-18 0:00 ` John Rusnak 2000-04-19 0:00 ` Robert Dewar 2000-04-18 0:00 ` Pascal Obry 3 siblings, 1 reply; 91+ messages in thread From: John Rusnak @ 2000-04-18 0:00 UTC (permalink / raw) C++ allows you to put many classes in one namespace and also allows you to have inner classes which are concepts analogous to putting more than one tagged type in a package. Java's definition of a package is essentially a grouped collection of classes. Java also allows you to have inner classes (I believe) and also allows you to define more than one class within a given file, although only one will be publicly available for use outside the file. Note that it is recommended in Ada as a matter of good style NOT to put more than one tagged type in a package. (See Section9.6 of the Styl Guide). And I have to agree with this design choice. When I do have to put a seond tagged type in a package, I generally place it within the context of an internal (child?) package. -John ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` John Rusnak @ 2000-04-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <38FCD19F.49DD6519@lmco.com>, John Rusnak <john.j.rusnak@lmco.com> wrote: > Note that it is recommended in Ada as a matter of good style > NOT to put more than one tagged type in a package. (See > Section9.6 of the Styl Guide). And I have to agree with this > design choice. When I do have to put a seond tagged type in a > package, I generally place it within the > context of an internal (child?) package. I find this seriously misguided advice, there is no reason to treat tagged types specially here. Putting multiple related types into a package often makes sense, whether or not they are tagged. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Jean-Pierre Rosen ` (2 preceding siblings ...) 2000-04-18 0:00 ` John Rusnak @ 2000-04-18 0:00 ` Pascal Obry 3 siblings, 0 replies; 91+ messages in thread From: Pascal Obry @ 2000-04-18 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1872 bytes --] Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> a �crit dans le message : 8dh37m$qef$2@wanadoo.fr... > Can't resist to provide my 0.02 on the tagged/class issue, or how I present > it in my courses. > > A tagged type is not a class. A tagged type is a programming construct that > can be used to build classes. This is what the building block approach is > about. > A class in the usual OOP sense is a *design pattern*, where you put a tagged > type and its associated primitive operations (the methods) in a package > specification. Ada allows you to build other design patterns, that have no > equivalent in other languages, like putting several tagged types in a single > package (a bit like friends, but not exactly similar). > I completly agree with this view. The whole point is "building block" and this is how Ada has been design. Then designer can use the flexibility of Ada to build whatever "design pattern" they need, one of them is the C++ or Java "class". This "building block" orientation of Ada has been very well presented by T. Taft at a conference in Paris some years ago. Pascal. -- --|------------------------------------------------------------ --| Pascal Obry Team-Ada Member | --| | --| EDF-DER-IPN-SID- T T I | --| Intranet: http://cln46gb | --| Bureau N-023 e-mail: p.obry@der.edf.fr | --| 1 Av G�n�ral de Gaulle voice : +33-1-47.65.50.91 | --| 92141 Clamart CEDEX fax : +33-1-47.65.50.07 | --| FRANCE | --|------------------------------------------------------------ --| --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Geoff Bull 2000-04-18 0:00 ` Jean-Pierre Rosen @ 2000-04-18 0:00 ` David Botton 1 sibling, 0 replies; 91+ messages in thread From: David Botton @ 2000-04-18 0:00 UTC (permalink / raw) class type X = type X is tagged Geoff Bull: > class type X is record ... > and means exactly the same as > type X is tagged record ... Yup. > > I.E. we would have two ways of doing the same thing. Yup. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` Robert Dewar 2000-04-16 0:00 ` Jeff Carter 2000-04-16 0:00 ` David Botton @ 2000-04-17 0:00 ` Robert I. Eachus 2000-04-18 0:00 ` Robert Dewar 2000-04-19 0:00 ` Alfred Hilscher 3 siblings, 1 reply; 91+ messages in thread From: Robert I. Eachus @ 2000-04-17 0:00 UTC (permalink / raw) Robert Dewar wrote: > It's always a hard sell when you choose terminology that is > arbitrarily different from the cultural norm. It is interesting > to recall the big debate at the Salem meeting between Tucker > Taft and Jean Ichibiah. I won't even try to write a history of Ada 9X, even of just that meeting, but it certainly was a key point in the history of Ada. There were several issues that could have resulted in failure to reach concensus at that meeting, but most of the sound and fury was devoted to class vs. tagged. (To me the silliest of the issues with such potential was about whether or not to allow leading underscores in identifiers...) I think that the reason that the classs vs. tagged debate got so furious was that there were two different viewpoints, one technical and one aesthetic. Many of those arguing for class were unwilling to discuss some of the technical problems with their alternatives, while the tagged group was very reluctant to consider compromises without through analysis. The sense in which the tagged group "won" is that the version finally accepted did not create unnecessary limitations, and IMHO, the changed to the treatment of abstract made at a later Boston meeting probably would not have been possible with the syntax proposed by Jean Ichbiah. The way in which the Ada community as a whole lost is that the current syntax is probably much uglier that it had to be. Efforts to ammend the proposals (before the Salem meeting) were looked on as unacceptable compromises instead of "perfecting ammendments." "type Foo is Bar with begin null; end record;" did get cleaned up to "...with null record;" then "...with null;" But simply replacing the tagged keyword with class was for some reason unacceptable to both sides... > The national delegations at Salem were all a bit appalled by > the ferocity of the argument on both sides, and in particular > at what was clearly a huge amount of effort the design team > had spent in preparing the counter argument. Tucker, do you have a copy of your Winnie the Pooh slides? I think it would be worth putting them on-line in some historical archive, and if possible Jean Ichbiah's presentation as well. But everyone should remember that there were several dozen potential show-stoppers discussed and resolved in Salem, and by Saturday? afternoon we had a consensus which was then adopted unanimously as the result of the conference. > I knew perfectly well at the time that if I had instead said > > "I really think we cannot have an important issue like this > left open with an even vote, I propose that we discuss > this further and revote, that then most likely CLASS would > have been approved." > > But I worried about the dynamics. For whatever reason it > was clear that the Ada 95 design team was truly ferociously > opposed (in fact it reminded me of Jean's opposition to the > unanimous recommendation of the Ada 83 DR's for removing > derived types from Ada 83). > > Jean's motion was rejected partly because he insisted on > the prefix notation. Indeed the Japanese delegation voted > against it solely on this basis, and I think if they had > realized that tactically their negative vote would sink > the whole proposal, they would have reconsidered. Even > if they had abstained, then the motion would have carried > (by a majority of 2 countries, since the US would then have > voted FOR the motion.) > > I tried before the discussion to get Jean to separate the > two points, but he refused. I knew that was a > tactical error, based on previous discussions in the DR > group, but he was adamant. Personally I prefer the prefix > notation, but I knew others were quite opposed to it. If we had another day, I would have strongly supported you. But running out of time on the clock/calendar could have a significantly adverse impact on the Ada 9X process. (And I think that every night that week I was up past midnight getting materials ready for the next day. MITRE was acting as host, and often subgroups met late at night preparing wording to be voted on the next day. We had a computer set up with a laser printer and we thought, plenty of transparencies. We almost ran out on the last day, even though we had twice sent someone to get more...) Many of those attending the meeting felt that it was vitally important that the meeting end with no major divisive issues unresolved. (And I think I remember RBKD as one who felt this way.) The class/tagged issue had been discussed and resolved at an earlier meeting, but Jean Ichbiah reopened the issue on-line. There is nothing wrong with this. In many cases a technical problem will be found in a "closed" decision, and it is necessary to re-open the issue to correct it. But when all the problems are known and have been discussed, as they had been in this case at or before the Salem meeting, a decision has to be made that is final. It would have been nice to have a better proposal on the table at Salem, but there are cases where the procedures for reaching agreement limited the number of alternatives considered. And in this case, any compromise position would--and did--get attacked from both sides, since they saw no reason to compromise, and politically both extreme positions had to be represented in the final vote. Oh, and one other thing that most people miss about this issue. There are classes in Ada 83, and there is a richer class structure in Ada 95 that has little or nothing to do with tagged types. (See the note at the end of Section 3.2 in the Ada95 RM.) To change the meaning of class as a technical term would require significant additional work by the Language Design Team--unless they were allowed to unify the existing class hierarchy and the new class constructs. But this had been explicitly considered and rejected much earlier in the design process. So those arguing for class as a keyword had to justify the extra effort. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-17 0:00 ` Robert I. Eachus @ 2000-04-18 0:00 ` Robert Dewar 2000-04-19 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 91+ messages in thread From: Robert Dewar @ 2000-04-18 0:00 UTC (permalink / raw) In article <38FB8556.4EACD391@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: > (To me the silliest of the issues with > such potential was > about whether or not to allow leading underscores in > identifiers...) Silly enough for you to have forgotten the issue :-) The issue was whether to treat underscores as letters in identifiers, removing the restrictions on the use of underscores. Actually the example most often used was a trailing underscore, but the general ability to mirror c identifiers such as a__b was also an issue. > IMHO, the changed to the treatment of abstract made at a later > Boston meeting probably would not have been possible with the > syntax proposed by Jean Ichbiah. That's plain wrong, or a misunderstanding, the notation class type x is record ... as simply a syntactic transformation of type x is tagged record ... is completely neutral with respect to such changes (indeed an Ada 95 compiler today could if it liked accept the first time as a source representation of the second form (though this kind of stretching of the notion of source representation is considered unsporting, even if allowed by the RM :-) To change the meaning of class as a technical > term would require significant additional work by the Language Design > Team--unless they were allowed to unify the existing class hierarchy and > the new class constructs. But this had been explicitly considered and > rejected much earlier in the design process. So those arguing for class > as a keyword had to justify the extra effort. TO use this as an argument against the class syntax suggestion is allowing best to be the enemy of good. The class syntax could perfectly well be introduced without changing the notion of classes. After all, to most Ada 95 programmers type x is tagged record ... introduces a new class called x anyway, sure I know that is not quite right, but there are lots of cases where informal usage does not match the RM :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-18 0:00 ` Robert Dewar @ 2000-04-19 0:00 ` Robert I. Eachus 2000-04-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 91+ messages in thread From: Robert I. Eachus @ 2000-04-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > Silly enough for you to have forgotten the issue :-) The issue > was whether to treat underscores as letters in identifiers, > removing the restrictions on the use of underscores. Actually > the example most often used was a trailing underscore, but the > general ability to mirror c identifiers such as a__b was also > an issue. As near as I can remember, the four alternatives discussed were: no change, allow trailing underscores, allow leading and trailing underscores, and treat underscore as if it was a letter. Since no concensus developed behind any change, the result was to stand pat. I personally think that the silliest part of this discussion ws on allowing leading underscores, and I think that was what killed the most general alternative. But all that is detail. > > IMHO, the changed to the treatment of abstract made at a later > > Boston meeting probably would not have been possible with the > > syntax proposed by Jean Ichbiah. > > That's plain wrong, or a misunderstanding, the notation > > class type x is record ... > > as simply a syntactic transformation of > > type x is tagged record ... > > is completely neutral with respect to such changes (indeed > an Ada 95 compiler today could if it liked accept the first > time as a source representation of the second form (though > this kind of stretching of the notion of source representation > is considered unsporting, even if allowed by the RM :-) The devil has always been in the details. If the only difference between Jean and Tucker's positions had been in the syntax, the online discussions would not have been anywhere near as long. In any case, the particular feature that I was referring to was to have an abstract formal private type and to derive another abstract type from it within the generic specification, and finally derive a non-abstract type from the instance: generic type Element is abstract tagged limited private; package Linked_Lists is type List_Element is abstract new Element with private; -- operations on lists... end Linked_Lists; ... package List_of_Strings is new Linked_Lists(Ada.Strings.Unbounded.Unbounded_String); type List_Element is new List_of_Strings.List_Element; This change made later, in Boston, required both syntax and semantic changes, and I felt that it fit extremely well with the tagged type grammar and semantics. I do not feel that it would have fit nearly as well with Jean's grammar, and would have required more semantic work. It was an extremely close call to even consider allowing the language design team to even work on this, although the vote the next day to adopt Tucker's proposal was overwhelming. The amount of compiler change was not an issue, but the amount of RM text to be changed was. Since this change was simplifying and unifying, it got in. Would a similar change to the class grammar have made it through? I don't know. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Robert I. Eachus @ 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ray Blaak 2000-04-23 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-20 0:00 UTC (permalink / raw) In article <38FE442C.92F7C2B3@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: > > As near as I can remember, the four alternatives discussed > were: no change, allow trailing underscores, allow leading and > trailing underscores and treat underscore as if it was a > letter. Since no concensus > developed behind any change, the result was to stand pat. Again, your memory is flawed here, you should check the minutes of the Salem meeting. In particular, the rejection was nothing to do with lack of consensus behind any one scheme, but rather to do with dislike for the whole idea. In particular you should be able to recall the fierce opposition of the French delegation on this point :-) > I personally think that the silliest part of this discussion > was on allowing leading underscores, and I think that was what > killed the most general alternative. But all that is detail. Yes, and incorrect detail at that, this was not at ALL the dynamics of the discussion. In particular, perhaps you can recall the strong point that was made that with modern variable width type fonts, it is hard to tell how many underscores are in a sequence of underscores ... that was the primary French objection to the motion. > > > I do not feel that it would have fit nearly as > well with Jean's grammar, and would have required more semantic work. I disagree > It was an extremely close call to even consider allowing the language > design team to even work on this, This is a completely incorrect memory, there was no close call. Just look at the minutes! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar @ 2000-04-20 0:00 ` Ray Blaak 2000-04-23 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 91+ messages in thread From: Ray Blaak @ 2000-04-20 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > This is a completely incorrect memory, there was no close call. > Just look at the minutes! Are any of these minutes available online? I seem to recall some things about the Ada 9X design process being available, but can't seem to find anything now. Did it used to be at AJPO? Are there any AJPO archives anywhere? (There seems to have been a concerted effort to "disappear" all online AJPO materials, including mirrors). -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ray Blaak @ 2000-04-23 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 91+ messages in thread From: Robert I. Eachus @ 2000-04-23 0:00 UTC (permalink / raw) Robert Dewar wrote: > Again, your memory is flawed here, you should check the minutes > of the Salem meeting. In particular, the rejection was nothing > to do with lack of consensus behind any one scheme, but rather > to do with dislike for the whole idea. In particular you should > be able to recall the fierce opposition of the French delegation > on this point :-) My memory of the discussion was that the debate was mostly between leading, leading and trailing, and underscore as a letter, rather than between those who favored some change and those in favor of no change. Of course, I might have missed some of the debate running various errands, but I think I was there for most if not all of it. In any case, I think that the some people voted against change since there was no strong consenus in favor of a single proposal. I don't think I can verify or falsify that from the minutes. > > > I personally think that the silliest part of this discussion > > was on allowing leading underscores, and I think that was what > > killed the most general alternative. But all that is detail. > > Yes, and incorrect detail at that, this was not at ALL the > dynamics of the discussion. In particular, perhaps you can > recall the strong point that was made that with modern > variable width type fonts, it is hard to tell how many > underscores are in a sequence of underscores ... that was > the primary French objection to the motion. I didn't say it was all of the discussion, just the silliest part. Some delegates actually thought it was important for interfacing to C, while many who actually wrote interfaces to C found the idea of such names contaminating their code distasteful. As a result we had a lot of people talking past each other--one group feeling it was necessary for functionality and the other--including the French, opposed on style grounds. > > It was an extremely close call to even consider allowing the > > language design team to even work on this, > This is a completely incorrect memory, there was no close call. > Just look at the minutes! And what will I find? There was a discussion of whether or not it was too late to consider changes to the grammar. However, since the existing grammar was obviously broken, I don't think that there was even a vote on that. Then there was a discussion of whether to require the design team to make the smallest possible change. Tucker strongly argued that he thought that the total (text) change for the more radical--and elegant--fix was small, and offered to work on it overnight. He did, and it was small, but I think that, with time to sleep on it, everyone who understood the issue was in favor, even if it had turned out to be a large change. So, as I recall, there was a close call on whether or not it was too late for a change of this mangitude, but once a full proposal was put on the table, no one was against it. (In fact the only subject of any discussion at all was the order of keywords, resolving to "type Foo is abstract tagged limited private;" ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-16 0:00 ` Robert Dewar ` (2 preceding siblings ...) 2000-04-17 0:00 ` Robert I. Eachus @ 2000-04-19 0:00 ` Alfred Hilscher 2000-04-19 0:00 ` Ray Blaak 3 siblings, 1 reply; 91+ messages in thread From: Alfred Hilscher @ 2000-04-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > Jean argued that Ada 95 would be far more accessible to the > object oriented cognoscenti if it was willing to embrace the > term class more enthusiastically, and he suggested that > > type x is tagged record .... > > be replaced by > > class type x is record .... > I would have preferred this notation too. 1. "class type t is ..." and "t'class" would be more clear than "type t is tagged ..." and "t'class" 2. I have to write task type t is and not type t is concurrent ... ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Alfred Hilscher @ 2000-04-19 0:00 ` Ray Blaak 2000-04-19 0:00 ` Robert Dewar 0 siblings, 1 reply; 91+ messages in thread From: Ray Blaak @ 2000-04-19 0:00 UTC (permalink / raw) Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> writes: > I would have preferred this notation too. > 1. "class type t is ..." and "t'class" would be more clear than > "type t is tagged ..." and "t'class" > 2. I have to write task type t is and not type t is concurrent > ... And "protected type t", not "type t is protected". For that matter, given a protected type, one also writes t.Foo instead of Foo(t). I know people here feel strongly about the normal procedural syntax for method calls, and it certainly helps to avoid problems, especially with defining binary operations, but having been away from Ada for a while, and using Delphi, C++, and Java, I have found I have changed my mind. I am realizing the saying obj.Method is a more natural way of expressing how I *think*. I like Delphi's way of doing OO: type TObject = class (ParentClass, Interface1, Interface2, ...) private attribute : Integer; public procedure Foo(v : Integer); end; and then the implementations look like: procedure TObject.Foo(v : Integer); begin self.attribute := v; end; I consider myself to be an experienced OO programmer, and at one time was an expert Ada programmer, and I certainly "get" Ada's way of doing OO with tagged types, but I find the syntax now for doing simple OO stuff tedious and not as clear to the reader as it should be. Multiple inheritance from interfaces should be easy. Declaring virtual methods should be easy. In Ada, the caller decides if dispatching is desired by ensuring a method call is in terms of a class wide parameter or not. I think it should be the class implementor that decides, since if the caller gets it wrong, it is a silent error. Delphi's style makes overriding and polymorphism clear in the code: type TObject = class(TBaseObject) procedure Foo; override; // required if TBaseObject.Foo is virtual procedure DispatchOnMe; virtual; end; Ada's style is the most "correct" since we have a true building block approach, but I just wish the syntax was a little better. I am spouting religious opinions to be sure, I generally like Ada very much, and its OO style is now standardized and not going to change any time soon, but I will still complain about it now and again. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: friend classes in ada95 2000-04-19 0:00 ` Ray Blaak @ 2000-04-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 91+ messages in thread From: Robert Dewar @ 2000-04-19 0:00 UTC (permalink / raw) In article <uln2aq6oo.fsf@infomatch.com>, Ray Blaak <blaak@infomatch.com> wrote: > I am realizing the saying obj.Method is a more natural way of > expressing how I *think*. but ONLY if Method is indeed an OO method, certainly I don't think anyone prefers Obj1."+" (Obj2) to Obj1 + Obj2 The problem of people confusing tagged types with objects, and primitive procedures with OO methods is a pretty severe one, and adopting the prefix notation would most certainly aggravate the situation. It is conceivable that one might want to allow the prefix alternative when wanted, but you certainly do NOT want to insist on it in all cases. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2000-04-29 0:00 UTC | newest] Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-14 0:00 friend classes in ada95 Stefan Folkesson 2000-04-14 0:00 ` Florian Weimer 2000-04-14 0:00 ` Stefan Folkesson 2000-04-14 0:00 ` swhalen 2000-04-14 0:00 ` Julian Day 2000-04-14 0:00 ` Steve Folly 2000-04-14 0:00 ` Robert A Duff 2000-04-17 0:00 ` John J. Rusnak 2000-04-18 0:00 ` Vincent Marciante 2000-04-18 0:00 ` John Rusnak 2000-04-18 0:00 ` Steve Folly 2000-04-14 0:00 ` John J. Rusnak 2000-04-15 0:00 ` Jeff Carter 2000-04-16 0:00 ` Robert Dewar 2000-04-16 0:00 ` Jeff Carter 2000-04-16 0:00 ` David Botton 2000-04-17 0:00 ` Robert Dewar 2000-04-17 0:00 ` Hyman Rosen 2000-04-17 0:00 ` Robert Dewar 2000-04-16 0:00 ` David Botton 2000-04-17 0:00 ` Robert Dewar 2000-04-17 0:00 ` David Botton 2000-04-17 0:00 ` David Botton 2000-04-18 0:00 ` friend classes in ada95 (long) tmoran 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` friend classes in ada95 Stanley R. Allen 2000-04-19 0:00 ` friend classes in ada95 (long) Brian Rogoff 2000-04-19 0:00 ` Hyman Rosen 2000-04-19 0:00 ` Brian Rogoff 2000-04-23 0:00 ` Hyman Rosen 2000-04-23 0:00 ` Brian Rogoff 2000-04-24 0:00 ` Hyman Rosen 2000-04-25 0:00 ` Brian Rogoff 2000-04-25 0:00 ` Ole-Hjalmar Kristensen 2000-04-19 0:00 ` David Botton 2000-04-19 0:00 ` MI, was Re: friend classes in ada95 tmoran 2000-04-19 0:00 ` David Botton 2000-04-18 0:00 ` Geoff Bull 2000-04-18 0:00 ` Jean-Pierre Rosen 2000-04-18 0:00 ` David Botton 2000-04-18 0:00 ` tmoran 2000-04-18 0:00 ` John J. Rusnak 2000-04-19 0:00 ` Geoff Bull 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Ehud Lamm 2000-04-19 0:00 ` Jeff Susanj 2000-04-19 0:00 ` Bill Greene 2000-04-19 0:00 ` tmoran 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Jeff Carter 2000-04-19 0:00 ` Ray Blaak 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` BSCrawford 2000-04-20 0:00 ` Brian Rogoff 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-20 0:00 ` Ray Blaak 2000-04-20 0:00 ` Jean-Pierre Rosen 2000-04-24 0:00 ` Ray Blaak 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ray Blaak 2000-04-20 0:00 ` Charles Hixson 2000-04-21 0:00 ` Jean-Pierre Rosen 2000-04-29 0:00 ` Aidan Skinner 2000-04-29 0:00 ` Robert I. Eachus 2000-04-21 0:00 ` Jon S Anthony 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Jeff Carter 2000-04-21 0:00 ` Robert Dewar 2000-04-21 0:00 ` Jon S Anthony 2000-04-22 0:00 ` Robert Dewar 2000-04-21 0:00 ` Ken Garlington 2000-04-19 0:00 ` David Botton 2000-04-19 0:00 ` Robert Dewar 2000-04-19 0:00 ` Robert Dewar 2000-04-20 0:00 ` Geoff Bull 2000-04-19 0:00 ` Jean-Pierre Rosen 2000-04-19 0:00 ` Robert Dewar 2000-04-18 0:00 ` John Rusnak 2000-04-19 0:00 ` Robert Dewar 2000-04-18 0:00 ` Pascal Obry 2000-04-18 0:00 ` David Botton 2000-04-17 0:00 ` Robert I. Eachus 2000-04-18 0:00 ` Robert Dewar 2000-04-19 0:00 ` Robert I. Eachus 2000-04-20 0:00 ` Robert Dewar 2000-04-20 0:00 ` Ray Blaak 2000-04-23 0:00 ` Robert I. Eachus 2000-04-19 0:00 ` Alfred Hilscher 2000-04-19 0:00 ` Ray Blaak 2000-04-19 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox