I've already given my opinion on the matter and don't want to keep
restating it, so I'll keep it brief, I hope.
At 8.28 +0200 2000.06.27, Steffen Beyer wrote:
>Hello Chris Nandor, in a previous mail you wrote:
>> Note that "Date::Object" tells me not a jot about what the module
>> actually does for me.
>
>It is supposed to tell you that it allows you to handle points in
>date/time as objects (and by inference, that it allows you to treat
>date/time points as a built-in data type, i.e., using Perl's built-in
>operators like <, >, ==, !=, +, - etc. for operations, instead of a
>proprietary functional interface).
The name gives absolutely no hint that you can use overload operators
with it. Object != Overloaded Operators. And even if it did, that
still tells me nothing of importance, unless I know WHICH operators.
Is it numeric operators? String operators? All of the above? Is it
for converting dates, calculating dates, parsing date strings,
formatting date string?
>BTW, one of the objectives (through a more "standard" interface) is to
>make the interface more intuitive so that people like you ;-) do not
>NEED to read the docs before using the module!
I hope you aren't serious.
>> Maybe there is not a need for this new module? Just a thought. Good luck,
>
>I already hear the scream of the couple of people in my mind who explicitly
>asked me for this module! :-) (They did!)
I had someone ask me for an OOP interface to MP3::Info. MP3::Info
right now returns a hashref with all the data in it. I asked what
advantage an OOP interface would provide. He said, "I like OOP. I
do everything in OOP." The fact that someone asked you for it
doesn't mean it is a good idea. That's not to say it isn't a good
idea. The project sounds interesting. But I would prefer a name
like "Date::Feebleglarb" to "Date::Object". Neither means much to
most users, and the former at least doesn't pretend to.
That said, since the main point is not Object but Overload, perhaps
Date::Overload would be more meaningful. The word "Object" means
next to nothing. There is no way to reasonably infer anything
interesting about the module from the fact that you use objects
instead of regular ol' functions (or XS instead of Perl). For all a
user knows, you just call methods exactly as you would call
functions, except from an object, instead of exporting the functions.
But with "Overload", at least now I know you are probably going to be
doing some overloading of operators, even if I still don't know what
I can do with those dates and which operators are available.
Just one last thought: I reckon most people don't think "I need to
work with dates," they think "I need to find the number of days
between these two dates," or "I need to format dates in French
24-hour Zulu time," or "I need to parse this date written by a
computer on Pluto." I don't think many people will look at
"Date::Object" and think "that will solve my problems!" since it
doesn't appear from the name to solve anything or do anything except
convert a date into an object. It makes dates into objects, but
doesn't say what you can DO with those objects. That's the whole
point here.
--
Chris Nandor | [EMAIL PROTECTED] | http://pudge.net/
Andover.Net | [EMAIL PROTECTED] | http://slashcode.com/
