This is a summary of last 2 weeks:
1- Rename module DateTime::Event::SpreadSheet
2- New methods start_set() and end_set()
3- New method DateTime::SpanSet->span_intersection()
4- New methods set_map() and set_grep()
5- Set methods should not operate in place.
I'd like to have some of these finished, before starting to work on CVS.
---
1- Rename module DateTime::Event::SpreadSheet
Dave Rolsky wrote:
> This looks really cool, but I don't think that's the right name for it,
> nor am I sure that the whole spreadsheet metaphor (methods called cell,
> etc.) is really appropriate.
Rick Measham was also working on this:
> However what I wanted to do was to be able to 'discover' that $now was
> a part of both $this_year and $today.
>
> What I'm working on at the moment is not using spanset, but just a hash
> of spans and spansets:
> $calendar = {
> 'sundays' => spanset of sundays,
> 'today' => span of today,
> 'this_year' => span of this year,
> 'sunrise' => set of datetimes
> }
The module name choices are:
DT::Event::Attributes # Dave Rolsky
DT::Event::NamedEvents
DT::Hash # Yitzchak Scott-Thoennes
DT::Event::Classify # Matt Sisk
DT::Event::Correlate
DT::Event::Docket
DT::Event::Named # Flavio S. Glock
DT::Event::Spreadsheet
2- New methods start_set() and end_set()
Reinhold May wrote:
> I'd like to be able to access all start times respectively
> all end times of the SpanSet, preferably as sets. I could use
> the as_list() function to get a list of spans and simply make up
> a new set with their start()/end() times. But I can't handle
> recurrences that way.
Dave Rolsky wrote:
> Why not just offer an explicit to_set method for DateTime::SpanSet, that
> "does the right thing" (whatever that may be ;)
3- New method DateTime::SpanSet->span_intersection()
Reinhold May wrote:
> If I do an intersection (whether with iterator->next($span)
> or $spanset->intersection($span) or even
> $spanset->as_list($span)), I get a SpanSet that can have,
> depending on where the intersection span starts and ends, a cut
> first span and a cut last span:
>
> |----| |----| |----| |----| # Source SpanSet
> |----------------| # intersection Span
>
> |--| |----| |--| # Resulting SpanSet
>
> what I actually need is a set of unmodified spans intersected by
> that span:
>
> |----| |----| |----| # Wanted resulting SpanSet
4- New methods set_map() and set_grep()
Andrew Pimlott wrote:
> As an immediate reaction from someone who hasn't used any of the
> Set/Span modules, I don't like that last part. One, it's too easy for
> someone who only skims the documentation to miss it, and end up with a
> very subtle bug. Two, lots of functions return undef, so people are
> going to end up with ugly code like
>
> $set->iterate( sub { myfunc($_); 1 } );
>
> just to avoid the effect. I think if you want to be able to modify the
> set, you should provide different methods for that. ->map and ->grep
> come to mind.
Andrew Pimplott also submitted this to iterate() docs:
> This method modifies a set by applying a callback function to each
> element. The element is replaced by the return value of the
> function unless the function returns undef, in which case the
> element is removed.
> Also, make it clear in the document that the function is not called
> immediately, and so it is unwise to count on any side-effects.
5- Set methods should not operate in place.
Dave Rolsky wrote:
> Actually, this doesn't encourage it and we _still_ need iterate() for
> sure. We can have set_map() only be used to create a new set, and
> iterate() only be used to alter the current set in place.
Why not have _all_ methods create new sets?
- Flavio S. Glock
