rails-devel

[Rails-devel] The Player Class

[<wak...@ea...>]

Over the last few days, I've been working on getting the initial game options working. If you check out the files in CVS and run the main() method in test/GameTest.java you'll see the current state of things.

However, it looks like the Player class needs some clean-up work done to it before I go too much further. 

Currently, there are methods that presume the Player is a collection for housing all players' data and there are methods that presume the Player is a singular object.

I think we need to pick one of these styles rather than cluttering up the class with the ability to work both ways.

In my opinion, it's very easy to use existing collections to store multiple singular Player objects (ex: Player[] allPlayers). This allows the Player class to focus on housing all the data specific to a single player and makes a bit more logical sense when we have Player extending CashHolder.


Thoughts?


---Brett.

RE: [Rails-devel] The Player Class

[Erik V. <eri...@hc...>]

> Over the last few days, I've been working on getting the 
> initial game options working. If you check out the files in 
> CVS and run the main() method in test/GameTest.java you'll 
> see the current state of things.
> 
> However, it looks like the Player class needs some clean-up 
> work done to it before I go too much further. 
> 
> Currently, there are methods that presume the Player is a 
> collection for housing all players' data and there are 
> methods that presume the Player is a singular object.
> 
> I think we need to pick one of these styles rather than 
> cluttering up the class with the ability to work both ways.
> 
> In my opinion, it's very easy to use existing collections to 
> store multiple singular Player objects (ex: Player[] 
> allPlayers). This allows the Player class to focus on housing 
> all the data specific to a single player and makes a bit more 
> logical sense when we have Player extending CashHolder.
> 
> 
> Thoughts?

Yes.

I'm from a school of thought that classes should be self-managing,
which is why I tend to include static arrays and methods to manage
the instances of a class inside that class, as I have done in Player. 

About the Player[] allPlayers (I tend to use ArrayLists
because these do not need to be pre-dimensioned): sure, 
but my point is: where do we store such an array? 
I have put it as a static array inside Player (the class, not the instance)
itself. 
Why not?

Two other considerations were:

1. Player is not very likely to be subclassed, so the usual 
addition of an interface might not be needed. But maybe it is.

2. Static methods are easy because you don't need to carry object 
references around.

But, as I already have indicated in an earlier post, self-managing classes
turn out not to fit well with the style of component management and XML
parsing that we have started to use, so that a PlayerManager class 
already needs to be considered.

So I probably (though somewhat reluctantly) have to agree with you....

Long live the proliferation of classes! :-(

Erik,

Re: [Rails-devel] The Player Class

[John D. G. <jd...@di...>]

Erik Vos wrote:
> I'm from a school of thought that classes should be self-managing,
> which is why I tend to include static arrays and methods to manage
> the instances of a class inside that class, as I have done in Player. 

It's not exactly clear to me what you mean by self-managing.

Part of my coding philosophy is that, when taking any action that needs
to be cleaned up afterward (opening a file, allocating heap memory, etc.),
that action should be represented by a class object with a destructor that
cleans it up when it goes out of scope.  That way you can't forget it.

But if you mean you want to have a class keep a list of all objects of that
class, that's easy enough to do without static arrays.  Here's an example
in C++ of a class that maintains a circular linked list of every instance
of itself.

    class Example;  // to allow pointer declarations

    class Example {

    private:
        Example *prev, *next;
        static Example *first;

    public:
        Example();
        ~Example();

        // whatever other members it will contain

    };

    Example *Example::first = 0;  // The only static member.  Initialize once.

    Example::Example() {

        // If there are any other constructors, they also must contain this code.

        if (first) {

            // Insert the new instance into the circular pointer chain at the
            // end (just before *first).  Notice that first does not change.

            next = first;
            prev = next->prev;
            prev->next = this;
            next->prev = this;
        } else {

            // We're creating the first instance.  For now, prev, next, and
            // first will all point to that one instance.

            prev = this;
            next = this;
            first = this;
        }
    }

    Example::~Example() {
        if (prev == this) {

            // We're deleting the last instance.

            first = 0;
        } else {

            // Unlink this instance from the pointer chain.

            prev->next = next;
            next->prev = prev;

            // If we're deleting *first, update first.

            if (first == this) first = next;
        }
    }

Of course, in a multi-threaded program, both this constructor and destructor
would need locking calls added around their present contents.

RE: [Rails-devel] The Player Class

[Erik V. <eri...@hc...>]

> Erik Vos wrote:
> > I'm from a school of thought that classes should be self-managing,
> > which is why I tend to include static arrays and methods to manage
> > the instances of a class inside that class, as I have done 
> in Player. 
> 
> It's not exactly clear to me what you mean by self-managing.

A class that keeps a list of its own instances,
and provides methods to find these instances.
In some cases it might also instantiate them.
 
> Part of my coding philosophy is that, when taking any action 
> that needs
> to be cleaned up afterward (opening a file, allocating heap 
> memory, etc.),
> that action should be represented by a class object with a 
> destructor that
> cleans it up when it goes out of scope.  That way you can't forget it.

Cleanup is automatic in Java, if you remember not to keep
references to no-longer-needed objects.

> But if you mean you want to have a class keep a list of all 
> objects of that
> class, that's easy enough to do without static arrays.  

<snip>

Nice, but what is the advantage above a static array?
Looks a lot easier to me.

I'm getting the impression that 'static' is synonymous to
'not done' here....

Erik.

Re: [Rails-devel] The Player Class

[John D. G. <jd...@di...>]

Erik Vos wrote:
> Nice, but what is the advantage above a static array?
> Looks a lot easier to me.
> 
> I'm getting the impression that 'static' is synonymous to
> 'not done' here....

I hope so.

The reason for not using static arrays is that they set an unnecessary
upper limit on the number of instances, which can fail when temporary
copies of a class object are created in situations such as copying a
class type (a = b) or when a function returns a value of that type.
Some compilers create these temporary copies when others don't, so it's
simpler and better just to avoid having the limit.

RE: [Rails-devel] The Player Class

[Erik V. <eri...@hc...>]

> I hope so.
> 
> The reason for not using static arrays is that they set an unnecessary
> upper limit on the number of instances, which can fail when temporary
> copies of a class object are created in situations such as copying a
> class type (a = b) or when a function returns a value of that type.
> Some compilers create these temporary copies when others 
> don't, so it's
> simpler and better just to avoid having the limit.

???

This has nothing to do with an array (or list, or collection)
being declared static. You only should not dimension it with
a final static constant.

That is why I do not use an array but an ArrayList,
which has no predefined limit.

Erik.

RE: [Rails-devel] The Player Class

[Erik V. <eri...@hc...>]

> Over the last few days, I've been working on getting the 
> initial game options working. If you check out the files in 
> CVS and run the main() method in test/GameTest.java you'll 
> see the current state of things.

... which is:

java.lang.Error: Unresolved compilation problem: 
	The method setPreferredSize(Dimension) is undefined for the type
Options

	at ui.Options.initialize(Options.java:56)
	at ui.Options.<init>(Options.java:132)
	at test.GameTest.GameInitTest(GameTest.java:12)
	at test.GameTest.main(GameTest.java:17)
Exception in thread "main" 

so I guess there is something missing in CVS.

Erik.