>>>>I mean no offense, but this is the crux of the misunderstanding. Objects are not supposed to know *anything* about the innards of each other.
>>>
>>>It's not a misunderstanding. I realize it violates OOP standards. But I tend to look upon them more as guidelines than requirements.
>>
>>Bear in mind this is new code he's doing.
>
>My bad then, I was under the impression that he was doing primarily maintenance work and that this was a change required in an existing system.
>>
>>If the guidelines are followed, things are much easier. It's the too frequent dismissal of the guidelines that make things such a mess.
>>
>>>
>>>I suppose this is an example of the maintenance programmer in me vs. the designer in you. I see the request as "how can I get this done now" and you see it as "how should it have been done in the first place."

I'll go so far as to say that with good practices, not copying code, making reusable modules, we could be far more productive than we are.

>>>
>>>If I were the original designer of Jay's system (unlikely since my design skills are not all that strong), each of the two objects would be properties of the same parent object and you could get the values from This.Parent (Question....in OOP design is an object supposed to know about its parent's methods and properties?).
>
>I'm curious about this question. How much is an object supposed to know about its parent?

Depends what you mean by parent. Containing object? *All* objects are supposed to be designed so they know divulge as little as possible to the outside world, which includes all other objects in the system. At design time we programmers can usually see all of the insides of a given set of modules. At runtime they must not see into each other.

subclass can see whatever it is allowed to see of the superclass by the designer.

>>>
>>>But as a maintenance programmer, I am loathe to uproot the original design to accommodate new requirements. I do understand that this is the way spaghetti systems are built. We'll patch this, then that, then the other thing, etc. until the whole thing is a mess. But each individual decision makes sense in the context in which it was made. To completely re-design a system each time doesn't always make real-world sense, even if it makes the future re-design orders of magnitude harder.
>>>

Yep. Frankenstein's Program. :) Seen many of those.

>>>>I'm always trying to find examples in the real world to demonstrate the problem ... if a sparkplug could access the inside of the gas tank, BOOM and you're dead!
>>>>
>>>Actually, there would be several blown up test cars and I would find another way of getting what I need.

You realize you probably get fired after the first couple of blown up cars?

>>>Question for you........
>>>
>>>If an object shouldn't know about anything other than itself, and if doing what I suggested is wrong then why does the language allow it? My first commandment of programming is "Thou shalt not tempt thy user to commit an abomination." If they shouldn't do something, they aren't allowed to do it. Why not simply restrict visibility within an object only to its own properties and methods?
>>
>>Because programmers are not engineers and would throw little hissy fits if they weren't allowed to do every goofy thing they think of.
>
>Guilty as charged...........and probably about as remorseful (???) as you would expect.

Just joking around. :)

There are lots of reasons. Old habits. Backward compatibility (the worst offender).

I had a discussion recently: public memvars are bad. The often touted solution is use an application object, right? Well guess what? Most people don't hide or protect the properties on said application object which is usually a public var. End result? Public properties on a public variable is NO better than public variables. I believe most people don't understand the implications, and since it works and nobody dies, nobody cares?