Menu
▾
▴
rails-devel
|
From: Brett L. <wak...@ea...> - 2005-12-13 00:36:08
|
If these are UI-side objects, it would make more sense to place them in the /ui directory rather than in /game. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Dec 11, 2005 1:30 PM To: rai...@li... Subject: [Rails-devel] Granular model/view I have committed code including part of a model/view implementation of individual fields in the Status and OR windows. This applies to the cash, trains, price and worth fields. The view is always the existing Field class, which I have extended a little. Each Model is one of a set of simple classes in the new game.model package. Where implemented, the Fields are now kept up-to-date by either - pulling the value on each paintComponent() call (Brett's method) or - pushing the value on each change via the Observer interface (my method) (worth is always pulled, as it must always be recalculated). The method can be selected by setting the boolean StatusWindow.useObserver. The difference is just a few lines of code. We can make a final choice later, e.g. once we are adding client/server separation (and I know what the choice then will be... :-)). This subproject is in an intermediate state. But everything should still work, except for one thing: the left-movement of the share price tokens in OR 1. This is because of the new behind-the-scenes processing of the no-trains case in the new OperatingRound. I will fix that later (or withdraw that particular change). Erik. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Brett L. <wak...@ea...> - 2005-12-13 20:15:04
|
Looking a bit more at the code... ok, I see how you're implementing it. Now it makes a bit more sense. So, what's the difference between Cash and Money? Worth doesn't seem to make a whole lot of sense to me. It's not storing any information of its own, but is instead calling methods in Player. So, if this information isn't something that we can abstract out, why should we make things more complicated by making a new Class? In the end, Cash and Trains make sense to me. Price seems like it could extend from Cash, because a Price is just an amount of Cash. The others don't really look like we need them. ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Dec 13, 2005 11:31 AM To: rai...@li... Subject: RE: [Rails-devel] Granular model/view > If these are UI-side objects, it would make more sense to > place them in the /ui directory rather than in /game. But they aren't, the name says it all... Erik. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@hc...> - 2005-12-13 20:30:44
|
> Looking a bit more at the code... ok, I see how you're > implementing it. Now it makes a bit more sense. > > So, what's the difference between Cash and Money? Nothing. > Worth doesn't seem to make a whole lot of sense to me. It's > not storing any information of its own, but is instead > calling methods in Player. So, if this information isn't > something that we can abstract out, why should we make things > more complicated by making a new Class? To fit into the generic way that the new Field class updates itself: via the toString() method of any ModelObject subclass. > In the end, Cash and Trains make sense to me. Price seems > like it could extend from Cash, because a Price is just an > amount of Cash. The others don't really look like we need them. No, Price embeds a StockSpace, Cash embeds an int. I could probably find a way to merge these classes, by representing price by an int as well as a StockSpace. But that would require extra update code in PublicCompany, so it does not really reduce complexity to me. Anyway, this is kind of an experiment on how to do these things, so it is of course well possible that we find ways to simplify this later. Erik. |
|
From: Brett L. <wak...@ea...> - 2005-12-13 20:55:21
|
>> Looking a bit more at the code... ok, I see how you're >> implementing it. Now it makes a bit more sense. >> >> So, what's the difference between Cash and Money? >Nothing. We should probably keep one and delete the other. ;-) >> Worth doesn't seem to make a whole lot of sense to me. It's >> not storing any information of its own, but is instead >> calling methods in Player. So, if this information isn't >> something that we can abstract out, why should we make things >> more complicated by making a new Class? >To fit into the generic way that the new Field class updates itself: >via the toString() method of any ModelObject subclass. Ah ha. That makes lots of sense. Very good. >> In the end, Cash and Trains make sense to me. Price seems >> like it could extend from Cash, because a Price is just an >> amount of Cash. The others don't really look like we need them. >No, Price embeds a StockSpace, Cash embeds an int. >I could probably find a way to merge these classes, >by representing price by an int as well as a StockSpace. >But that would require extra update code in PublicCompany, >so it does not really reduce complexity to me. Would it make sense for Price to extend from Cash instead of from ModelObject? Would the inherited methods add any value? ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-12-13 21:23:01
|
> >> Looking a bit more at the code... ok, I see how you're > >> implementing it. Now it makes a bit more sense. > >> > >> So, what's the difference between Cash and Money? > > >Nothing. > > > We should probably keep one and delete the other. ;-) Ah, now I understand the confusion. I had renamed MoneyModel to CashModel, but I see that the removal of MoneyModel was not committed. Done now. > >> Worth doesn't seem to make a whole lot of sense to me. It's > >> not storing any information of its own, but is instead > >> calling methods in Player. So, if this information isn't > >> something that we can abstract out, why should we make things > >> more complicated by making a new Class? > > >To fit into the generic way that the new Field class updates itself: > >via the toString() method of any ModelObject subclass. > > > Ah ha. That makes lots of sense. Very good. I agree with you that the number of ModelObject classes is growing a bit large, and more will come. I will certainly consider all this again when I'm revisiting this subject. > >> In the end, Cash and Trains make sense to me. Price seems > >> like it could extend from Cash, because a Price is just an > >> amount of Cash. The others don't really look like we need them. > > >No, Price embeds a StockSpace, Cash embeds an int. > >I could probably find a way to merge these classes, > >by representing price by an int as well as a StockSpace. > >But that would require extra update code in PublicCompany, > >so it does not really reduce complexity to me. > > > Would it make sense for Price to extend from Cash instead of > from ModelObject? Would the inherited methods add any value? No, but coming to think of it: if we let StockSpace extend from ModelObject, we would probably not need the extra PriceModel. Sounds good. Erik. |
|
From: Erik V. <eri...@hc...> - 2005-12-13 19:31:34
|
> If these are UI-side objects, it would make more sense to > place them in the /ui directory rather than in /game. But they aren't, the name says it all... Erik. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X