***************************** Team Allaire *****************************
Well, Fusedoc has always had the idea of being a lightweight PDL (program
definition language). That's one of the reasons for the Responsibilities
section.
-----Original Message-----
From: Fred T. Sanders [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 28, 2001 12:01 PM
To: Fusebox
Subject: Re: Fusedocs Q
NO PDL in fusedocs!!!
----- Original Message -----
From: "Hal Helms" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Sunday, May 27, 2001 9:56 PM
Subject: RE: Fusedocs Q
> ***************************** Team Allaire *****************************
> Fuseboxers, Lee's suggesting making some version of symbolic logic
available
> but not mandatory to use. Do you think we'd encounter the sitation where
> some people who know symbolic logic will put stuff in their Fusedocs that
> are inscrutable to the rest of us? Or do you think this would be valuable?
>
> And I'm sure even if we disagree on symbolic logic in Fusebox, we can all
> agree with Steve Nelson's point that webslugs like Nat P. should turn off
> Baywatch and do some work, dammit! Sorry. Just had to vent...
>
> -----Original Message-----
> From: lee borkman [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 27, 2001 6:48 PM
> To: Fusebox
> Subject: RE: Fusedocs Q
>
>
> Hi all,
>
> I agree that these are requirements that will probably not be EASILY
> incorporated into FuseDoc, and most of use will be happy to put then in as
> text, BUT...
>
> Clearly, the more that can be expressed in a formal language, the more we
> can do in the way o automated tools, etc. So we have a trade-off - more
> formalisation=better automation, though possibly at the expense of
> comprehensibility, learning curve, acceptance, etc.
>
> So, bear with me - I just woke up seconds ago, but I have to write
something
> before you all go to bed ;-)...
>
> WHAT IF there were a new optional sub-class of FuseDoc statement that
> signalled "here is a complex requirement expressed in the symbology of
> formal logic", or something like that. Of course, you can't really use
> formal logic symbols with a normal keyboard, but some substitution could
be
> arranged.
>
> eg.,
>
> LOGIC
> ((x = 3) AND (exists(y)) => {
> -->[attributes.z]: the volume of a cone of height x and radius y
> }
>
> So we have a header like LOGIC, then statements of the form:
> logical_condition => {
> standard_set_of_FuseDoc_attributes
> }
>
> Now that's nasty, and I daresay that nobody would ever use it or anything
> like, but perhaps the automation freaks out there (like me, or Jeff, or
> possibly HH) might see some use in it.
>
> yawn,
> time for my wheet-a-bix,
>
> LeeBB.
>
>
>
> >From: "Hal Helms" <[EMAIL PROTECTED]>
> >Yes, I agree that those examples almost certainly fall into the category
of
> >"True statements that are not expressible in Fusedoc". Sure, we could
> >create
> >a symbology that would allow us to express that, but I think you're
> >right--why bother?
> >
> >I'm more interested in the grey areas between something Fusedoc clearly
> >should be able to convey and those examples of things I think should be
> >outside the realm of Fusedoc. For example, should Fusedoc be able to
> >express
> >this?
> >
> >I'll get one (and only one of the following): a, b, XOR c
> >
> >-----Original Message-----
> >From: Erik Voldengen [mailto:[EMAIL PROTECTED]]
> >> > if i get a then i will also get b
> > >
> > > or
> > >
> > > if the value of fuseaction is "XFA.onSubmitForm" I set
> > > client.CurrentUser;
> > > otherwise I set client.Unregistered.
> > >
> >
> >I wonder if it really matters if you can symbolically represent this
> >logic. Why not just use text comments to fill in the blanks for such
> >tricky situations, keeping fusedocs nice and clean.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
