Re: Set/Get methods

[Bruce Van Allen]

On Friday, January 24, 2003, at 03:14 PM, Dave Rolsky wrote:

On Fri, 24 Jan 2003, Bruce Van Allen wrote:

be updatable at all. It appeared to me that consensus formed to have
objects static, and updating would be done via cloning:

I wouldn't say there was consensus ;)

So many threads and sub-threads...

As I said previously, it's appealing from an _implementor's_ standpoint,
and very logical, but I'm not sure that it actually makes for an API.

Yes, I was definitely seeing it as reducing the burden on the class's internals. But also for my applications, I'd prefer DateTime to be sleek, strong, and fast, because I know I'll be building things around it. Clever is less important at this level if it means lots more code.

At the moment, I'm leaning towards making the object mutable, either via:
$dt->day(6);
_or_ by just having one mutator sub:
$dt->set( day => 6, hour => 7 );

In general I agree with Rich Bowen's argument for unified get/set methods. But in the case of DateTime it just seems like trouble to introduce this. As I suggest below, we probably wouldn't want some attributes to be mutable, so why create the expectation? It would be simpler to spell out rules for a separate set() method.

For one thing, would either approach deal with anything besides the date/time atoms (year, month, day, hour, minutes, seconds)?

$dt->set( month_name => 'January' ); # seems innocent
$dt->month_name('January'); # ditto

But what happens when:
$dt = DateTime->new(year => 2003,
month => 1,
day => 24); # init OK
$dt->week_day(); # 5 (Friday, Monday=1) # get OK
# Let's go to Tuesday
$dt->week_day(2); # Now what date is it??? # aack!

Much less:
# I try to set a custom abbreviation...
$dt->set(week_day_abbr => 'F'); # ?? For this date? for all Fridays?
$dt->add( day + 7 ); # Do some math on the object
$dt->week_day_abbr(); # 'F' or 'Fri'??

Another point is that the date/time atoms as you've described them are all numeric; if they were the only mutable attributes, this feature of the API would not be anglo-centric.

Will arguments be accepted that resolve to forms different from how the attribute is expressed?
$dt->year(); # 2003 Attribute's format is: CCYY
$dt->year( $dt2->year() + 3 ); # OK
$dt->year( '03' ); # ? ERR or 3 AD? (it's not 2003)
$dt->year( '0003' ); # OK?
$dt->year( 3 ); # OK?

So, if the objects are mutable, I'd prefer:
- the minimum set of mutabilities, probably date/time atoms only;
- any mutation ramifies throughout the object (might mean re- or de-memoizing);
- a separate 'set' method;
- however done, arguments for 'set' mode must and may only resolve to the exact form that 'get' returns:
$dt->set( year => $dt2->year() ); # OK
$dt->set( year => '463 BC' ); # ERR

Cheers,
- Bruce

__bruce__van_allen__santa_cruz__ca__