Re: [Rails-devel] Comments on Patch for Disclaimer, UserConfirmation and new Main-Class

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

(Some parts removed)

> I have need the LocalizedText to get the language. There are 
> instance-ethods
> to get it, but since you never instanciated the class, I 
> could not used it.
> Since I try to avoid a complete refatoring, I used this work-a-round
> instead.

OK.
 
> > 
> >When creating a server (see below) we might want to create an
> >instance 
> >(or a Properties map) per locale, but even then all of this should
> >IMO be 
> >managed internally. 
> >
> So a german and an japanese user could not play together? - 
> no good idea.

I said: per locale, not: per game.

But you make a very good point.
Nothing prevents us to send different players of the same game
messages in their own languages. It only means, that we will
have to postpone localisation of messages generated in the
server. 

> >> - getLogger() 
> >> Can be also in Util. I put it in here, because it is a 
> >> rails-spezifig way 
> >> to log. 
> >> Find the Logger over a Method makes it easiar to change the
> >fist 
> >> desission to log on package-level. 
> > 
> >Sorry, I don't understand at all what you are trying to say here. 
> When you start to introduce log4j in devel-rails, you talk about the
> posibility to create a logger for each class (or even instance),
> but for rails, it should be enough, to have a logger at package-level.
> 
> To create a logger on a defined way would be a good think, I 
> thought. So why
> writting at each class the same code to get the package name 
> and create a
> logger, 
> if we can write a central method, with just need the class or 
> an instance of
> it, to get the logger?

Aha, so you replace Logger.getLogger(Classname.class.getPackage().getName())
by Util.getLogger(Classname.class)?

I can't deny that it looks a bit better. On the other hand, 
creating a separate utility for saving two method calls
per class hierarchy does not really looks like worth the effort to me.
(It does not occur in each class, only in top-level classes.)
But if you feel better with this utility, no problem.
 
> > 
> >> - VERSION 
> >> Final variables should be written in upper letters
> >(Sun-Conversion) 
> > 
> >I thought that *constants* should be written in upper case. 
> >The question is whether 'version' is really a constant. 
> >One can also see it as a variable that, once assigned, cannot be
> >changed - 
> >but the value is different in each release. 
> > 
> >But if you say that this is nitpicking, I agree, 
> >and I have no real problem with making it upper case. 
> >
> It was just an example. If you look at the code, you find 
> diffrent styles
> and naming-praxis, with makes it harder to understand it.

Absolutely. Brett and I have quite different styles,
and I'm certainly not as consistent as I should be.
We are learning...

> Writing constants in upper letter is just one think, with 
> should know most
> coders and most coders follows.
> Anyway, when I will come to the project, you will see that I 
> will make such
> easy avoidable mistakes also. - don't bother.

Yes, we all do.

> >> - Config (comment) 
> >> - Much better not as static class, So you can have userConfig
> >and 
> >> systemConfig. Both should than accessed by RailsSystem or maybe
> >better 
> >> Util-Methods 
> > 
> >I was thinking it would be easier to have all (user and system) 
> >properties in one Properties map, so that the programmer need 
> >not worry about where a property is exactly defined. 
> >We could then also easily move properties between property files 
> >if that would suit us better. 
> > 
> >We definitely need static access to properties, otherwise we'll 
> >have to push around another instance reference. 
> >I have no real problem to replace Config.get() by Util.getConfig(), 
> >but I don't see the benefit either. To me, it's just an extra layer 
> >of indirection. 
> >
> If we need system.properties we should not put it into the 
> user.properties,
> becouse the user should normaly not see it or change it.

I don't want to merge property files. 
I do want to read their contents into the same map.
That is a different thing. Why would we not do that?

> >> - Where do you define the default-values? (if the file is 
> >> coruppted by 
> >> the user) 
> > 
> >Where needed, defaults are specified where the properties are used 
> >when they turn out to be null or empty. 
> > 
> So if you need the default more then ones, you defined it 
> more then ones? -
> Bad idea.

No, then I would encapsulate the property.
Come on, you are jumping to wrong conclusions much too easily.

> >Not every property has an explicit and fixed default value. 
> >The default money amount format is game-dependent. 
> >The default language is (British) English, because the default 
> >resource bundle is written in that language. 
> >The default log4j properties are (by definition) empty. 
> >Etc. 
> If there are no defaults - OK, but if there are, why not using a
> property-file for it too.
> the resource bundle has a default one (with no language extension).

Of course we could create a file with default property values.
It looks like overkill to me, compared with hardcoding defaults,
(also because users can tweak a defaults file too) but maybe I'm wrong.  

> >> - CodeStyle (comment) 
> >> - public and protected variables: You are much to 
> >> broadminded with it. 
> >> You should capsulate as much as possible, using getter- and 
> >> setter-methods 
> >> for access. 
> > 
> >One problem I have with Java is, that you cannot distinguish 
> >between variables that may only be visible to subclasses, 
> >and variables that may be visible to all classes within a package. 
> >Both are "protected". 
> - protected: means only for subclasses
> - private: only for class and private or anonym classes in 
> the same file
> - 'none': package wide with does not include subclasses in 
> other packages

The Sun Java Tutorial says: 
The protected modifier specifies that the member can only be accessed 
within its own package (as with package-private) and, in addition, 
by a subclass of its class in another package.

That "within its own package" I don't like, so that it why I use 
getters within a package too.
 
> >I agree that in principle there should not be public variables. 
> >Do we really have sinned as much as you seem to imply? 
> >It is possible that I have not always been consistent, 
> >so I would appreciate your examples of wrong use of public etc. 
> For example, all windows (views) are public, so I guess you 
> call them direct
> from the gmae-classes (model).

No, the UI classes are in control, and pull all info from the game classes.
The only exception is the use of the Observer pattern
to keep the UI fields up to date. But here also the UI Observer
must register at the game Observable. 

So it might very well be true that the UI classes don't need to be public.
Your fault, Brett... ;-)

> >Several parts of the code need to be able to find out in which turn, 
> >round or phase the game is (this all may have changed 
> >any moment, e.g. while processing a train buy). 
> >So there must be some central point of inquiry about all 
> >aspects of the game state.
> A central controller and interfaces

Yes. 

In the game package we are in fact not far from having a controller,
I think we only have to reorganise the Game and GameManager 
static and instance methods, and make clear which one the real 
controller is (I think it is GameManager).

In the UI I suppose we need a separate controller (if only
to work towards a client/server system), and that could be harder.
The UI control functions are pretty much a mess now.

I'm currently redoing the UI/game interfaces partly to try cleaning that up.

> >In my experience, things usually become clear when the time is ripe. 
> Thats the way I have coded in the 80's. On a very large 
> project (and I think
> this is a large project - at least what the final vision is),
> I was stucked in the code, with becomes unchangeable and had 
> to start from
> the beginning again, 

In principle true, but in reality I don't have such bad
experiences. I keep refactoring, and I also like to think
that I have a pretty good intuition for good structure. 
(Not that it always shows, you will respond, and you're right!)

Erik.