> On Tuesday 13 Jan 2004 5:05 pm, Wiggins d Anconia wrote: > > > On Tuesday 13 Jan 2004 3:04 pm, James Edward Gray II wrote: > > > > On Jan 13, 2004, at 6:24 AM, Gary Stainburn wrote:
<snip old posts> > > Hi, > > I've not responded to these two comments yet as my head was struggling enough > with the read of the thread. > No problem, lots to take in, but good information... > I've looked at POE before, and at the time thought it looked far too > complicated. However, looking again now may produce a different opinion. I > still think that it will be a bit OTT for my project. > It is pretty complicated, the tough part is that so is your project ;-)! As the others have expressed. I am concerned (take that loosely) that, while your attempts to learn OOP in this context are certainly worthwhile and giving you progress, the OOP may be hiding the complicated part of your problem that is yet to come which has been mentioned briefly before. In other words how do you keep the parts of the system running in a constant nature while attempting to receive inputs from external sources in possibly multiple ways. The problem I foresee is that you have multiple objects that are all possibly (usually?) doing something independently but also must detect and handle signals from other objects in some unscheduled manner which is fine to say, but the problem becomes that a single Perl process *blocks* (usually), which essentially means your objects can't work independently and concurrently. In more concrete terms, you have to have a way to have a train move along a track, have a signal box receiving signals, having a trainset manager (can't remember the name you gave it) inputting data (aka using the controls), having the controls waiting for inputs and handling them, etc. *at the same time* all the while with some way to get the various parts talking while they work. The problem becomes how to do this, how to prevent the blocking, three options come to mind (for me) threads, forked separate processes (using IPC or shared memory (yikes)), or some type of time slicing aka POE, Select, or Loop (group have I missed any?). I am curious if the discussion about the "owner" and managing all of those tasks is the reason why the object structure hasn't been as obvious as it should. Essentially this is the jump that must be made from simple scripts to long running programs, essentially a server, where rather than serving data of some sort you are really serving trainset events (which of course is just data), then a client plugs in to control those events. I am thinking that you can resolve your object system and make it seem like it will work, but when you go to flip the on switch it is just going to sit there because how to get the different parts moving hasn't been worked out fully in the design, that or you will have a series of events that must happen in the essentially in the same order at the same time, which is hardly like the real life system you are trying to emulate. But then I could just be off my rocker.... in the end if I am not loco, POE is going to be one easy way to get this type of system running. > The idea of named parameters is worth considering as my project and therefore > the methods is starting to get far more comprehensive and complex. > Yeh, its extra work to get used to but worth it in the end... http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
