RE: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread RADEMAKERS Tanguy
Another option is to roll your own date object and pass an instance of it into the function instead. Actually, this could be one way around the whole type safety / null problem with cf - develop a system of object types (Date.cfc, Integer.cfc, String.cfc, etc). Then you could choose to work with

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread Bill Rawlinson
September 2005 13:11 To: CFCDev@cfczone.org Subject: RE: [CFCDev] Default for Dates in a Transfer object Another option is to roll your own date object and pass an instance of it into the function instead. Actually, this could be one way around the whole type safety / null problem with cf

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread RADEMAKERS Tanguy
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kerry Sent: Wednesday, September 21, 2005 3:21 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] Default for Dates in a Transfer object basically an isNull() method hmm, would that return true simply if the value had zero length? or only if it had

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread RADEMAKERS Tanguy
PROTECTED] On Behalf Of Bill Rawlinson Sent: Wednesday, September 21, 2005 3:32 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object Kerry, You would define you're own rule for what a NULL is for that type since you're creating the component. If a zero-length

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread Bill Rawlinson
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Rawlinson Sent: Wednesday, September 21, 2005 3:32 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object Kerry, You would define you're own rule for what a NULL is for that type since you're

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread RADEMAKERS Tanguy
Sent: Wednesday, September 21, 2005 4:00 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object or, if you did want to null the object you could have a method, setNull() which just turns the flag back on. cfset myString = createobject(component,types.String

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread Bill Rawlinson
Of Bill Rawlinson Sent: Wednesday, September 21, 2005 4:00 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object or, if you did want to null the object you could have a method, setNull() which just turns the flag back on. cfset myString = createobject

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread Kerry
@cfczone.org Subject: RE: [CFCDev] Default for Dates in a Transfer object but then you'd be open to the weird situation of having an object that claims it is null but contains a value. If you need a null object, just create a new one and don't initialize it. /t -Original Message- From: [EMAIL

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread Patrick McElhaney
Maybe you could have two different objects: a value object and a null object. For example, you could have a Date object that always has a value, and a NullDate that extends Date and doesn't have a value. - You don't skip the init method. (Bill's concern.) - An object can't simultaneously have a

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-21 Thread RADEMAKERS Tanguy
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick McElhaney Sent: Wednesday, September 21, 2005 5:51 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object Maybe you could have two different objects: a value object and a null object. For example, you could have

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Barney Boisvert
If you don't require a date, then you can't qualify the argument as a date, because CF has no concept of NULL. The closest you can get is saying is equivalent to null, and then using the string type as you propose. You should do validation inside your method like this: cfif

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Dawson, Michael
Some will say use a string data type and return an empty string. I don't much care for this option. Others will say use a date date type and return a "null" date such as 1/1/1900. Again, I don't much care for this option, either. Still more others will say throw/catch an exception if this

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Tom Young
Good point Barney. Barney Boisvert wrote: If you don't require a date, then you can't qualify the argument as a date, because CF has no concept of NULL. The closest you can get is saying is equivalent to null, and then using the string type as you propose. You should do validation inside

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Peter J. Farrell
Peter Hardy wrote: Hi guys, I've seen this on the forum before but I'm can't remember the answer at all. I've created a transfer object that takes amongst others a couple of date parameters. Trouble is, they are optional parameters so sometimes they are a valid date and sometimes they

RE: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Nando
these. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Tuesday, September 20, 2005 9:29 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object If you don't require a date, then you can't qualify the argument

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Patrick McElhaney
On 9/20/05, Peter Hardy [EMAIL PROTECTED] wrote: I've created a transfer object that takes amongst others a couple of date parameters. Trouble is, they are optional parameters so sometimes they are a valid date and sometimes they are equal to . If my cfargument type to date cf just throws an

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Barney Boisvert
The problem is that 'string' is way too lenient, because you want to allow dates, the empty string and that's it. A type of 'string' will also allow hulabaloo to be passed without error, which is undesirable. Of course, you HAVE to use type=string in order to circumvent CF's weird type system,

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Peter Hardy
Boisvert Sent: Tuesday, September 20, 2005 9:29 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Default for Dates in a Transfer object If you don't require a date, then you can't qualify the argument as a date, because CF has no concept of NULL.The closest you can get is saying is equivalent to null

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Patrick McElhaney
On 9/20/05, Barney Boisvert [EMAIL PROTECTED] wrote: If you ask me, CF's lack of NULL is really quite a burden. CF is a loosely typed language, which is fine, but then they came and added in strong typing all over the place, but didn't provide the ability to use NULL, so the strong typing is

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Patrick McElhaney
On 9/20/05, Barney Boisvert [EMAIL PROTECTED] wrote: The problem is that 'string' is way too lenient, because you want to allow dates, the empty string and that's it. A type of 'string' will also allow hulabaloo to be passed without error, which is undesirable. So make an error. Throw an

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Barney Boisvert
So make an error. Throw an exception if the string isn't empty and can't be converted to a date. Which is exactly what the code I proposed earlier does. (and may as well just leave the attribute off). Not that I recommend that I'm on the verge of recommending it. Strong typing is a

Re: [CFCDev] Default for Dates in a Transfer object

2005-09-20 Thread Peter Hardy
Yeah, me too. I tried loose typing for a while but it drives me crazy. As for ColdFusion being easy to use, yip, it can be. It can also be a right royal pain in the tucus. And don't get me started on the whole RADness of it. Sorry guys, am having a grrr day. Will play nice tomorrow I promise:)