RE: instance data for DateTime derived classes
On Wed, 28 Mar 2007, Boorstein, Daniel B wrote: Are you saying that in general you don't expect classes derived from DateTime to include additional instance data in the conventional manner (tacking it onto $self)? I'm not even sure I expect classes to derive from DateTime at all. DateTime.pm is written to make this possible, but as has been discussed in this thread and others, there are problems with it. You'll have to override a number of methods in order to handle that extra data, since internally DateTime.pm creates new objects in order to implement date math. In the particular case of providing information about an event, I really think that subclassing is the wrong solution. In fact, in general, subclassing is the wrong solution for many, many things, especially in Perl, which makes subclassing harder than many languages. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
RE: instance data for DateTime derived classes
> From: Dave Rolsky [mailto:[EMAIL PROTECTED]
>
> On Wed, 28 Mar 2007, Rick Measham wrote:
>
>
> > I'd suggest we have a purpose built $self->{data} for
> > hanging such stuff and
> > make sure that anything in there is preserved across
> > mutations and clonings.
>
> I really don't think this data belongs in the DateTime
> object. There's
> something odd about the idea that two otherwise "identical"
> objects could
> have different data under the hood, where one knows about an
> event and one
> doesn't.
Are you saying that in general you don't expect classes derived
from DateTime to include additional instance data in the
conventional manner (tacking it onto $self)?
Thanks,
- Dan Boorstein
Re: instance data for DateTime derived classes
On Wed, 28 Mar 2007, Rick Measham wrote:
Boorstein, Daniel B wrote:
I realize this is my problem since I broke encapsulation, but I'm
wondering if others have dealt with this already. Is there a designated
means for derived classes to add custom instance data? I've perused the
docs, but didn't see anything specific for authors of derived classes.
There's been a few times where I wanted to hang data off a DT, especially for
DT::Event modules
Someone had proposed a while back that DT::Event modules support returning
an object that contains additional info beyond the datetime. I'd like to
pursue that (or have _someone_ pursue it ;)
I'd suggest we have a purpose built $self->{data} for hanging such stuff and
make sure that anything in there is preserved across mutations and clonings.
I really don't think this data belongs in the DateTime object. There's
something odd about the idea that two otherwise "identical" objects could
have different data under the hood, where one knows about an event and one
doesn't.
Here's some ideas ...
All datetime-returning methods in event modules should return two objects
in list context:
my ( $dt, $event ) = $events->next();
Or maybe event modules support some sort API where you give it a datetime
and it tells you something about it:
my $event = $event->info_for_datetime($dt);
I'm kind of leaning towards the latter.
There's some open questions:
* What is $event? Is it an object, a hashref, what? Maybe it's different
for each event module?
* How do modules that don't have anything extra to say express that?
undef? a special null object?
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: instance data for DateTime derived classes
Boorstein, Daniel B wrote:
I realize this is my problem since I broke encapsulation, but I'm
wondering if others have dealt with this already. Is there a designated
means for derived classes to add custom instance data? I've perused the
docs, but didn't see anything specific for authors of derived classes.
There's been a few times where I wanted to hang data off a DT,
especially for DT::Event modules
I'd suggest we have a purpose built $self->{data} for hanging such stuff
and make sure that anything in there is preserved across mutations and
clonings.
There was talk ages ago about life span controls however:
$dt = $easter;
print $dt->{data}{EventName};
# Easter Sunday
$dt->add( days => 4 );
print $dt->{data}{EventName};
# Easter Sunday
So now it's incorrect. Four days after Easter isn't Easter any more, so
the EventName shouldn't survive any 'add' that takes it past midnight,
but it should survive any 'add' that leaves it still on the same 'day'
How do you do that?
* One option is to ignore such things and just leave the data hanging
around. If someone changes the date, it's their own damned fault.
* Another option would be a callback class method and use
$self->{data}{callback} to store an arrayref of packages that want a
callback on any mutation:
sub add_duration {
...
...
foreach( @{ $self->{data}{callback} } ){
$_->callback( $self );
}
}
Then in DateTime::Event::Easter, there's a sub callback that checks the
data in the object and adjusts, deletes etc., as appropriate
print Dumper($dt->{data});
# { callback => [ 'DateTime::Event::Easter' ], initial_date =>
'2007-04-08', event_name => 'Easter Sunday' }
package DateTime::Event::Easter;
sub callback {
if ($dt->ymd('-') ne $dt->{data}{initial_date}){
delete $dt->{data}{initial_date};
delete $dt->{data}{event_name};
$dt->{data}{callback} = [
grep { $_ ne 'DateTime::Format::Easter' }
@{$dt->{data}{callback}}
];
}
}
__END__
Just a thought on how we can do such things.
Cheers!
Rick Measham
RE: instance data for DateTime derived classes
No, you got it right, but I think a similar approach can be taken to overload a couple of key points in DT that can preserve the values then re-set them later. I used a sub-routine to do this since I had to call it from more than one constructor. Jim > -Original Message- > From: Boorstein, Daniel B [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 10:14 AM > To: datetime@perl.org > Subject: RE: instance data for DateTime derived classes > Having given it a quick viewing it looks like your new() calls > $_454_allocate->(), which only sets your custom attributes to undef, > rather than preserve their prior values. Have I misread it? Does it do > more than just ensure that the keys exist? > > Thanks, > > - Dan Boorstein >
RE: instance data for DateTime derived classes
> -Original Message- > From: Jim Bacon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 9:51 AM > To: datetime@perl.org > Subject: RE: instance data for DateTime derived classes > > Take a look at how I overloaded "new" in > DateTime::Fiscal::Retail454. I had > the same problem you describe. > Having given it a quick viewing it looks like your new() calls $_454_allocate->(), which only sets your custom attributes to undef, rather than preserve their prior values. Have I misread it? Does it do more than just ensure that the keys exist? Thanks, - Dan Boorstein
RE: instance data for DateTime derived classes
Take a look at how I overloaded "new" in DateTime::Fiscal::Retail454. I had
the same problem you describe.
Jim
> -Original Message-
> From: Boorstein, Daniel B [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 27, 2007 9:43 AM
> To: datetime@perl.org
> Subject: instance data for DateTime derived classes
>
>
> Hello All,
>
> I have a package called Qf::DateTime that does a "use base 'DateTime'".
> From here I've added convenience methods and overridden a few of the
> core DateTime methods to my liking.
>
> In doing this I was a bad OO programmer and broke encapsulation. In
> Qf::DateTime objects I hung various member variables off of $self, such
> as $self->{'_qf_holidays'} to support my custom methods.
>
> This has worked very well for several years now. Unfortunately, due to
> the recent necessity to upgrade DateTime and DateTime::TimeZone, the
> custom data attached to the object gets stripped after calling
> $dt->add() for example. At a glance, it appears this happens at the end
> of add_duration() when from_object() is called.
>
> I realize this is my problem since I broke encapsulation, but I'm
> wondering if others have dealt with this already. Is there a designated
> means for derived classes to add custom instance data? I've perused the
> docs, but didn't see anything specific for authors of derived classes.
>
> Thanks,
>
> - Dan Boorstein
>
instance data for DateTime derived classes
Hello All,
I have a package called Qf::DateTime that does a "use base 'DateTime'".
>From here I've added convenience methods and overridden a few of the
core DateTime methods to my liking.
In doing this I was a bad OO programmer and broke encapsulation. In
Qf::DateTime objects I hung various member variables off of $self, such
as $self->{'_qf_holidays'} to support my custom methods.
This has worked very well for several years now. Unfortunately, due to
the recent necessity to upgrade DateTime and DateTime::TimeZone, the
custom data attached to the object gets stripped after calling
$dt->add() for example. At a glance, it appears this happens at the end
of add_duration() when from_object() is called.
I realize this is my problem since I broke encapsulation, but I'm
wondering if others have dealt with this already. Is there a designated
means for derived classes to add custom instance data? I've perused the
docs, but didn't see anything specific for authors of derived classes.
Thanks,
- Dan Boorstein
