Hi Gary. I'm quite concerned about this thread. I think we could help you a lot more if we had a better grasp of the problem: instead we've been answering individual questions that you've raised, hoping that they help you to achieve your goal but without any real idea of where you're headed.
Paul has come the nearest to echoing my thoughts so far, albeit for different reasons, so I'm tagging this post onto his. Paul Johnson wrote: > > On Mon, Jan 12, 2004 at 04:21:58PM +0000, Gary Stainburn wrote: > > > The only functionality gain would be the ability to have multiple trainsets. > > This will never be requred. > > I've not been fully following this thread, but this comment caught my > eye. I think that is a very dangerous assertion to make. Good code is > often used in ways its original author didn't envisage. Of course, the > worse your code, the more likely your comment is to be true. ;-) > > This is a general comment and you might feel that it doesn't apply in > this specific case. You might well be right, but I think that in > general good designs try hard not to paint themselves into a corner. You've created a package/class called 'Trainset' but decided not to instantiate it as an object. As James says, this is therefore no more than a namespace and could probably be more obviously coded as simple data items and subroutines in the 'main' namespace. At the very least, if you choose to have a bucket labelled 'Trainset' for all related subroutines and data, you should avoid writing methods for it. A call like Trainset->method() is hiding the more obvious and truthful Trainset::method() where there is no such thing as a 'Trainset' object. Such a bundle will of course have no interest in constructor or destructor methods, as there are no objects to create or destroy. As Paul said, it's a good idea to write code to be as reuseable as possible, as you don't know when somebody might get their hands on it and use it in the next Cruise missile AI software. But in your case you're writing a program just for your own teaching, and this doesn't really apply. Would it help to compare your 'Trainset' non-class to a learner's car built with no brakes, and the clutch and accelerator pedals swapped (as proper functionality 'will never be required')? (Forgive my ignorance of US English terms.) The time to bend the rules comes only when experience tells us how far they can safely be bent. As a secondary point, I think you're also confounding your learning process by considering object destruction before you have anything working. My advice is to get the basics going first, and then consider optimisation and memory conservation as a secondary chore. Certainly you should forget about implementing a DESTROY or 'delete' method until it proves necessary: the vast majority of Perl modules have no such method. Finally, throughout this thread we've been working with our imaginings of your design and code. It would help you as well as the group if you were to post some actual code - this will be much more descriptive of your ideas than you may imagine, and will help us to address the real problems you're facing. Hoping this is useful in some way, and wishing you well, Rob -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
