pyatcron-devel-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Pyatcron-devel-list] Scheduler Class Definition


From: NICOLOVICI Xavier
Subject: RE: [Pyatcron-devel-list] Scheduler Class Definition
Date: Mon, 15 Dec 2003 09:41:50 +0100

All,

About the year array, my feeling is that we should focus on consistency
between methods. Month and day are arrays of integer, and year should be the
same.

Now, this is my own opinion, and of course, I'm not a software design guru.
If everybody think that we should set the year method with one integer
parameter, then I'll accept this option ;-)

Now that you know my position, I let you decide...

Xavier

PS: Sorry about not releasing documentation so far, I'm very busy those
days. I should send you something on the plugin architecture before end of
this week.


> > I'm not sure to understand why you want to make the year 
> attribute different
> > from every other one. If we keep in mind that this 
> Scheduler class is an
> > abstract layers, classes that inherit from it (aka 
> CronEntry and AtEntry)
> > will be responsible of dealing with those arrays.
> > 
> > Do not forget the GUI coding point of vue. It's much easier 
> to have all
> > methods having same prototype, difference will be done by 
> inherited classes.
> 
> My point of view on this subject is that there can't be more than 1
> year. Not any case. So why provide a years array ? Of course, we could
> do it for consistency reasons with other attributes. But that wouldn't
> be very clean, would it ?
> 

This e-mail contains proprietary information some or all of which may be 
legally privileged. It is intended for the recipient only. If an addressing or 
a transmission error has misdirected this e-mail, please notify the author by 
replying to the e-mail. If you are not the intended recipient you must not use, 
disclose, distribute, copy, print, or rely on this e-mail.
We take reasonable precautions to ensure our e-mails are virus free. However, 
we cannot accept responsibility for any virus transmitted by us and recommend 
that you subject any incoming e-mail to your own virus checking procedures.











reply via email to

[Prev in Thread] Current Thread [Next in Thread]