[#13775] Problems with racc rule definitions — Michael Neumann <neumann@...>

15 messages 2001/04/17
[#13795] Re: Problems with racc rule definitions — Minero Aoki <aamine@...> 2001/04/18

Hi,

[#13940] From Guido, with love... — Dave Thomas <Dave@...>

52 messages 2001/04/20

[#13953] regexp — James Ponder <james@...>

Hi, I'm new to ruby and am coming from a perl background - therefore I

19 messages 2001/04/21

[#14033] Distributed Ruby and heterogeneous networks — harryo@... (Harry Ohlsen)

I wrote my first small distributed application yesterday and it worked

15 messages 2001/04/22

[#14040] RCR: getClassFromString method — ptkwt@...1.aracnet.com (Phil Tomson)

It would be nice to have a function that returns a class type given a

20 messages 2001/04/22

[#14130] Re: Ruby mascot proposal — "Conrad Schneiker" <schneik@...>

Guy N. Hurst wrote:

21 messages 2001/04/24
[#14148] Re: Ruby mascot proposal — Stephen White <spwhite@...> 2001/04/24

On Tue, 24 Apr 2001, Conrad Schneiker wrote:

[#14188] Re: Ruby mascot proposal — matz@... (Yukihiro Matsumoto) 2001/04/25

Hi,

[#14193] Re: Ruby mascot proposal — "W. Kent Starr" <elderburn@...> 2001/04/25

On Tuesday 24 April 2001 23:02, Yukihiro Matsumoto wrote:

[#14138] Re: python on the smalltalk VM — Conrad Schneiker <schneik@...>

FYI: Thought this might be of interest to the JRuby and Ruby/GUI folks.

27 messages 2001/04/24
[#14153] Re: python on the smalltalk VM — Andrew Kuchling <akuchlin@...> 2001/04/24

Conrad Schneiker <schneik@austin.ibm.com> writes:

[#14154] array#flatten! question — Jim Freeze <jim@...> 2001/04/24

Hello.

[#14159] Can I insert into an array — Jim Freeze <jim@...> 2001/04/24

Ok, this may be a dumb question, but, is it possible to insert into an

[#14162] Re: Can I insert into an array — Dave Thomas <Dave@...> 2001/04/24

Jim Freeze <jim@freeze.org> writes:

[#14289] RCR: Array#insert — Shugo Maeda <shugo@...> 2001/04/27

At Wed, 25 Apr 2001 01:28:36 +0900,

[#14221] An or in an if. — Tim Pettman <tjp@...>

Hi there,

18 messages 2001/04/25

[#14267] Re: Ruby mascot proposal — "Conrad Schneiker" <schneik@...>

Danny van Bruggen,

16 messages 2001/04/26

[#14452] How to do it the Ruby-way 3 — Stefan Matthias Aust <sma@3plus4.de>

First a question: Why is

21 messages 2001/04/30

[ruby-talk:14053] Re: OO

From: chad fowler <chadfowler@...>
Date: 2001-04-23 00:42:42 UTC
List: ruby-talk #14053
> My question would be how are parts of a program
> supposed to talk to this
> Options object?
> 

2 cents:

>  - I could instantiate an Options object and then
> pass it to each object
>    as one of its initialization parameters

Does it make sense for each object to contain an
"Options"?  It seems like "Options" could be one of
many ways for an object to be populated with state. 
Each object shouldn't have to know about the many
possible ways.  I would keep that knowledge outside of
the objects.

>  - I could instantiate an Options object and place
> it in $OPTIONS so that
>    each object could access that object directly

This combines the object coupling of the first option
with temporal coupling ($OPTIONS has to be valid
before the objects try to use it).

>  - I could instantiate an Options object and store
> it in a Resources class
>    using a class method, and then use another class
> method to read the
>    options back, e.g. Resources.options(...)
>  - I could make Options not instantiatable at all
> and just have class methods
>    to load and access the options
> 

Your problem, IMO, isn't about instance vs. class
methods.  It's about coupling.  I don't think the
previous two possibilities address that.

What kind of data will be stored in the "Options"
object?  What do the individual classes need from it? 
It sounds like you are creating a static configuration
mechanism.  Another coupling-related fear that I would
have is that, when you pass a full "Options" into an
object, you are probably giving that object access to
any of the data in "Options".  So, you're creating
possible dependencies between every object that uses
"Options" and every possible "Option".

The solution I would propose is that you keep
"Options" outside of any objects that don't
specifically need it.  Then, from a controller object
(probably the same one that actually instantiates each
object), you can read "Options" and pass any required
data to the objects that need it.  With this approach,
"Options" doesn't know about your objects, and your
objects don't know about "Options".

This gives me my second opportunity to reference
http://www.c2.com/cgi/wiki?LawOfDemeter today. :)

Opinions?

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

In This Thread