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
