On Monday 12 Jan 2004 3:01 pm, James Edward Gray II wrote:
> On Jan 12, 2004, at 5:27 AM, Gary Stainburn wrote:
> > Hi folks,
>
> Hello again.
>
> > I'm after peoples opinions on my (beginner's) slant objects in perl.
>
> I'll see what I can do.
>
> > In much of what I've read, there seems to be the implied rule that
> >
> > Package Name == Class == Object Type,
> >
> > specifically MyObject would be a object of class MyObject which would
> > be held
> > in a package MyObject, and would probably be created by calling
> > MyObject->new.
>
> You seem to be getting it just fine to me.
>
> > In my Package Trainset, I have class Trainset with variables global to
> > that
> > class. However, I don't have an object type of Trainset
>
> Well, then it's not really a "class" is it? It's just a package or a
> namespace, if you will.
>
> > (In a previous thread someone suggested creating one to hold the
> > class variables instead of using globals, to enable me to create more
> > than one trainset. I decided that
> > would create more problems than it would solve here).
>
> Create more problems than it solves? Pardon the pun, but I think your
> logic just derailed. ;)
>
> I recall a big discussion on this list when we saw your code about what
> that external hash in the constructor was and if it was a good idea to
> be manipulating things like that. If nothing else, I think we can
> assume from this that the intent of the code is not crystal clear.
> That means you stand to gain readability by objectifying Trainset.
I think the confusion here was that in my program I accessed
%Trainset::__Blocks. This is no longer possible ('my' now used instead of
'our') and was there only as crude debugging (now moved inside the module).
Access to all objects will be done through the approriate method, thus
cleaning up the interface.
>
> The suggestion was made, as you note above, because the code would gain
> functionality from the change as well.
>
> That's two plusses, what do you stand to lose?
The only functionality gain would be the ability to have multiple trainsets.
This will never be requred. The two proposed uses for the module are:
a) automate the control of inteligent electric model train sets.
b) Signalbox simulator and training aid for Preserved Steam railways.
What I'll lose I'll cover below.
>
> > I do have object types:
> >
> > * Block
> > * point (switch to american readers)
> > * signal
> > * lever
> > * signalbox
> >
> > These are all created by calling Trainset->Block etc., and the code
> > for all
> > object types are in the Trainset package.
> >
> > My question is:
> >
> > Is there anything wrong with what I'm doing, or any pit-falls I need
> > to watch
> > out for?
>
> I would prefer and I think it would be better OO design if the classes
> where broken out into separate modules. Maybe something like:
>
> Trainset.pm
> Trainset/Block.pm (package Trainset::Block)
> Trainset/Point.pm (package Trainset::Point)
> Trainset/Signal.pm (package Trainset::Signal)
> Trainset/Lever.pm (package Trainset::Lever)
> Trainset/SignalBox.pm (package Trainset::SignalBox)
>
I had originally thought of doing it this way, but considered it to be a bit
over the top for the size of the code being created (quickly changing my mind
though).
This was mainly because of the increase in complexity of having all the
various objects in different name spaces. Again, see below.
> > Is there a better way to do this, without further complicating or
> > slowing of
> > the code (e.g. indirect access to the globals via Trainset methods as
> > would
> > be needed if I created a Trainset object)?
>
> I'm not sure if I totally understand the complaint above, but let me
> see if I can change your thinking anyway... :D
>
In the the perldocs it compares having direct access to class globals with
using methods to access them. It states that while using methods provides
better control over the contents, it is exponentially slower than direct
access. As both my intended uses are going to be real-time, I don't want any
method slower than is necessary.
The other benefit mentioned in the perldocs is the simplicity and readability
of the code:
If, within a block I wanted to access all other blocks I could simply do
foreach keys %_BLOCKS
instead of having to find the Trainset object which is a variable probably
somewhere in main::, then calling a method to read the keys, then use another
method to read the block objects.
This is why I've gone for having everything in one package and using class
global variables.
> I was envisioning Trainset as the interface object to outside code. I
> wouldn't think a user would be wanting to call those five extra
> constructors and attach the new object to the right part of the
> Trainset. I would think they would call something like
> $trainset->add_signal(SOME PARAMS HERE) and the Trainset object would
> handle all the gory details, including creating the Signal object.
>
This is how I intend to use the module, but using
Trainset->add_signal
instead of
$trainset->add_signal
The only drawbacks I see so far are things like only having one DESTROY
method, and that an object can't detect itself what class it is (which would
make the DESTROY issue less of a problem).
> Does that give you any new ideas?
If I could get arrange the modules as you describe above, while still keeping
the direct access to class level variables, I would consider changing
especially as the code is getting much bigger than I thought.
>
> I should probably say that I know very little about what you're trying
> to create here and even less about trains, so if I'm being dumb, just
> ignore me. I'm just trying to toss out some general ideas.
I'm trying to model a very simple neural net, where the changes in one block
affect all of it's neighbours. e.g. If one block becomes occupied the signal
to enter it should change to red. The signal of the block in rear should
change to caution.
Any train occupying the block in rear would have to stop.
If a signaller in a signalbox throw a lever to set a call-ahead signal, the
train should be able to draw forward.
Thus:
* blocks must be able to talk to each other
* blocks must be able to read signals
* levers must be allowed to set signals (and points/switches)
* signalboxes must be able to own blocks, points, signals, and levers
(a signalman can only throw his own signals)
As you can see, there is a hell of a lot of cross-object talk which is why I
decided to put everything in to one namespace.
I suppose the purpose of this thread was to find the best way of getting the
benefits of splitting the classes, while keeping the benefits of keeping
everything together.
I am already starting the scalability problems, but cannot see easy solutions
for problems like the one mentioned above, where within a block object I
would need to find the Trainset object before I could access the list of
other blocks.
>
> Good luck.
>
> 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>
