This is a very good point, and I am currently looking at changing my code to
better modularise and to have a Trainset object.
My two stumbling blocks are still:
1) How could a sub-class access the Trainset globals without knowing the
instance of the Trainset object?
There is no law about keeping a reference to a parent object, as I believe you figured out below.
2) How do they do this quickly?
Ah, here's the tricky question! Perl can be slow, in comparison to some things. Perl's objects sure aren't famous for their speed either, so you're definitely in the problem zone.
However, let's keep our wits about us as we discuss this. Slow in modern day computing is still pretty dang fast. I've seen operations be "100 times slower" and still happen in the blink of an eye. Believe me, it would take a lot of Perl object work to get my G5 to start behaving like a dog.
It may be that you're in the realm of needing to worry about this. If you're going to have a LOT of objects and/or be making a LOT of method calls and need all your answers VERY FAST, you may run into problems. Those are all relative terms though. Computers can just plain handle a lot these days.
The rule of thumb for optimizing is: Don't do it until you must! What if you build this whole thing and it's already "fast enough" (the super important speed goal to meet)? Good. If it's not, you have a lot of options at that point. Profiling to find out what's slow and looking for ways to speed that up or getting really serious and using some linked in C code which is sure hard to beat speed wise. You just don't want to make that a problem now, before you really know how much of a problem it is and how far your are going to have to go to fix it.
One possibility I've just thought of is to store the Trainset object as a ref
inside each sub-class object. This would then allow for multiple Trainset
instances, but would greatly increase refcounts, memory usage, complexity and
expense of access etc.
See speed issue discussion above and apply it to each of these areas in turn. Honestly, I'm a lot more concerned about the speed than anything you list down here and I'm not super concerned about any of it. You shouldn't be either yet. Keep your focus on building it right, for now. If you keep the code clean and well designed, you'll be able to fix these problems somehow, should any of them ever actually arise.
Hope that helps.
James
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
