On 13/2/03 3:53 pm, Dave Rolsky at [EMAIL PROTECTED] spake thus:
> The problem is that in the future there may be format modules for which
> parameters need to be set on a per-object basis. For example, a "human
> language" parser might take an argument to set the language.
Point taken, but I'll think about it.
>> For clarity, the above should be:
>> my $ical_datetime = DateTime::Format::ICal->new;
>> my $dt = $ical_datetime->parse_datetime( '20030117T032900Z' );
>>
>> my $ical_duration = DateTime::Format::ICal->new;
>> my $dur = $ical_duration->parse_duration( '+P3WT4H55S' );
>
> How is that clearer?
Its now clear than the duration has nothing to do with the point-in-time.
When they both use the same object, they look somehow related.
>> If we want to keep it OO would be that DateTime::Format::ICal->new replaces
>> parse_datetime and takes an iCal date/time string. It then returns a
>> DateTime::Format::ICal object whose methods are all inherited from DateTime.
>
> No, no, no. We're not going to have lots and lots of DateTime.pm
> subclasses. The only reason to subclass DateTime.pm is to change the
> _implementation_, not to add formatting or parsing features.
>
> What if you need to parse iCal and output ISO8601? What subclass would
> you use?
Hmmm .. I did point that out in my original draft of my post .. must have
edited it and forgot to paste it back in.
>> I think this module really should just contain subs rather than methods. I
>> imagine the reason for it not returning its own object is so that different
>> formats can be input and output.
Ahh, there it is.
>> <code>
>> use DateTime::Format::iCal;
>> use DateTime::Format;
>>
>> my $DateTime =
>> new(DateTime::Format::iCal::parse_datetime('20030117T032900Z'));
>
> What is new()? A function? Should that be DateTime->new?
Yes it should be, sorry.
>> print $DateTime->format(DateTime::Format::iCal::format_datetime());
>> </code>
>
> I don't think this code is easier to understand, anyway.
Personal opinion. The only thing that makes it difficult to read is that the
call to the function contains the long module location. Maybe
DateTime::Format::iCal would import datetime_format_ical() etc.
> Yes, the object for the iCal format is pointless, but I'd like to have the
> same(-ish) API for all format modules. Also, I don't really like the idea
> of some of the DateTime suite modules being OO, and others functional.
> That's too awkward.
I disagree, and disagree strongly. A module should do what a module should
do. If there a module returns an object, there should be a use for that
object. OO isn't the savior of the world, only a handy option in the
programmer's belt.
If the behavior is functional, the module should be functional.
If the behavior is object based, make it OO.
This is a fundamental for me and I think its way more confusing to have a
useless object than to have a module that is functional that is related to a
module that is OO. There are plenty of times that we all work with modules
of varying types.
My comments here, like your replies to my post, are personal opinion, but I
do hope that you can take them aboard without prejudice to your own
preferences.
Cheers!
Rick Measham
--------------------------------------------------------
�� � � � � � 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
--------------------------------------------------------
