Date coercion

[Dave Winer]

Since this wasn't actually offlist, this kind of discussion needs to be
on-list somewhere. Maybe not this one, but some developer list where changes
like this can be RFC'd for breakage issues. Now that I'm on the user-side of
the fence, I can't afford to have my system go down because of a change that
breaks workarounds. In a programming system like Frontier, the bugs are part
of the way it works. You can see it in Chris's reaction, he had already done
a workaround! Since that verb has been in the language for half a decade, or
more, it's reasonable to assume it's been worked around elsewhere, perhaps
even in frontier.root, mainResponder.root or manila.root, where a change in
functionality could break every user of the software. We must have some
insulation from that. In the past I could veto these changes before they
happened, but now I can't. I want to at least have a *say* in what happens,
to be able to warn UserLand of breakage. Dave

----- Original Message -----
From: "Jake Savin" <jake at userland.com>
To: <Frontier-Users at userland.com>
Sent: Thursday, May 29, 2003 6:02 AM
Subject: Re: Date coercion


Hi Chris, replying offlist due to political sensitivities...

The fix was already applied to Radio, but unfortunately I had to back
off a bit due to potential breakage issues. Rather than make date
coercion always fail when an invalid date is passed to date(), I've
added an optional parameter. If you want to get an error when an
invalid date is passed in, use something like this:

date ("foo", true) //will cause an error

Again, this change was applied also to Radio, so you'll have the
functionality you need there, as long as you pass in true for the value
of the 2nd parameter.

Thanks, and sorry the fix was not ideal...

-Jake

On Wednesday, May 28, 2003, at 02:52 PM, Chris Bunch wrote:

> Thanks Jake -
>
> Quick work! Now I'll have to delete my workaround. ;-)
>
> Will you fix this in Radio as well? That’s where I usually test things
> out.
>
> C
> __________________________________
>
>
>
>> Hi Chris,
>>
>> This was indeed a bug. A fix has been released. To get the fix, update
>> Frontier.root.
>>
>> Thanks,
>> -Jake
>>
>> On Wednesday, May 28, 2003, at 11:13 AM, Chris Bunch wrote:
>>
>>> According to DocServer (http://docserver.userland.com/coercion/date),
>>> coercing to a date should fail with an error if the object being
>>> coerced is
>>> not of the appropriate type.
>>>
>>> This appears not to work as billed omm (Mac OS X).
>>> Try the following in QuickScript:
>>>
>>> date("31-Jan-2002")  -- works OK, displays appropriate date string
>>> date("31-Feb-2002")  -- returns true: does not throw an error
>>> date("garbage")      -- returns true: does not throw an error
>>>
>>> Does DocServer need updating or is this a Bug?
>>>
>>
>>
>