On 24/3/03 1:12 pm, Eugene van der Pijll at [EMAIL PROTECTED] spake thus: > I don't like the name of that method... In DateTime set() changes the > object; two related modules shouldn't have unrelated methods with the > same name, IMHO.
Thought about the above again ... > DateTime::Event::Easter->as_set( from => $dt1, to => $dt2 ); This would return a DateTime::Set object > DateTime::Event::Easter->all( from => $dt1, to => $dt2 ); This would return an array of DateTime objects. Any objections to including both these behaviors? Is the second redundant? I'm not too sure on how DateTime::Set will work. My thoughts on having both is that ->all would allow people to get a list without having DateTime::Set installed. Functionally ->as_set would basically just return ->all as a DateTime::Set object. Another thought would be to use ->Set rather than ->set .. although that could lead to confusion. When I first outlined my thoughts on the interface for this I had ->next and ->previous, but thanks to syntax coloring in my editor I realised next was a perl command and would probably trigger strict, not to mention being confusing. One of the great things about developing with a loose distributed group like this is the application of multiple brain power to such simple things as the confusion of using ->set Cheers! Rick -------------------------------------------------------- �� � � � � � There are 10 kinds of people: �� those that understand binary, and those that don't. -------------------------------------------------------- �� The day Microsoft makes something that doesn't suck �� � is the day they start selling vacuum cleaners --------------------------------------------------------
