[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

how to change mindset from Records to objects

zyzygy

1/11/2007 3:37:00 AM

Hi Gang,

I have a ruby issue that I'm hoping someone can shed some light on. Its
probably not so much a Ruby issue as a dinosaur ex Cobol programmer
trying to work with objects rather than records.

I'm using Ruby to generate ConTeXt code to automate a report. One part
of the data is about tape libraries and looks something like this
(simplified)

tapelibs:Array
tl:Tapelib
lib_device:Device
rmu:Device
parts:Array
part:Partition
drives:Array
drive:Device


I'm creating this data in part from an input file and in part from
stored database information, and the whole tree of objects is created
so that the Initialize of one object calls the initialize of the next
sub object as needed.

One of the attributes of Device is latest_ucode and it is looked up in
the database.

Now it turns out that the latest microcode level for a drive depends on
the type of the tape library as well as the type of the drive, so when
I'm down in the depths of of Initialize for the Device object I need to
access the tape library model several steps up the data structure.

The only way that I have been able to work around this is to pass Self
down into the creation of the next level object and use that to create
a @parent attribute, which I can then follow back up as necessary.

This feels kludgy and unsatisfying though and is not nearly general
enough for my taste.

Can someone please point me at the Ruby way to do this?


Thanks

Steve.
3 Answers

Francis Rammeloo

1/11/2007 9:52:00 AM

0


zyz...@telstra.com schreef:

> Hi Gang,
>
> I have a ruby issue that I'm hoping someone can shed some light on. Its
> probably not so much a Ruby issue as a dinosaur ex Cobol programmer
> trying to work with objects rather than records.
>
> I'm using Ruby to generate ConTeXt code to automate a report. One part
> of the data is about tape libraries and looks something like this
> (simplified)
>
> tapelibs:Array
> tl:Tapelib
> lib_device:Device
> rmu:Device
> parts:Array
> part:Partition
> drives:Array
> drive:Device
>
>
> I'm creating this data in part from an input file and in part from
> stored database information, and the whole tree of objects is created
> so that the Initialize of one object calls the initialize of the next
> sub object as needed.
>
> One of the attributes of Device is latest_ucode and it is looked up in
> the database.
>
> Now it turns out that the latest microcode level for a drive depends on
> the type of the tape library as well as the type of the drive, so when
> I'm down in the depths of of Initialize for the Device object I need to
> access the tape library model several steps up the data structure.
>
> The only way that I have been able to work around this is to pass Self
> down into the creation of the next level object and use that to create
> a @parent attribute, which I can then follow back up as necessary.
>
> This feels kludgy and unsatisfying though and is not nearly general
> enough for my taste.
>
> Can someone please point me at the Ruby way to do this?
>
>
> Thanks
>
> Steve.

If I understand well, you are saying that in order to define a drive
you must know what tape library you are using. So in that case I think
passing the type library object to the constructor of the drive object
is the right choice.

Transitioning from Cobol to Ruby is a brave choice! I hope you'll enjoy
it :-)

Francis

Eric I.

1/11/2007 9:44:00 PM

0

Hi Steve,

You can decide whether the objects form a hierarchy in which the higher
level objects know about the underlying levels (and not vice versa), or
whether the lower level objects can/should know about "whom" they
belong to. And this really depends on what makes sense for the
information domain you're working in.

Think about instances of a class PostalAddress. That's a pretty
general purpose class, and you can imagine using it in many
circumstances -- in a Customer class, an Employee class, an Invoice
class, etc. In that case you would likely not want to have
PostalAddress have an instance variable that refers back to the
instance to which it belongs. There's no purpose for this information
that could span all these different uses.

Now consider two highly cooperative classes, say an Account class and a
Transaction class. An Account will likely have a reference to many
Transactions. And it would be reasonable for a Transaction to have a
reference back to the Account it belongs to.

Now I don't know the information domain you're working with. But you
can ask yourself whether it's reasonable for an instance of drive to
know about which tape library it belongs to. If it is reasonable, then
the constructor for a drive *should* take as a parameter a reference to
the tape library and store that in an instance variable.

In other words, your solution is basically OK and may not be as much as
a "kludge" as you are inclined to believe. You may want to consider
using an attribute name more specific than @parent, though, as it
sounds like you know what type this parent should be.

Eric

====
Highly reviewed, hands-on, on-site Ruby training is available from
www.LearnRuby.com .

zyzygy

1/12/2007 4:19:00 AM

0

Eric I. wrote:
> Hi Steve,
>
> You can decide whether the objects form a hierarchy in which the higher
> level objects know about the underlying levels (and not vice versa), or
> whether the lower level objects can/should know about "whom" they
> belong to. And this really depends on what makes sense for the
> information domain you're working in.
>
> Think about instances of a class PostalAddress. That's a pretty
> general purpose class, and you can imagine using it in many
> circumstances -- in a Customer class, an Employee class, an Invoice
> class, etc. In that case you would likely not want to have
> PostalAddress have an instance variable that refers back to the
> instance to which it belongs. There's no purpose for this information
> that could span all these different uses.
>
> Now consider two highly cooperative classes, say an Account class and a
> Transaction class. An Account will likely have a reference to many
> Transactions. And it would be reasonable for a Transaction to have a
> reference back to the Account it belongs to.
>
> Now I don't know the information domain you're working with. But you
> can ask yourself whether it's reasonable for an instance of drive to
> know about which tape library it belongs to. If it is reasonable, then
> the constructor for a drive *should* take as a parameter a reference to
> the tape library and store that in an instance variable.
>
> In other words, your solution is basically OK and may not be as much as
> a "kludge" as you are inclined to believe. You may want to consider
> using an attribute name more specific than @parent, though, as it
> sounds like you know what type this parent should be.
>
> Eric
>

Thanks Gents.

Your posts have made the lightbulb come on :)
I need a device class and a drivedevice class descended from it, which
has the extra information that it needs.

Many Thanks

Steve

AIX and TSM Admin
Brisbane Australia
> ====
> Highly reviewed, hands-on, on-site Ruby training is available from
> www.LearnRuby.com .