| Author |
 Topic  |
|
ravensOrb
Tomato Guru
136 Posts |
 Posted - Feb 24 2004 : 09:25:38 AM
|
This may be a little outside of the scope of VAX, but I figured I'd offer it as a suggestion anyway 
It would be a really cool feature if I could do something like highlight a member variable and right click to auto create a public get/set property and leave the cursor at the place where I type in the name of the property.
Just a thought... |
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 24 2004 : 09:41:01 AM
|
If you're going to make a public getter and setter, why not just make the member variable public? For some kind of framework that requires getters and setters? Just curious...
|
 |
|
|
ravensOrb
Tomato Guru
136 Posts |
Posted - Feb 24 2004 : 10:26:45 AM
|
One work: encapsulation
It is always better to wrap all member variables. That way you can change/add behavior at any time with zero impact on existing code... |
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Feb 24 2004 : 11:11:41 AM
|
i think you could do this by writing a code template that uses the hightlighted variable name as variable %0. the code templates seem very powerful  |
zen is the art of being at one with the two'ness |
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 24 2004 : 11:20:19 AM
|
Um, no, and that's why I asked. Not trying to be rude, but there's no difference between having public getter and setter members and having public data. Wrapping with public getters and setters provides only the illusion of encapsulation, not real encapsulation. It took me several years to really "get" that.
Maybe someone else can jump in here with a good reference to OO programming. The only one I can think of off the top of my head is the Gang of Four book ("Design Patterns", Gamma et al.): it changed the way I program.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Feb 24 2004 : 11:32:18 AM
|
now i am curious. why doesn't this provide encapsulation? i am mostly a C programmer, so my OO theory is currently weak.
i did a course on Smalltalk a few years ago, and one of the few things i remember is that all member variables are private, and the course simply referenced them with public getters and setters. they did then illustrate changing the way the setters worked, to illustrate why this was a good idea. |
zen is the art of being at one with the two'ness |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Feb 24 2004 : 11:56:51 AM
|
I disagree with Larry. If you use protected data members with public functions to access them, you can later change the setter to have side-effects if you want, or make the getter extract the old data from a more complex data structure, without changing other classes.
However, he is right that if you do this you are defeating privacy. That's why I cringe when people add getters and setters for all their data members as a matter of course. It's also why I don't think VA should include the feature ravensOrb proposed, although I think other people have asked for it too. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Feb 24 2004 : 12:04:17 PM
|
| I guess another way to say it is that encapsulation is about more than privacy. It's also about providing a clean interface into the class. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 24 2004 : 12:36:47 PM
|
I'm really poor at explaining things like this, so I tried to google for phrases like "code to the interface", "double-dispatch", etc., to no avail. The problem is, I learned OO programming over a period of several years, and mostly from websites and other people's code, not from books, so I don't have any book references to share.
I'm really hoping that someone here can point us all to a good tutorial on this subject, as it really represents the major step in a C++ programmers development. It's like that moment when you learn to ride a bike without training wheels: it suddenly changes everything.
In the meantime, here's a link to Allen Holub's article on this subject: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html Yeah, it's Java, but the concepts are so fundamental that you'll forget he's not talking about C++. Be forewarned that a lot of people don't like his writing style, but I've read one of his books and a few articles, and he seems to me to be on the mark almost all the time. Just my opinion, though.
Feline, I'm not surprised that you were taught that. I've been doing C++ since 1995, and it took me probably four years of coding C++ every day until I understood enough of the language to start thinking about object-orientation. Every C++ programmer I've ever known has started out that way: private data members with public getters/setters. And eventually we've all come to laugh/shudder at the memory of it.
Maybe I can come up with an example from some of my real code, which is going to have to be C++/MFC, I'm afraid. Let's say you have a "list control" and some kind of data source that can populate it. A "C" programmer (and a new C++ programmer) would do something like this:
MyDataSource datasource;
MyListControl listcontrol;
while (datasource.HasMoreRows()) {
DataRow row(datasource.GetNextRow());
CString sName(row.GetName());
listcontrol.AddRow(sName);
}
The "C" programmer might think this is a good way to program this, and so uses this code in, say, 1000 places in the huge application they're working on. But let's ask a question: what happens when (not if) the boss says, "We have to display not just the name, but also the zipcode - by tomorrow"? Yikes - you have to re-write 1000 places in the source code; you're screwed. But what if we had coded it this way instead?
// We call it (in 1000 places) like this:
MyDataSource datasource;
MyListControl listcontrol;
listcontrol.AddRows(datasource)
// And here's the MyListControl::AddRows() implementation.
void MyListControl::AddRows(MyDataSource& rDataSource)
{
while (rDataSource.HasMoreRows()) {
DataRow row(data.GetNextRow());
row.InsertYouselfIntoThisControl(this);
}
}
// Here's the code in the DataRow class.
void MyDataRow::InsertYouselfIntoThisControl(MyListControl* plistcontrol)
{
CString sText(m_sName);
plistcontrol->AddRow(sText);
}
There are a couple of things to notice here. First, the 1000 places we call it from are all immune to changes in how MyDataSource and MyListControl interact. I mean, it's just three lines, with no coupling between them:
MyDataSource data;
MyListControl listcontrol;
listcontrol.AddRows(data)
Second, to add the zip code to the display, we only have to change one place: the MyDataRow::InsertYouselfIntoThisControl() method. Notice how the list control class is immune to changes from the data source class, and vice versa.
Third, this is just the first step. Imagine if MyListControl were derived from an abstract base class called IMyControl, and MyDataSource were derived from an ABC called IDataSource. Then you could pass around pointers to IMyControl and IMyDataSource; that way, you could change controls (to, for example, MyTreeControl), and you could change data sources (to, for example, MyXMLDataSource) without practically zero changes to source code.
I do the above kind of thing all the time: it's wonderful to be able to spend a day implementing something that works with list controls, and then five minutes each extending it to work with tree controls, list boxes, and comboxes. Or, getting it to work with database cursors, then quickly extending it to work with ASCII text files and XML files. The first time you do it, it makes a believer out of you.
I'm sure this example has about a million flaws, as I just typed it in on the spot, but it should be enough to get you thinking.
|
Edited by - LarryLeonard on Feb 24 2004 12:46:41 PM |
|
|
|
Torsten
Junior Member
Germany
20 Posts |
Posted - Feb 24 2004 : 2:16:20 PM
|
Sorry,
I could not get your point Larry.
The starting point of the discussion was whether exposing public fields infringes encapsulation. Of course it does.
If your clients interact directly with your member variables, you are exposing implementation details to them and enforce them to be coupled tightly to your implementation.
If you later decide that you will not store the value directly in your object, but say want your object ask another object to handle over the value upon a client request, all your clients have to be changed.
But when you hide the implementation begind an interface of get/set or properties, you decouple your client from your implementation and the described change would be opaque for them.
The example you gave is - in my opinion - a different story. This is about which object is responsible for what and where you want to have generic behavior. And really generic behavior is hard to get. Should your control be responsible to get the information it want out of the control or should your datarow be responsible to insert its own values into a control? I think it depends on the specific details of your implementation and possible extensions in the future. What if you have data sinks that do not fit with your IMyControl interface - either if they just want the name and not the zip or they want to have the zip process it ann... Anyway your solution may be sensible with your application, but may be not with different ones. And to come back to the point this absolutely does not discredit getter and setter in the light of encasulation.
ok enough for this bit of off-topic thoughts,
-Torsten
|
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 24 2004 : 2:27:59 PM
|
quote:
But when you hide the implementation begind an interface of get/set or properties, you decouple your client from your implementation and the described change would be opaque for them.
I'm sorry, but that's absolutely incorrect, and I think my example, and Holub's article, demonstrated that (with varying degress of clarity).
|
|
|
|
Torsten
Junior Member
Germany
20 Posts |
Posted - Feb 24 2004 : 4:49:01 PM
|
Ok I thought of that again.
You are right that exposing as little of your object's internals as possible. This fits with Scott Meyers Definition of encapsulation ('How Non-Member Functions Improve Encapsulation', C++ Users Journal, Feb. 2000):
quote:
...a reasonable way to gauge the amount of encapsulation in a class is to count the number of functions that might be broken if the class's implementation changes.
With respect to this, neither exposing a field publically nor make it availlable through getters/setters at all makes a class more encasulated. I.e. avoid any unecessary access to your class' data.
But in the cases that you have to make some data accessible to clients (and it is not always avoidable) it is always better to make these accessible through getters/setters. And this is also stated by Holub in his 'When is an accessor okay?' part.
But again, if you can distribute your responsibilities such that your class have not to expose some fields, but is responsible itself to spit out it's data in an appropiate way, that's best, and your point is sound.
-Torsten |
|
|
|
willdean
Tomato Guru
134 Posts |
Posted - Feb 24 2004 : 4:58:17 PM
|
Larry, this isn't nearly so black and white as you say. Certainly not to the degree of being able to claim someone is 'absolutely incorrect'.
Lots of Get/Set isn't great, and there are often better ways of doing things. But it *is* better than merely making the variables public. There are a heap of things you can do with Get/Set which you can't do with public member variables. Many of these *decrease the coupling* of the producer and the consumer.
They don't *completely decouple* it, but then nor does anything else. It's a continuum, with global variables, public data members, getters/setters, and whatever people *today* consider to be *truly* object orientated all occupying different positions on that continuum.
Unless we have reached some really new point in programming, I predict that in 10 years time, people will be looking at current advocated style and criticising it roundly.
|
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 24 2004 : 5:36:42 PM
|
willdean, I have to disagree. The naive use of getters and setters in the mistaken belief that they somehow usefully decrease coupling is simply a misunderstanding of the meaning and purpose of encapsulation. Sure, using a getter in some trivial way reduces coupling, but that's like saying being shot with a .38 is better than being shot by a .45. To argue such is to miss the point that being shot is very bad; I tried to demonstrate one way to begin thinking about how to dodge these bullets.
Put another way: it's not that getters and setters are bad (though they are); it's that, if you're using getters and setters, your're doing the kind of OO stuff I demonstrated. Whether getters/setters are really bad, often good, sometimes lovable, sometimes evil, etc. is not my point.
And I agree that someday our descendants will laugh at our pitifully archaic practices; that does not mean, however, that all of our practices are equally good.
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Feb 25 2004 : 04:28:27 AM
|
| I think we all agree that some people make getters and setters too readily, and destroy encapsulation. But the question is whether if you do need to expose one of the data members of a class — and sometimes that really is the best design — it's better to make the member public, or to make it protected and expose it through accessor functions. I know which I prefer. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Feb 25 2004 : 07:42:52 AM
|
quote:
Originally posted by LarryLeonard
Maybe I can come up with an example from some of my real code, which is going to have to be C++/MFC, I'm afraid.
*gob-smacked expression*
i am a self taught C and C++ programmer, and a lot of what i have learnt i learnt the hard way 
it took a bit of thinking, but i am going to print out this example and keep it on hand. i am not sure how quickly or globally i can learn apply this idea, but i can definitely see your point.
i like to try and hide as many details as possible in my C code. i have already learnt just how much work exposing things can cause when you have to make a load of changes 6 months later *sigh* this shows how to take this to a whole new level  |
zen is the art of being at one with the two'ness |
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 25 2004 : 09:38:49 AM
|
Torsten said:
quote:
if you can distribute your responsibilities such that your class have not to expose some fields, but is responsible itself to spit out it's data in an appropriate way, that's best
That's what I was trying to say, but couldn't express it.
I've bookmarked that article by Meyers, and will read it soon. His "Effective C++" and "More Effective C++" books are excellent, I think, so I'm sure this will be too. Thanks for the pointer.
|
|
|
|
Uniwares
Tomato Guru
Portugal
2321 Posts |
Posted - Feb 25 2004 : 09:44:35 AM
|
quote:
Originally posted by LarryLeonard
I do the above kind of thing all the time: it's wonderful to be able to spend a day implementing something that works with list controls, and then five minutes each extending it to work with tree controls, list boxes, and comboxes. Or, getting it to work with database cursors, then quickly extending it to work with ASCII text files and XML files. The first time you do it, it makes a believer out of you.
I'm sure this example has about a million flaws, as I just typed it in on the spot, but it should be enough to get you thinking.
OK, let me add now a few thoughts to this already very interesting thread (does it belong to this forum anyway?  ).
Although your approach is a big leap forward by means of OO programing, to really reach the top of OO abstraction you would create an inserter class which even releases the listcontrol implementation of knowing anything about the data class.
Or, simpler, implement iterators in the data class. you could write code like:
void MyListControl::AddRows(MyDataSource& rDataSource)
{
MyDataSource::iterator i = rDataSource.begin();
while (i != rDataSource.end())
{
i->InsertYouselfIntoThisControl(this);
++i;
}
}
Another, even more elegant solution would be to implement streams:
MyDataSource datasource;
MyListControl listcontrol;
listcontrol << datasource;
Have a look at Design Patterns and using template classes (Josuttis and Vandervoorde) to get a good idea. I admit it is hard to get the grip on these concepts, but once you do, programing is not more the same.
A good start for read into these topics is also
http://www.codeproject.com/cpp/
http://www.codeproject.com/vcpp/stl/ (great stuff here)
|
Edited by - Uniwares on Feb 25 2004 09:58:21 AM |
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 25 2004 : 09:48:33 AM
|
feline said:
quote:
I am not sure how quickly or globally i can learn apply this idea...
Here's two tricks that work for me.
First, make all data members protected or private, and simply don't write any getters or setters. You'll be forced to code it up in a (more) OO way: without getters or setters, you'll have to pass pointers or references to objects around (which is a start).
Second, try to never pass around pointers or references to concrete classes; instead, pass around pointers or references to interfaces. For example, don't pass to a MyListControl* to the InsertYouselfIntoThisControl() method; pass it a IMyControl* instead. This is called "coding to the interface".
Thanks for "gob-smacked", BTW, I had to look it up... you Brits... |
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Feb 25 2004 : 10:13:55 AM
|
Uniwares said:
quote:
Have a look at Design Patterns and using template classes (Josuttis and Vandervoorde) to get a good idea.
I've been looking for a really good STL book... I can't seem to find that one. Is it "Design Patterns and Using Template Classes", by Josuttis and Vandervoorde? Or are you referring to two books (the GoF book, and "Using Template Classes")?
I admit I'm biased against STL for some odd reason: probably Microsoft's lousy early support for it; the total lack of decent STL books for years; and the fact that the code just looks ugly to me. I mean, I use STL, but not nearly as much as I know I could and probably should. But maybe if I can find a great STL book to get me excited about it...
quote:
Another, even more elegant solution would be to implement streams...
Can you use the words elegant and streams in the same sentence? 
|
|
|
|
Uniwares
Tomato Guru
Portugal
2321 Posts |
Posted - Feb 25 2004 : 10:30:18 AM
|
I am talking about some books here:
C++ Templates: The Complete Guide
The C++ Standard Library : A Tutorial and Reference
Definitely the 2 best books on STL.
Design Patterns
As for MS's STL - forget it (although the one in VC7 is not bad at all). Documentation was non-existent until VS.NET. I am stuck with STLPort, which does for me all that I need and expect from STL (even accepting that VA has still serious troubles with it. Did I mention already that VAX has problems with template classes?)
Streams and elegant, well, depends on which part of this you are looking at. The "use" is definitely elegant, just pray that you dont need to write the stream implementation.
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Feb 25 2004 : 10:31:30 AM
|
There's a third book by Meyers, Effective STL. I haven't read it though, so I can't comment, except to agree that the other two are very good.
While we're on the subject of Meyers, coincidentally I just read Item 20 of Effective C++, which is highly relevant. It's entitled "Avoid data members in the public interface". He argues in favour of never making data public and using getters and setters instead, on the following grounds:
- That it's a consistent convention for user classes;
- That it gives you more fine-grained control because you can allow no access, read-only, read-write or even write-only access;
- "If you implement access to a data member through a function, you can later replace the data member with a computation, and nobody using your class will be any the wiser."
Of course, he's only comparing using getters and setters with making the data member public. If you're arguing that no data member ever needs to be (functionally) public, that's a different issue. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
Edited by - Stephen on Feb 25 2004 10:37:27 AM |
|
|
|
Uniwares
Tomato Guru
Portugal
2321 Posts |
Posted - Feb 25 2004 : 11:16:07 AM
|
Meyers is one of the must-read books for every C++ developer. (There are a few others, but I think this is not the place to chit-chat about books).
My 2 cents on public data members - hide them; but ...
* for functional classes, wrap members around them to access their value/purpose
* for data classes/structs, use a facade
Explanation: when you have a class like MyWindow then this is probably a functional class, so you have properties to set/get, actions to do, events to process.
When you have a class/struct which is used purely for data containment (often 1:1 used with persistant storage) then use a facade to abstract possible data changes. This helps when you need handle data structure changes.
In most cases the compiler will remove facade interfaces during compilation whenever possible, so there is no penalty in data access. |
|
|
|
Jugalator
Junior Member
11 Posts |
Posted - Feb 26 2004 : 05:06:09 AM
|
First, I belong to the Get/Set camp :)
However, I agree they make programs a bit less object-oriented. Get/Set is much like regular functions instead of manipulation of an actual object property.
So that's where VB / C# "properties" come into play. :D
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Mar 02 2004 : 11:31:19 AM
|
quote:
Originally posted by LarryLeonard
Here's two tricks that work for me.
*snip*
Thanks for "gob-smacked", BTW, I had to look it up... you Brits...
gob-smacked summed it up perfectly so simple and clear once someone pointed it out. you left me wondering why i had never seen this before.
i have just spent some time re-writing a chunk of my one and only serious windows program
i process a website log file, and turn the processed data into a list view. so instead of keeping all of the data in structures (one per line) i have turned my structure into a class with all but one of the data items as private members
i had to expose one member to avoid a load of hassle finding and matching up duplicate items.
my problem is that the run time has jumped from 10 seconds to 63 seconds for processing exactly the same 19Meg data file.
is there some method to help cut down the overhead costs of these techniques? i am assuming i haven't made a grievous mistake in my program. i am now torn between better slower code and worse faster code 
time to try and speed up the program i think, since i have seen it run on much larger data files. |
zen is the art of being at one with the two'ness |
|
|
|
LarryLeonard
Tomato Guru
USA
1041 Posts |
Posted - Mar 02 2004 : 12:28:53 PM
|
I'd be thunderstruck if re-implementing your code as OO caused your load time to jump six-fold, processor speed being what it is these days. (In fact, I'd go as far as to say it's impossible, which is a pretty strong word. I mean, if you'd said five or ten per cent, I'd have said "that sounds pretty high" - but 600 per cent? Nah, there's no way it's because of the OO techniques.) I would look elsewhere for the culprit; most likely, there is some subtle inefficiency you've introduced somewhere. Also, the list view control is notoriously difficult to load quickly for large data sets. Are you using the SetRedraw() method? And have you looked in what are called "virtual list controls"? Just some ideas...
|
|
|
|
Uniwares
Tomato Guru
Portugal
2321 Posts |
Posted - Mar 02 2004 : 7:15:37 PM
|
| And dont forget about the biggest culprit in OOP - temporary objects. They can cause a big time penality when you create temporary objects (you can use a tracer to keep track of objects and how many times they are created) -> http://www.josuttis.com/tmplbook/index.html contains a tracer class for this purpose. |
|
|
|
kschaab
Tomato Guru
USA
118 Posts |
Posted - Mar 02 2004 : 8:05:24 PM
|
I'll have to add my 2 cents. First for accessors (get/set). Well I must say Get/Set is a good thing in two cases. One read-only properties, so Get with no Set. Two rules. AT&T started a project to extend C++ and implemented a new language that preprocessed to C++ called R++. R++ had properties and the thing about it is you can apply rules to those properties. For example you want to set a Foo property off an object but the object only wants to set Foo if Foo is valid. Can't do that if your member is public with no code wrapping access. Unfortunately C++ isn't the greatest language for accessors...GetXXX() SetXXX() can start to become ugly.
I've started writing a lot of code in C# and I love built in support for accessors. I find even encapsulating private members from derived classes proves to be useful. My code starts looking very nice and it's much easier to encapsulate functionality around my data making it much *more* OO in nature.
Like Uniwares has stated accessors can give you dreaded temporary objects in C++. Most all of my C++ accessors take const references as parameters for gets and sets return references. This makes them look as close to properties as you can get in C++ (without exposing the members themselves of course) and you incur almost no cost. In case you return a temporary object from your accessor (where you encapsulate some functionality) you can use const & to bind to that temporary object avoiding another copy. The only thing to watch out for here is implicit conversions from one type to another, const modifiers can hide these a lot more than simple references would. Of course implicit conversions would still be an issue when dealing with a member variable anyway...
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18943 Posts |
Posted - Mar 03 2004 : 08:09:34 AM
|
ah, so it is a problem with my code. this is good to know, i was getting worried. i really like the improvements this has made to my code now i just need to discover where i went wrong.
as for my program, all of the run time is while processing the log file. building the list view (made using Qt 3.2.3) is basically instantaneous.
i am effectively sorting and uniquing 84,140 lines down to 238 lines. it is only the final 238 lines that are inserted into the list view. temporary objects being created during the comparison phase would make sense.
oh yes, many thanks for the help on this this is rather off topic, but incredibly useful  |
zen is the art of being at one with the two'ness |
|
|
|
Old as dirt
Tomato Guru
USA
246 Posts |
Posted - Mar 03 2004 : 10:54:19 AM
|
One time that public getters are useful is when the data isn't in a single variable but rather has to be calculated. Of course a public setter is pretty much useless in that situation.
Ken
|
Ken |
|
|
|
John_H_Bergman
Tomato Guru
USA
198 Posts |
Posted - Mar 07 2004 : 3:19:50 PM
|
Try applying your approach to COM. I've yet to see an example that would expose variables, since its simply not possible. So if you ever intend your object to be a component, you should use getters and setters.
Additional, many best practices I've read indicate that your member variable shouldn't even be protected, but private -- obviously, there are exceptions, but if you are truly trying to encapsulate then I would even tend to agree on that (reluctantly).
There are lots of other examples were encapuslation using getters/setters is a good thing, especially if your interal data representation is complex; where the values of one or more fields affect the values of other fields.
Another good reason to use the getter/setter implementation is design-by-contract. Your interface is a contract that is enforcable that way. You can 'protect' our internal state by doing validation on the incomming values to make sure they are not being set out of range or incorrectly.
As for STL.. don't even get me started on that... its not an OO framework, and should be used with caution. I've seen several examples when polymorphic objects are placed in STL containers that simply do not work as expected. Maybe the C# generics won't suffer the same types of problems.
Just some rambling thoughts.... |
John H. Bergman
CTO
SiliconZone
[email protected]
To Send email, remove the .online. |
|
|
|
Topic |
|
Topic Locked
