- polymorph? - 15 Updates
- OT: Association for Orthodox Jewish Scientists - 4 Updates
- didactics of reference parameters[Supersedes] - 6 Updates
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 20 11:02PM -0400 On 3/20/2016 1:36 PM, Mr Flibble wrote: >> hint for you: look into virtual inheritance. Keyword: diamond pattern. > Try again Victor: virtual inheritance is NOT appropriate here. > /Flibble Actually, Victor is correct. You are not. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 20 11:09PM -0400 On 3/20/2016 7:01 AM, Jens Kallup wrote: > how many objects are present? > TIA > Jens I think your problem here is one of understanding. Inheritance is always a "type of" relationship - that is, both Rectangle and Circle are a "type of" shape. However, "PositionOfShape" is not a type of Shape - it is an attribute of a Shape. So it should be an attribute of Shape, not a derived class. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 20 11:26PM -0400 On 3/20/2016 4:24 PM, Öö Tiib wrote: > properties are those of DrawnThingy. > * Rectangle and Circle have some common to both component DrawingTools. > There are no way out of that puzzle without brain power applied. Both are Shapes. And deriving from Shape would be correct. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 21 08:01AM +0100 On 20.03.2016 12:01, Jens Kallup wrote: > Hello, That's what President Obama also said at the start, in his yearly speech to the Iranians, now two or three days ago. > Properties > - Color > - Brush... Nice but misleading ASCII artwork. The connecting lines denote quite different forms of relationship, as I see it. For presumably a Rectangle IS a Shape, for example, while a Shape HAS a Position, or HAS a Color. This is one basic thing you need to be careful with, and keep in mind that beginners have a tendency to incorrectly model HAS as IS. Essentially then, Shape HAS a position HAS a line color HAS a background brush Rectangle IS a Shape Circle IS a Shape Next you need to think hard about whether such objects are pure VALUES or MUTABLE (objects whose values can be modified). If they are pure values, like numbers, then a Circle can be a kind of Ellipse, because it has all the properties of an Ellipse. It's just a subset of ellipses. The other way doesn't work, because it's not the case that every Ellipse or most Ellipses has exactly one radius. But if they are mutable, then if a Circle were derived from Ellipse then one could presumably use some modifier function of Ellipse to make that Circle elongated, decidedly un-Circle like. And thus breaking the class invariant of Circle. And so with mutable objects it's impractical to derive Circle from Ellipse. Instead one can offer conversions between these classes. A conversion from Circle to Ellipse will always succeed except for e.g. memory exhaustion. > I think each class (Rectangle, and Circle) have same standard > properties. Can i specialize it in sub class? A derived class is a specialization. It is also an extension. > Like radius of Circle, and radius of borders circle (as example)? If you're talking about radius of borders then that doesn't sound very reasonable. > Is it possible to iterate through Shape to know how many objects are present? If you put these objects in a collection, yes. Cheers & hth., - Alf |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 04:34AM -0700 On Sunday, 20 March 2016 11:01:16 UTC, Jens Kallup wrote: > Properties > - Color > - Brush... Yes, you can, and it's not a case of multiple inheritance, as others have said. A design issue: a class named "Position of shape" should not be a parent of Rectangle/Circle. You may want to have Rectangle/Circle inherit from Shape, and have your properties (color, brush, positition, etc...) as members of Shape. You can have a collection of Shape that can either be Rectangle's or Circle's and invoke specific behaviours through polymorphism. A good question you should ask yourself is whether a Square should inherit from Rectangle or vice versa :) |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 04:36AM -0700 On Monday, 21 March 2016 03:09:42 UTC, Jerry Stuckle wrote: [..] > I think your problem here is one of understanding. Inheritance is > always a "type of" relationship - that is, both Rectangle and Circle are > a "type of" shape. To be fair, 'inheritance' and 'subclassing' are not necessarily the same concept, at least in theory (see "A Theory of Objects" by Cardelli-Abadi). |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 06:20AM -0700 On Monday, 21 March 2016 07:01:42 UTC, Alf P. Steinbach wrote: >a Circle can be a kind of Ellipse, because it has all the properties of an Ellipse. It's just a subset of ellipses. The other way doesn't work, because it's not the case that every Ellipse or most Ellipses has exactly one radius. Well, it's not that simple, IMO. I agree that circles can be considered subsets of eclipses, but the idea that a sub-type *restricts* the base type is not intuitive at all. It should be quite the opposite: the sub-type *extends* the base type. Therefore it is not wrong, IMO, to think of an eclipse as an *extension* of a circle, as it just extends a circle's contract. |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 09:42AM -0400 On 3/21/2016 7:36 AM, Zaphod Beeblebrox wrote: >> always a "type of" relationship - that is, both Rectangle and Circle are >> a "type of" shape. > To be fair, 'inheritance' and 'subclassing' are not necessarily the same concept, at least in theory (see "A Theory of Objects" by Cardelli-Abadi). Nobody was talking about subclassing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 09:43AM -0400 On 3/21/2016 9:20 AM, Zaphod Beeblebrox wrote: > subset of ellipses. The other way doesn't work, because it's not the > case that every Ellipse or most Ellipses has exactly one radius. > Well, it's not that simple, IMO. I agree that circles can be considered subsets of eclipses, but the idea that a sub-type *restricts* the base type is not intuitive at all. It should be quite the opposite: the sub-type *extends* the base type. Therefore it is not wrong, IMO, to think of an eclipse as an *extension* of a circle, as it just extends a circle's contract. Actually, that is true. A derived class is a more specific case of the base class. For instance, Person->Employee->Manager. All Managers are Employees and all Employees are Persons, but the other way does not work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 08:31AM -0700 On Monday, 21 March 2016 13:44:09 UTC, Jerry Stuckle wrote: [...] > Actually, that is true. A derived class is a more specific case of the > base class. "More specific" does not mean that it *restricts* the contract. It's quite the opposite. An employee is a more specific case of a person but it "extends" the contract of a person by adding the "attribute" of being an employee. So does a Manager with respect to Employee. It is an extension, not a restriction. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 08:32AM -0700 On Monday, 21 March 2016 13:42:16 UTC, Jerry Stuckle wrote: [...] > Nobody was talking about subclassing. >Rectangle and Circle are a "type of" shape. *YOU* are talking about subclassing. |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 12:14PM -0400 On 3/21/2016 11:32 AM, Zaphod Beeblebrox wrote: >> Nobody was talking about subclassing. >> Rectangle and Circle are a "type of" shape. > *YOU* are talking about subclassing. Nope, I'm talking about inheritance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 21 12:17PM -0400 On 3/21/2016 11:31 AM, Zaphod Beeblebrox wrote: >> Actually, that is true. A derived class is a more specific case of the >> base class. > "More specific" does not mean that it *restricts* the contract. It's quite the opposite. An employee is a more specific case of a person but it "extends" the contract of a person by adding the "attribute" of being an employee. So does a Manager with respect to Employee. It is an extension, not a restriction. More specific by definition means further restrictions. It has nothing to do with the attributes; the derived class may or may not have additional attributes or it may hide attributes in the base class. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 09:24AM -0700 On Monday, 21 March 2016 16:14:22 UTC, Jerry Stuckle wrote: [...] > Nope, I'm talking about inheritance. Okay, you need to make things clear in your mind and stop arguing just for the sake of it. If you say "Inheritance is always a 'type of' relationship", you are saying that inheritance is always sub-typing, therefore is always sub-classing. |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Mar 21 09:32AM -0700 On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote: [...] > More specific by definition means further restrictions. "More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends. > It has nothing to do with the attributes; the derived class may or may not have > additional attributes or it may hide attributes in the base class. I am not talking about the class members. I used quotes around that noun. I am talking about 'the attribute of being an Employee'. You qualify a person as an "employee". This specializes a person and, at the same time, *extends* a person with the attribute of being an employee. So does a manager with regard to an employee. A person is a person. An employee is a person *AND* an employee. A manager is a person, *AND* an employee, *AND* a manager. Each sub-type extends the base type, though it gets more and more specialized. |
| David Brown <david.brown@hesbynett.no>: Mar 21 09:19AM +0100 > Years ago I worked at IBM, American Express and > Southwest Airlines. This was before they drifted > away from the biblical understanding of marriage. These are /companies/. A company or business is only concerned about one thing in regard to marriage - how does it affect our employees ability to do their work? If it makes the employees happy, then that's great - they will probably do a better job. The company does not care if the employees are marrying men, women, or little green men from out of space - as long as they are doing their job and avoiding anything illegal. You can choose how /you/ want to live your life, and what type of person (if any) /you/ want to marry - but you don't get to pass judgement on the choices of other people. If Jesus were alive today, he'd turn in his grave at the hatred and bigotry spewed by some people - especially concerned people's love. Try reading the important parts of the Bible - the Gospels. Forget the cryptic nonsense, myths, invented self-serving "history", and bizarre rules of the OT. Forget the rantings of that angry little chauvinist Paul. Look at what /Jesus/ said. It is all about love and tolerance, care and consideration, and the only people Jesus ever condemns are those that judge others and try to enforce their man-made rules to promote anger, hatred, judgement and vengeance instead of kindness, goodness and love in others. There is a great deal about religions, religious beliefs, and many (but certainly not all) religious practitioners that bothers me. Few things are worse than people who call themselves Christians, yet go so far against the teachings of Jesus. |
| seeplus <gizmomaker@bigpond.com>: Mar 21 02:52AM -0700 On Monday, March 21, 2016 at 7:19:52 PM UTC+11, David Brown wrote: > those that judge others and try to enforce their man-made rules to > promote anger, hatred, judgement and vengeance instead of kindness, > goodness and love in others. Except where he goes into a friggin rage overturning stuff because people are selling doves etc Matt 21:12, and of course when he doesn't show much love for a fruit tree and rages against a poor bloody tree and gives it the old J curse because he could not get any fruit off it. Matt 21:18 etc etc ... and 100s of other equal stupidities. |
| woodbrian77@gmail.com: Mar 21 08:56AM -0700 On Monday, March 21, 2016 at 4:52:52 AM UTC-5, seeplus wrote: > > goodness and love in others. > Except where he goes into a friggin rage overturning stuff because people are selling doves etc Matt 21:12, > and of course when he doesn't show much love for a fruit tree and rages against a poor bloody tree and gives it the old J curse because he could not get any fruit off it. Matt 21:18 etc etc The following is from this page: https://www.apologeticspress.org/apcontent.aspx?category=11&article=1956 "Jesus often insisted that trees which do not bear good fruit will be cut down (Matthew 7:19; Luke 13:6-9). The fig tree did not bear fruit, was useless, and deserved to be destroyed: the spiritual application being that any human who does not bear fruit for G-d will also be destroyed for his or her failure to produce." Brian Ebenezer Enterprises http://webEbenezer.net |
| Daniel <danielaparker@gmail.com>: Mar 21 09:10AM -0700 > "Jesus often insisted that trees which do not bear good fruit > will be cut down (Matthew 7:19; Luke 13:6-9). Interesting. But couldn't the same be said about C++ Middleware Writer? Daniel |
| woodbrian77@gmail.com: Mar 20 04:53PM -0700 On Sunday, March 20, 2016 at 6:14:12 PM UTC-5, Ian Collins wrote: > > the responsible thing to do. > No it isn't. No sane developer would create their own top level > namespace called "std". Someone might do it by accident, or out of ignorance or malice. Brian Ebenezer Enterprises - An ounce of prevention is worth more than a pound of cure. http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: Mar 20 05:16PM -0700 > > No it isn't. No sane developer would create their own top level > > namespace called "std". > Someone might do it by accident, or out of ignorance or malice. We typically want fastest feedback possible about such ignorance, accidents and/or malice taking part in our code-bases. Or don't we? |
| Ian Collins <ian-news@hotmail.com>: Mar 21 01:23PM +1300 >> No it isn't. No sane developer would create their own top level >> namespace called "std". > Someone might do it by accident, or out of ignorance or malice. The former is unlikely and would be quickly spotted, the later could apply to anything such as a nasty #define. Neither justify cluttering code with unnecessary clutter. -- Ian Collins |
| woodbrian77@gmail.com: Mar 20 05:52PM -0700 On Sunday, March 20, 2016 at 7:16:52 PM UTC-5, Öö Tiib wrote: > > Someone might do it by accident, or out of ignorance or malice. > We typically want fastest feedback possible about such ignorance, > accidents and/or malice taking part in our code-bases. Or don't we? I guess so, but I don't really understand what you are saying. |
| Jerry Stuckle <jstucklex@attglobal.net>: Mar 20 10:59PM -0400 On 3/20/2016 7:13 PM, Ian Collins wrote: >> the responsible thing to do. > No it isn't. No sane developer would create their own top level > namespace called "std". Remember who you're talking about, Ian... :) -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Öö Tiib" <ootiib@hot.ee>: Mar 20 08:06PM -0700 > > accidents and/or malice taking part in our code-bases. Or don't we? > I guess so, but I don't really understand what you are > saying. I meant that fastest feed-back are IDE underlying things red or compiler errors about conflicts. The '::std' cooperates with potential ignorance, accidents and/or malice by avoiding such compiler errors. People see that it also clutters the code in process with needless colons. Something is controversial about "most responsible thing to do" here. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment