On Tuesday 13 January 2004 6:17 pm, James Edward Gray II wrote:
> On Jan 13, 2004, at 11:32 AM, Gary Stainburn wrote:
> > I'm starting to confuse myself again now.
>
> Yes, you are.
But hopefully lifting the vail a little at last.
>
> > I've got it into my head that I'm going to have an instance of
> > Trainset as a holder to contain track, signals etc, so I'll do
> > something line:
> >
> > my $tset=Trainset->new;
> > $tset->add_track('TCB',['TCB1','TCB2']);
>
> Everything you've said to here is correct.
>
> > The problem here is that I'm using a Trainset object to call a method
> > of
> > Trainset::Track.
>
> If that's what you are doing, yes that is the design flaw. Now I
> understand why you were using "base" in the earlier example. That's
> bad and you don't want to go that way.
>
> Trainset isn't a child object of all your other objects, it's a master
> object that provides an interface for using all those other objects.
> Trainset needs and add_track() method which calls Trainset::Track's
> constructor, does any other needed initialization (linking for
> example), and stores the references in some Trainset instance variable
> for future reference.
>
> Did that make any sense?
Yes. While driving home I think I've discovered my biggest conceptual block.
The idea of a Trainset class is as you know new. The idea was originally to
have all code relating to track in the Trainset::Track class.
What I've realised is that only the code relating to the insides of a single
block belongs in there (constructor, update etc) while use use of, or the
grouping of multiple blocks belongs in the container.
This way, linking blocks together etc. all happens within the container code.
I will still need to link blocks to each other directly, so that the effects
on one block will ripple down to it's neighbours, and link levers to signals
and points to change their states, but again this will happen within the
container class and should not be a problem.
One thing that both you and Rob will be happy with is that I will finally let
go of the $owner.
>
> This is probably why you have also been so insistent about keeping the
> $owner objects everywhere. You get all this fixed up and you may not
> even need them at all, which is what I've always suspected would be the
> case.
;)
>
> James
--
Gary Stainburn
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
