Variable Exposure - Epidemic Alert

Started by
35 comments, last by Holy Fuzz 19 years, 8 months ago
Quote:Original post by Jiia
It's possible HolyFuzz was speaking generically; obviously his intention. Variables are "being protected" in both protected and private.


Look again he said:

Quote:Original post by Holy Fuzz
By giving a class protected members, your saying, "Here, look at me! Extend me and make me better!"


So he said data members that have protected access, not public not private but protected.

Quote:Original post by Jiia
What if you need a method to call to perform something that shouldn't be allowed to be accessed anywhere but from a derived type?


Since when did i say methods/functions with protected access was bad? i've beeing talking about data members all along.

Quote:Original post by Jiia
No offense, but are you sure you've actually tried to use these techniques to build something complex enough to realize the issues?


Of course, i've programmed in pascal, vb6, c/c++, dabbled in objective-c, Java, servlets & JSPs, &#106avascript, a lil shell scripting in korn, c-shell, bourne & bash shell, for the intel 8051 micro-controller. My main strengths are in C++ & Java.

I did a computer science degree at uni and we learn this kind of stuff, software architecture & software engineering on top of other things such as computer graphics in opengl.

I've worked on teams before, not on games developement but in other problem domains.

I've done some simple games & 3d applications on my own, nothing major but i'm not a team of programmers you know.
Advertisement
Quote:Original post by snk_kid
Look again he said:

Quote:Original post by Holy Fuzz
By giving a class protected members, your saying, "Here, look at me! Extend me and make me better!"

So he said data members that have protected access, not public not private but protected.

It's possible that's what he meant. It's also possible he meant the variables are to be protected. Are variables not protected in the private section? But why argue over such things?

Quote:Original post by snk_kid
Since when did i say methods/functions with protected access was bad? i've beeing talking about data members all along.

You told me my class-of-methods was just as bad in protected as public. Yet in protected, only derived types can call it's functions. In public, anything can call it's functions. Big difference between public and protected. No difference between a bunch of methods or a class containing a bunch of methods. [being an ass] Except for that one thing that I can't comprehend. [/being an ass]

Quote:Original post by snk_kid
I've done some simple games & 3d applications on my own, nothing major but i'm not a team of programmers you know.

Sounds like you know what you're doing then. I was seriously asking, I wasn't trying to be an ass - just letting you know.

By the way, who needs a team to program a game? The new API stuff that's out now lets any decent programmer with access to GameDev.net construct his/her own advanced 3D engine in about 2 weeks time. It took me 4-5 weeks, but it was my first time touching 3D, and I had never worked with quaternions or matrices before. After the engine is done, the rest is pure funness.
Quote:Original post by Jiia
Quote:Original post by snk_kid
Since when did i say methods/functions with protected access was bad? i've beeing talking about data members all along.

You told me my class-of-methods was just as bad in protected as public. Yet in protected, only derived types can call it's functions. In public, anything can call it's functions. Big difference between public and protected. No difference between a bunch of methods or a class containing a bunch of methods. [being an ass] Except for that one thing that I can't comprehend. [/being an ass]


Please quote me if i ever said instance/class methods/functions but i assure i did not, even one of the code examples i posted had methods as protected. If you thought i write that then you probably never understood anything anyone's written.

Quote:Original post by Jiia
By the way, who needs a team to program a game?


Probably something like Doom 3 or MMRPG, anyone who believes then can write something like that on there own has a screw loose. These kinds of games are by no means a trivial task.

Quote:Original post by Jiia
The new API stuff that's out now lets any decent programmer with access to GameDev.net construct his/her own advanced 3D engine in about 2 weeks time. It took me 4-5 weeks, but it was my first time touching 3D, and I had never worked with quaternions or matrices before. After the engine is done, the rest is pure funness.


There is more to games developement than graphics & graphics APIs.

Seriously this thread is going out of hand. I'm not trying to argue with you but trying to help you to see something that will improve your designs but it seems like you misinterpreted me all along.

[Edited by - snk_kid on August 6, 2004 4:00:26 AM]
Quote:Original post by snk_kid
Please quote me if i ever said instance/class methods/functions but i assure i did not, even one of the code examples i posted had methods as protected. If you thought i write that then you probably never understood anything anyone's written.

Please don't get upset. You're free to stop responding anytime you feel pressured. And please pay more attention to what I'm saying. Class of Methods. As in a class containing methods; it's instance placed in protected within another class. This sub-class will have private members itself. Yes, I believe it would also be fine placed into public, but there is still a huge difference between public and protected.

Oh, and here is your quote, while talking about my CBitFlags class - which has no public or protected data members, but who's instance is to be placed into the protected section of CObject.
Quote:Original post by snk_kid
Think about it thou don't you think that having a data member protected is bit of a contridiction like i was saying in my first post above, by declaring a data member protected your implying that unrelated types/modules can't access but if you sub-type you can, if you do that it may aswell be public but then you need to make sure that the member never changes to avoid updating all other modules and re-compilling & the state invariant is maintained manually.

And again, I will say that something changing in CBitFlags is no different than something changing in CObject. All true data members are still in private sections, only methods are exposed.


Quote:Original post by snk_kid
Probably something like Doom 3 or MMRPG, anyone who believes then can write something like that on there own has a screw loose. These kinds of games are by no means a trivial task.

If you really believe it's impossible to write one on your own, I could only wonder if you've ever tried to actually do it. I'm telling you this as a fact, not as an attempt to rile you: The new DirectX API implimentations make it extremely easy to throw an advanced 3D engine together. By advanced, I'm talking about phyics, Polygon-to-sphere collision, down-to-the-vertex control of Meshes and SkinMeshes with Vertex Shaders, and custom coded lighting with shaders (which is required with the vertex stuff). Take a look at where my first 3D question on GameDev started, and where the last one ended, then I will show you my engine. [boasting] It even has a really cool inverse kinematics posing system in my animation editor; which is pretty fun cause you can grab their hip and wirl them around and they attempt to hold on to stuff. [/boasting] As far as a full game goes, it is far from it. But once this part is done, the Doom / MMORPG stuff is pure game programming. Not engine programming. Meaning the rest is very fun.

Quote:Original post by snk_kid
There is more to games developement than graphics & graphics APIs.

DirectX is not a graphics API. It's a games API. And yes, I agree, but the rest is a simple design process. Well, except physics. I have to admit I hit quite a few bumps trying to understand collisions and such with triangles. But triangles are very closely related to the graphics engine :)

Quote:Original post by snk_kid
Seriously this thread is going out of hand. I'm not trying to argue with you but trying to help you to see something that will improve your designs but it seems like you misinterpreted me all along.

I'm pretty sure I've understood everything you've said. Perhaps it's my fault for not explaining myself more clearly. We are definitely disagreeing on something. You believe that all members are to be treated as data-members. But I believe that a sub-class which already has it's data members protected (as in placed in private :) should be allowed to act as an interface itself, for the main class. Meaning that a "data member" is placed into protected. Yet this member has nothing but methods publically available. This means all true data members are in private, and only methods are exposed to the protected area.
Quote:Original post by Jiia
Quote:Original post by snk_kid
Please quote me if i ever said instance/class methods/functions but i assure i did not, even one of the code examples i posted had methods as protected. If you thought i write that then you probably never understood anything anyone's written.

Please don't get upset. You're free to stop responding anytime you feel pressured. And please pay more attention to what I'm saying. Class of Methods. As in a class containing methods; it's instance placed in protected within another class. This sub-class will have private members itself. Yes, I believe it would also be fine placed into public, but there is still a huge difference between public and protected.

Oh, and here is your quote, while talking about my CBitFlags class - which has no public or protected data members, but who's instance is to be placed into the protected section of CObject.
Quote:Original post by snk_kid
Think about it thou don't you think that having a data member protected is bit of a contridiction like i was saying in my first post above, by declaring a data member protected your implying that unrelated types/modules can't access but if you sub-type you can, if you do that it may aswell be public but then you need to make sure that the member never changes to avoid updating all other modules and re-compilling & the state invariant is maintained manually.


I was being sarcastic, i was trying to get you to see the point, which is a class with data members not member functions but data members in protected access is sign of bad design.

Quote:Original post by Jiia
And again, I will say that something changing in CBitFlags is no different than something changing in CObject. All true data members are still in private sections, only methods are exposed.


Just because CBitFlags encapsulates it's data & maintain it's own state invariant does not mean it prevents CObject from causing tight-coupling if you make it a member in protected access. Your exposing representation to new related-types thus you cause tight-coupling it's upto you if you wont that or not.

Quote:Original post by Jiia
You believe that all members are to be treated as data-members. But I believe that a sub-class which already has it's data members protected (as in placed in private :) should be allowed to act as an interface itself, for the main class. Meaning that a "data member" is placed into protected. Yet this member has nothing but methods publically available. This means all true data members are in private, and only methods are exposed to the protected area.


If you believe that then technically all of your types should put there data members in protected access because even the built-in types such as integer have an inteface that is there operations such as arithemtic operations, construction, assignement etc, they do not expose there representation, to a certain degree they maintain there state invariant aswell.
Quote:Original post by snk_kid
Quote:Original post by Jiia
You believe that all members are to be treated as data-members. But I believe that a sub-class which already has it's data members protected (as in placed in private :) should be allowed to act as an interface itself, for the main class. Meaning that a "data member" is placed into protected. Yet this member has nothing but methods publically available. This means all true data members are in private, and only methods are exposed to the protected area.


If you believe that then technically all of your types should put there data members in protected access because even the built-in types such as integer have an inteface that is there operations such as arithemtic operations, construction, assignement etc, they do not expose there representation, to a certain degree they maintain there state invariant aswell.

Please try to understand that I'm not saying all data-members of a class type with built-in interfaces can go in public/protected. I'm saying in this situation, derived types need exposed to the CBitFlag interface in the first place, so why try to complicate things by adding yet more functions?

Okay, one last time. There are only three ways I know to go about this.

Method #1: Have CObject return a reference of CBitFlag (your suggestion). CBitFlag instance must be declared in private, meaning any modules using CObject are exposed to CBitFlag.
Method #2: Re-write all of CBitFlags methods into CObject, making an interface to it's interface. This also requires CBitFlag be a private member of CObject, also exposing it. Unless a forwardly declared pointer is used instead. So re-write an entire interface, and be forced to allocate the instance.
Method #3: Leave the CBitFlags instance in protected. It's interface is available, and that's it. And that's all that needs to be available. Nothing else needs written. All data is still privately protected.

Both methods 1 and 3 expose the CBitFlag class to any routines seeing CObject. And method 2 will do the same if the CBitFlag member is declared as a non-pointer. This means compile times are most likely going to be the same with all three methods. If the data members in CBitFlag change, this is no different than if the data members of CObject change. If the routines in CBitFlag change, this is no different than if the routines in CObject change.

One exception is if you forwardly declared the pointer to CBitFlag and declared it in private as a pointer, and create an interface to return it's address (GetFlags()->TurnOn(STATUS_DEAD)). So a combination of #1 and #2. But this only decreases compile tiles. There is no difference in encapsulation/modulation. All derived objects still need exposed to CBitFlag.

Please tell me where I'm wrong. I might be slightly stubborn, but I'm not willing to use something that many people will frown upon. I really appreciate your perseverance.

EDIT: Spelling

[Edited by - Jiia on August 7, 2004 2:08:03 AM]
LOL, yeah, that's what I get for ignoring a thread for a couple days. :-)

Quote:LOL @ Fuzz! You did that just for a rating, didn't you? It was a damn good analogy, so you get it.


Wow, thanks. I don't know what to say to that. :-) No, I didn't do it for the rating; I didn't even know what my rating was till you reminded me just now.

Quote:It's possible HolyFuzz was speaking generically; obviously his intention. Variables are "being protected" in both protected and private.


No, I meant protected as in the keyword "protected," not generically. Sorry for the confusion.

Quote:No it doesn't, the whole point of inheritance is to extend behaviors/services not representation.


I don't get what you're trying to say... did *I* say something about representation? I thought I was talking about extending behaviors... *shrugs*

Ta ta,
- Fuzz

This topic is closed to new replies.

Advertisement