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.
on 2007-01-11 04:40
on 2007-01-11 07:16
On 1/10/07, email@example.com <firstname.lastname@example.org> wrote: > > Hi Gang, <snip> > > 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. <snip> Can someone please point me at the Ruby way to do this? > > > Thanks > > Steve. > > Since you asked, there is a section on trees that may be helpful in the online sample chapter of The Ruby Way. ;) http://rubyhacker.com/coralbook/ch3.html#sec34
on 2007-01-11 10:56
zyz...@telstra.com schreef: > tapelibs:Array > stored database information, and the whole tree of objects is created > > 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
on 2007-01-19 16:30
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 .
on 2007-01-19 16:31
Eric I. wrote: > circumstances -- in a Customer class, an Employee class, an Invoice > Now I don't know the information domain you're working with. But you > 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