Nat, I'm not saying Harness is the authority. I'm saying Hal's definition for
Fusedoc is the authority, and the thing that makes tools like Harness even
possible.
The single-line notation makes great sense in terms of communicating mutual
exclusivity; it's just not compliant with the current definition, which my
friend Mr. Helms has just altered. <g>
Very well, I will therefore create a new version of Harness with the extra
parsing required to handle the mutually-exclusive notation. And Hal, try to
get some of the grime off that crystal ball so this doesn't happen again, huh?
;>
- Jeff
On 25 May 2001, at 23:42, Hal Helms wrote:
> ***************************** Team Allaire *****************************
> Jeff, you know I love you big-time, sailor-boy, but in this case I have to
> disagree. I think it was Mr. QvT who pointed out that you wouldn't want to
> have the square brackets around the formulation, as the information being
> conveyed is that ONE of these MUST be being passed in. Given that, this
> formulation...
>
> --> Portfolio | Cluster | Market | Region: an INTEGER
>
> ....indicates that one of them must be passed in.
>
> The problem with the way you have it laid out is that it doesn't convey the
> same information. It indicates that any or all of them MAY be passed in.
> However, I am the one at fault for not having foreseen this need in the
> Fusedoc spec and once more, in the same week, I must cry Mea Culpa, Mea
> Culpa, Mea maxima Culpa (usually trans: my fault; my own fault; my own most
> grievous fault). So, I'd put that in the hopper for version 2.0; in the
> meantime, Harness rocks the rockin' horse's rockin' house.
>
> Repenting in dust and ashes,
>
> Hal
>
>
> -----Original Message-----
> From: Jeff Peters [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 25, 2001 9:49 PM
> To: Fusebox
> Subject: RE: Fusedocs Q
>
>
> Oh, please don't say that, Hal. That goes against the Fusedoc definition
> that
> allows tools like Harness to exist. After all, the variable called
> "Portfolio | Cluster | Market | Region" can't exist, even though the
> notation
> makes sense to us humans. I'd definitely recommend
>
> --> [Portfolio]: an INTEGER
> --> [Cluster]: an INTEGER
> --> [Market]: an INTEGER
> --> [Region]: an INTEGER
>
> Harness understands this notation perfectly, without need for additional
> costly
> parsing.
>
> - Jeff
>
> On 25 May 2001, at 12:37, Hal Helms wrote:
>
> > ***************************** Team Allaire *****************************
> > That's exactly how I'd do it, Laura.
> >
> > -----Original Message-----
> > From: Riccomi, Laura [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 25, 2001 11:42 AM
> > To: Fusebox
> > Subject: Fusedocs Q
> >
> >
> > Using Fusedocs, if a script requires one and only one of a group of
> > variables, how would you show this?
> >
> > For example, if Portfolio is passed to the script, then Cluster, Market
> and
> > Region should not be passed to the script. If Cluster is passed to the
> > script, then Portfolio, Market and Region should not be passed to the
> > script.
> >
> > Having a perl background, I've been using the following notation, but I'm
> > not sure this would be totally clear to a non-Perl person:
> >
> > --> [Portfolio | Cluster | Market | Region]: an INTEGER
> >
> > How would you guys do it?
> >
> > Laura R
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
