i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all the
rest? and not using a global variable? for example:
class Top
def initialize(a)
Middle.new(a)
end
end
class Middle
def initialize(a)
Bottom.new(a)
end
end
class Bottom
def initialize(a)
puts a
end
end
A.new(“Thanks! I need that.”)
how do i get a to Bottom without going through Middle, since Middle
dosen’t really need a. of course in my real program, i have about 4
middles. does anyone have any better solutions to this problem?
···
–
~transami
“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin
If only the bottom object is goind to need the parameter, why isn’t
the parameter getting passed directly to Bottom?
···
On Sun, Jul 07, 2002 at 08:11:11AM +0900, Tom Sawyer wrote:
i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all the
rest? and not using a global variable? for example:
i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all the
rest? and not using a global variable? for example:
> how do i get a to Bottom without going through Middle, since Middle
> dosen't really need a. of course in my real program, i have about 4
> middles. does anyone have any better solutions to this problem?
I think the real answer would require more detail about what Top, Middle and
Bottom are modeling. Alan’s answer would work for this example. Also,
refactoring so that Bottom is a subclass of Top that shares Top’s accessors.
It’s hard to say without more info.
···
On Saturday 06 July 2002 06:11 pm, Tom Sawyer wrote:
i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all
the rest? and not using a global variable?
How about using Environmental Acquisition? (Came from Python.) In
Ruby, it is required that the package ‘OBAQ’ is installed. You can get
here:
hey i found the answer! i got a clue from david. thanks david.
the trick is to use a class variable in a module, along with a class
method for setting it, and then include it in the “bottom” class.
module Prefix
@@prefix
def set_prefix(x)
@@prefix = x
end
end
class Bottom
include Prefix
def initialize
puts @@prefix
end
end
class Top
def initialize
Prefix.set_prefix(‘whatever’)
end
end
and bingo!
~transami
···
On Sat, 2002-07-06 at 17:11, Tom Sawyer wrote:
i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all the
rest? and not using a global variable? for example:
class Top
def initialize(a)
Middle.new(a)
end
end
class Middle
def initialize(a)
Bottom.new(a)
end
end
class Bottom
def initialize(a)
puts a
end
end
A.new(“Thanks! I need that.”)
how do i get a to Bottom without going through Middle, since Middle
dosen’t really need a. of course in my real program, i have about 4
middles. does anyone have any better solutions to this problem?
–
~transami
“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin
–
~transami
“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin
well, i have an object called a Miter, and it has an array of Table.
each Table has an array of Section. each Section has an array of Cell.
and each Cell has an array of Element.
so when i create a Miter, i pass in a @layout and a @prefix. the @layout
gets parsed thus creating all those subobjects, but in so doing, each
Element has a @name which needs to be prefixed with @prefix.
does that help?
···
On Sat, 2002-07-06 at 17:22, Alan Chen wrote:
On Sun, Jul 07, 2002 at 08:11:11AM +0900, Tom Sawyer wrote:
i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all the
rest? and not using a global variable? for example:
If only the bottom object is goind to need the parameter, why isn’t
the parameter getting passed directly to Bottom?
i have a chain of objects such that one object contains another which
contains another, and so on, down the line. the top object recieves a
parameter which only the bottom most object in the chain is going to
need. but how do i get it down there with out passing it through all
the rest? and not using a global variable?
How about using Environmental Acquisition? (Came from Python.) In
Ruby, it is required that the package ‘OBAQ’ is installed. You can get
here:
Interesting, and new to me. I’m wondering how this compares to just
putting #a in a module and mixing in the module to both Top and
Bottom – meaning, when/why one would use E.Acquisition instead of a
module (or whether I’m wrong to see overlap in what they’re doing).
That design looks a little ugly to me. For one, if you can’t have more than
one tree with different prefixes with that design. You’re esentially using
an obfuscated global variable. How about just passing prefix to the bottom
element at instantiation?
class Bottom
def initialize(name)
end
end
class Top
def initialize @prefix = ‘pro’
@bottom_array = []
end
def add_bottom(name) @bottom_array << Bottom.new( “#{@prefix}_name” )
end
end
···
On Sun, Jul 07, 2002 at 04:33:27PM +0900, Tom Sawyer wrote:
hey i found the answer! i got a clue from david. thanks david.
the trick is to use a class variable in a module, along with a class
method for setting it, and then include it in the “bottom” class.
module Prefix
@@prefix
def set_prefix(x)
@@prefix = x
end
end
class Bottom
include Prefix
def initialize
puts @@prefix
end
end
class Top
def initialize
Prefix.set_prefix(‘whatever’)
end
end
Hmmm… is @prefix know when you’re creating your Element objects?
···
On Sun, Jul 07, 2002 at 09:08:38AM +0900, Tom Sawyer wrote:
well, i have an object called a Miter, and it has an array of Table.
each Table has an array of Section. each Section has an array of Cell.
and each Cell has an array of Element.
so when i create a Miter, i pass in a @layout and a @prefix. the @layout
gets parsed thus creating all those subobjects, but in so doing, each
Element has a @name which needs to be prefixed with @prefix.
I am probably totally off base, but maybe it will trigger another way of
thinking about your problem. It appears that what you are trying to build is
a tree structure, which usually lends itself to recursion. But your original
post mentioned globals meaning that it’s really a namespace problem. By
controlling the descent in Miter you keep all elements in the same namespace
as @prefix.
class Miter
def initialize(layout, prefix) @layout = layout @prefix = prefix @tables = Array.new
buildTree
end
def buildTree
parser(@layout).eachTable do |table|
aTable = Array.new
@tables.push(aTable)
table.eachSection do |section|
aSection = Array.new
aTable.push(aSection)
section.eachCell do |cell|
aCell = Array.new
aSection.push(aCell)
cell.eachElement do |element|
aCell.push(element)
element.name = @prefix
end
end
end
end
end
def parser(aLayout)
#answer a tree
end
end
···
On Saturday 06 July 2002 07:08 pm, Tom Sawyer wrote:
well, i have an object called a Miter, and it has an array of Table.
each Table has an array of Section. each Section has an array of Cell.
and each Cell has an array of Element.
so when i create a Miter, i pass in a @layout and a @prefix. the @layout
gets parsed thus creating all those subobjects, but in so doing, each
Element has a @name which needs to be prefixed with @prefix.
a couple of people have suggested bringing everything into Top, i
thought about it, but that defeats the whole purpose of OO design.
the class variable makes sense. it didn’t have to go in a seperate
module. it could have just gone straight into the Element class. i only
used the module b/c i actually use the prefix in two or the lower lower
classes. (table and element). anyhow, it makes sense b/c the prefix is
constant for all Elements (and Tables).
~transami
···
On Sun, 2002-07-07 at 12:46, Alan Chen wrote:
On Sun, Jul 07, 2002 at 04:33:27PM +0900, Tom Sawyer wrote:
hey i found the answer! i got a clue from david. thanks david.
the trick is to use a class variable in a module, along with a class
method for setting it, and then include it in the “bottom” class.
module Prefix
@@prefix
def set_prefix(x)
@@prefix = x
end
end
class Bottom
include Prefix
def initialize
puts @@prefix
end
end
class Top
def initialize
Prefix.set_prefix(‘whatever’)
end
end
and bingo!
~transami
That design looks a little ugly to me. For one, if you can’t have more than
one tree with different prefixes with that design. You’re esentially using
an obfuscated global variable. How about just passing prefix to the bottom
element at instantiation?
class Bottom
def initialize(name)
end
end
class Top
def initialize @prefix = ‘pro’
@bottom_array = []
end
def add_bottom(name) @bottom_array << Bottom.new( “#{@prefix}_name” )
end
end
How about using Environmental Acquisition? (Came from Python.)
Interesting, and new to me. I’m wondering how this compares to just
putting #a in a module and mixing in the module to both Top and
Bottom – meaning, when/why one would use E.Acquisition instead of a
module (or whether I’m wrong to see overlap in what they’re doing).
It depends on case. The Top/Middle/Bottom sample is not suitable for
telling the advantage of Acquisition, because there is the intermediate
that can access each of Top/Middle/Bottom objects. Acquisition works well
on passing object/resource between far separated objects, and there are no
intermediate.
In Tom Sawyer’s case, it is needed Element to get the object that Miter
has. I think there are three ways.
Make the intermediate that can access both Miter and Element object.
Force each objects under Miter to have reference to Miter.
Use Acquisition. Miter exports the object, and Element imports it.
it is known, as it is passed all the way down. if i understand you
correctly.
to explain a little more…@prefix is known from the start, when Miter
is created. the prefix gets passed to it. Miter then creates some Table
objects which are stored in array. the prefix is passed to each of
those. in turn Table creates some Section objects which too are stored
in an array. again prefix is passed to those Section objects. and so on.
until prefix is passed all the way down to the Element objects where it
is actually used.
shirai’s idea of environmental acquisition is interesting, but seems
like more overhead then simply passing it all the way down.
~transami
···
On Sat, 2002-07-06 at 21:00, Alan Chen wrote:
On Sun, Jul 07, 2002 at 09:08:38AM +0900, Tom Sawyer wrote:
well, i have an object called a Miter, and it has an array of Table.
each Table has an array of Section. each Section has an array of Cell.
and each Cell has an array of Element.
so when i create a Miter, i pass in a @layout and a @prefix. the @layout
gets parsed thus creating all those subobjects, but in so doing, each
Element has a @name which needs to be prefixed with @prefix.
does that help?
Hmmm… is @prefix know when you’re creating your Element objects?
> a couple of people have suggested bringing everything into Top, i
> thought about it, but that defeats the whole purpose of OO design.
And what to you consider the purpose of OO design? Don't let the tail wag the
dog.
···
On Sunday 07 July 2002 02:37 pm, Tom Sawyer wrote:
a couple of people have suggested bringing everything into Top, i
thought about it, but that defeats the whole purpose of OO design.
Rather than pass data down through a series of innocent by-standers, simply
to have low-level objects create yet-lower-level objects, why not pass the
objects themselves, fully formed?
el = El.new( a )
cell = Cell.new( el )
sect = Section.new( cell )
table = Table.new( sect )
miter = Miter.new( table)
I’m not entirely thrilled with a series of construction expressions, since
it seems to bundle too much control logic in one place, but it does avoid
having to needlessly expose data to objects.
Perhaps this could work in a MiterFacrory class, which accepts general
instructions on how to create the Miter and its constituents, returning the
fully-formed Miter instance.
well, quite simply i was able to seperate these various “things” into
their own classes. each being a different type of entity. its a nice
seperation of code. sure, could have written it such that there was but
the one object Miter and everything exists in that. in fact thats how i
first hacked it out. but then i get a nice speration of code braking
things up into there components. it is far easier to understand and
maintain now.
~transami
···
On Sun, 2002-07-07 at 14:05, Albert Wagner wrote:
On Sunday 07 July 2002 02:37 pm, Tom Sawyer wrote:
a couple of people have suggested bringing everything into Top, i
thought about it, but that defeats the whole purpose of OO design.
And what to you consider the purpose of OO design? Don’t let the tail wag the
dog.
–
~transami
“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin
I don’t think anyone was suggesting that you use only one class. But rather a
simple refactoring so that a single high level process negated the need to
pass a variable down through intermediate level instances. But whatever,
It’s your code :^)
···
On Sunday 07 July 2002 03:49 pm, Tom Sawyer wrote:
well, quite simply i was able to seperate these various “things” into
their own classes. each being a different type of entity. its a nice
seperation of code. sure, could have written it such that there was but
the one object Miter and everything exists in that. in fact thats how i
first hacked it out. but then i get a nice speration of code braking
things up into there components. it is far easier to understand and
maintain now.