Static objects with dynamic wrappers?

On January 12, 2003, at 07:29 AM, Antonios Christofides wrote:

> (b) It's faster to use
>       ($year, $month, $day) = datetime_object -> strftime('%Y', '%m', 
> '%d');
>     than
>       $year = datetime_object->year;
>       $month = datetime_object->month;
>       $day = datetime_object->day;
>     because in the second case the same conversion from
>     datetime_object internal format has to be done three times.

It'd be easy enough to have a method that returned all three values at 
once, such as ($year, $month, $day) = $dt->ymd_list().

However, I think the goal is for this conversion to be done only once, 
with the result cached under another hash-key in the date-time object. 
With the performance problems out of the way, people will be free to 
use whichever interface is more appropriate to their task.

In order to do this conversion caching, we need to either use static 
date-time objects, which are never changed after their creation, or 
else use some kind of updating logic that knows how to clear out those 
cached conversions when the base data is updated.

I was originally unenthusiastic about static date-time objects, but 
then I realized that it'd be reasonably straightforward to build a 
variable wrapper object, which could then be used to hold a series of 
static objects:

   my $dth = DateTime::Handle->new( ... );
   # This would just call DateTime::Gregorian->new(...) and
   # return a reference to a reference to that object, so that
   # $$dth contains the underlying static DateTime object.

   $dth->strftime( ... );
   # All method calls on the Handle object are passed through
   # to the underlying static object, except as noted below.

   $dth->add( ... );
   # If the method called on the underlying object returns another
   # DateTime object, and if the call is a void context, then
   # the Handle object stores the new object reference.

   $dth->strftime( ... );
   # This method call will now be sent to the new static
   # object returned by the add(...) method call above.

Theoretically, this same type of handle could also be used to isolate 
the user from changes in the underlying datetime object's class:

   $dth->convert_to('Mayan');
   # Replaces our old DateTime::Gregorian object with a
   # DateTime::Mayan equivalent.

   $dth->strftime( "%L, %M %m, %W %w" );
   # Method calls are handled by DateTime::Mayan or its superclass.
   # Other calendars might have different strftime specifiers.

I'm not sure quite what to call this class, but the pattern of a 
reference to a reference reminds me of an old MacOS memory-management 
technique called handles... I'm sure there's something more intuitive: 
DateTime::Variable? DateTime::Traveller?

-Simon

• Static objects with dynamic wrappers? by Matthew Simon Cavalletto
• Re: Static objects with dynamic wrappers? by Dave Rolsky