No, the AnonMonk is quite correct. Sure, all objects have properties. They are necessary for the object to keep track of its own state. The problem comes when you expose those properties to the outside world through trvial accessors/mutators.
The most OO-pure way to do things would have all its methods have void return values. It only takes parameters and modifies its own state accordingly. (The most successful example of this is Unix shell pipelines).
The next best is to return complex objects in response to some methods (and void for the rest). This is essentially how I implemented Gopher::Server. On each request, the Gopher::Server::ParseRequest->parse() method generates a Net::Gopher::Request object, which is fed into a Gopher::Server::RequestHandler object. The process() method generates a Gopher::Server::Response object, which has a print_to() method for sending back the response to the client.
Note that there isn't a single trvial accessor/mutator involved in this process. One object is simply fed into the next until a response is built. Not even the Response object returns a primitive type--it prints its data back to the socket directly.
One advantage of this architecture is that different RequestHandlers can be easily swapped out. The current one uses a simple filesystem layout, but I imagine handlers that get all information from a database, or from menu files (as is done in some other Gopher server implementations). This will become really important to fully take advantage of Gopher+.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
In reply to Re^7: Assignable Subroutines
by hardburn
in thread Assignable Subroutines
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |