24 Jul, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
so,
i have completed my g++ cleanup of my QuickMud variant. If anyone wants a copy let me know and i can
send you one.

At this point i have been mostly playing around with C++'s cool features, and i am planning on adding some cool stuff.
First of all, i was planning on converting the pc_data structure into a class, and taking all of the handler.c functions and making them into class methods. I'm wondering, has anyone out there done this? I'm still trying to figure out if its worth the time.
24 Jul, 2009, Davion wrote in the 2nd comment:
Votes: 0
Someones always looking for C++ stuff :) You should just release it staryavsky!
24 Jul, 2009, David Haley wrote in the 3rd comment:
Votes: 0
It's not really worth the time if all you do is make public functions into public methods, and leave all the data members as public. You've cleaned it up a little and saved some work for the next guy who cares, but you haven't really accomplished much.

I find that it's far more productive to refactor these things gradually as you modify particular pieces of code. For example, if you want to change stat caps, you could make the stats private fields, and then expose an interface to those stats and get rid of the stuff in handler.c.

In the end of the day, there's just not a lot of point in "encapsulating" things into a class if everything stays public, or if you make all fields private but then add transparent getter/setter methods. With just that, you haven't really changed anything – although, yes, you have done the grunt work necessary for when somebody wants to do something that's actually interesting later on.
24 Jul, 2009, JohnnyStarr wrote in the 4th comment:
Votes: 0
Ok, well as where i agree, i never claimed i did anything "interesting".
I am personally more interested in the string capabilities and such. I suppose my post was just
to see if anyone had a road map for actual changes they have made to their projects. As where
encapsulating may change the overall structure of the codebase, it would be nice to know what has been
done by others and not would could be done. Of course, no offense to David, i always appreciate your
honesty. :biggrin:
24 Jul, 2009, David Haley wrote in the 5th comment:
Votes: 0
I just gave you examples of the changes I have made, and a roadplan for future changes to make or consider. :smile:
25 Jul, 2009, JohnnyStarr wrote in the 6th comment:
Votes: 0
ok then, i didnt really gather that from your words, but fair enough.
for the most part, i'm starting to build a bit more faith in structured programming.
from most of the reading i've done on OOP, it pretty much "dogs" anything but OOP, but
as far as maintainability, IMO if an application is large, but structured well, it isnt
hard to maintain, although i do see the benefits of encapsulation and having an interface
to data members, it does seem like too much of an undertaking to make everything
follow the paradigm.
25 Jul, 2009, David Haley wrote in the 7th comment:
Votes: 0
I'll admit that I was a little brief and you needed to expand it out yourself. The point is that you don't want to make things follow the paradigm just for the sake of following the paradigm. If you take a structure, make everything private and then add transparent getter/setts, and do nothing else, then you really haven't accomplished anything. The only thing you've done is saved a little work for somebody who comes later and wants to actually make those methods be more interesting.

Compare:

struct S1 {
int a;
};
struct S2 {
private:
int a;
public:
int getA() { return a; }
void setA(int a) { this->a = a; }
};


There's no functional difference between these two structures, except that S2 causes more typing. Compare with:

struct S2 {
private:
int a;
public:
int getA() { return a; }
void setA(int a) {
this->a = min(a, 100);
}
};


At least now the interface is doing something "interesting" (as interesting as contrived examples can get), but in any case the interface is now enforcing some kind of constraint on the values you can set. Now there is a functional difference.

But you're taking things a little far when you imply that encapsulation isn't actually that valuable. It is in fact invaluable; I posit that it is almost impossible to have a well structured program with some kind of distinction between public and private interfaces. It's not that you need to have C++/Java visibility enforcement, but a programmer must have some means of knowing how s/he is supposed to talk to the various modules, objects, etc.

So if you go forth and make all members private but add transparent getters/setters, I argue that you have basically wasted your time. It is far more productive to encapsulate things as you work on them, as you find need to encapsulate them. Otherwise you can end up spending weeks or months changing occurrences of ch->name to ch->getName() – whee. :rolleyes:
Now, it'd be far more interesting if ch->getName() were to return something different based on the circumstances – perhaps actors can pick stage names while performing a play in the town square? – and now there is a real opportunity to encapsulate the value with a functional difference.
25 Jul, 2009, JohnnyStarr wrote in the 8th comment:
Votes: 0
so if i understand your point David, its best to encapsulate what i add to the mud, and not go back and change everything else. Say i was to add a QUEST system, i could
take advantage of something like ch->add_quest(q); where q would be the quest, allowing us to enforce constraints like managing quest points, logs, and all that.

BTW, i didnt at all mean to come across that i think encapsulation isnt useful. i was just saying that personally i've enjoyed connecting the dots and have found that
the oldschool C Diku stuff isn't as horrible as some people claim, at least not
when you can grasp whats going on.
26 Jul, 2009, Runter wrote in the 9th comment:
Votes: 0
staryavsky said:
BTW, i didnt at all mean to come across that i think encapsulation isnt useful. i was just saying that personally i've enjoyed connecting the dots and have found that
the oldschool C Diku stuff isn't as horrible as some people claim, at least not
when you can grasp whats going on.


Keep in mind encapsulation could have be done with in C with Diku. Also, as you know, I think David pointed out the most compelling reasons for encapsulation aren't throwing variables arbitrarily behind wrappers. In OOP the ability to separate state of private data from public methods is key. Ergo, one could separate the implementation from the results—this not only protects the user (which may be yourself) but also makes them blissfully ignorant of even what state may exist or be redesigned in the future.

Edit: Also a little tidbit of information for you. In C++ struct refers to the same thing as class with one caveat. Struct defaults to public. Although, often people use the convention of structs behaving as plain-old-datatypes without any class functionality. (Which is probably good practice.)
26 Jul, 2009, David Haley wrote in the 10th comment:
Votes: 0
Yes, what Runter said. The C code has a lot of encapsulation issues, and interfaces are not respected very well at all.

It's not that you should only encapsulate new things: you should encapsulate old things as you find reason to do so. Turning S into S2 in my post above does nothing other than appease the OOP gods by enforcing ritual typing to access data members. But S3 actually does something useful, or at least functionally different. Any new code absolutely should be written cleanly, but you don't need to rewrite the entire codebase just to blindly follow some paradigm.
26 Jul, 2009, Runter wrote in the 11th comment:
Votes: 0
David Haley said:
Yes, what Runter said. The C code has a lot of encapsulation issues, and interfaces are not respected very well at all.

It's not that you should only encapsulate new things: you should encapsulate old things as you find reason to do so. Turning S into S2 in my post above does nothing other than appease the OOP gods by enforcing ritual typing to access data members. But S3 actually does something useful, or at least functionally different. Any new code absolutely should be written cleanly, but you don't need to rewrite the entire codebase just to blindly follow some paradigm.



This kinda reminds me of the misconception a lot of people have that once you use a C++ compiler you're doomed to having to rewrite your entire codebase. Perhaps to appease those Gods as well. :P
26 Jul, 2009, JohnnyStarr wrote in the 12th comment:
Votes: 0
Runter said:
This kinda reminds me of the misconception a lot of people have that once you use a C++ compiler you're doomed to having to rewrite your entire codebase. Perhaps to appease those Gods as well. :P


Thanks guys for your insight, just trying to chip away at the mystery 1 step at a time :smirk:
0.0/12