Just to jump in on the tail of a conversation I've so far had no part in
<grin>
My own opinion is that to introduce a standard, even an optional one, of
using something like formal logic (which I for one haven't so far had the
opportunity to learn) adds a layer of possible complexity that belies the
purpose of fusedocs. What happens a year or so down the track when half a
dozen fuseboxers have written a bunch of fuses full of notation in this
format, then try to cooperate with coders / designers who don't know any of
it? Once again we're back to square one as far as communication goes.
I always saw the fusedocs as giving me (among other things) the ability to
design a fuse and give it to a coder or designer WITHOUT having to sit down
and explain to them how it's supposed to work. The attributes section of
the fusedoc is important, even in regards to our designers here who know
almost no code - but enough to type #variablename# in the right place.
Adding a complex notation form would certainly bugger that right up.
I don't know - perhaps I'm the only coder here uncivilised enough not to
know formal logic <g> but I just wonder at the idea of adding complexity to
a concept who's entire focus is simplifying things. Is it such an enormous
job to find / develop a simplistic and human readable notation that would
cover the conditions we require?
At the end of the day I personally don't know too many situations where I'd
need incredibly complex conditional logic in a comment block identifying
attributes. In the past, when there has been a situation I thought required
further clarification I either added it to the responsibilities block or I
created a new block explaining the conditions on the attributes block...
-----------------------------
"Life is poetry, write it in your own words..."
Toby Tremayne
Code Poet and Zen Master of the Heavy Sleep
Show Ads Interactive
359 Plummer St
Port Melbourne
VIC 3207
P +61 3 9245 1247
F +61 3 9646 9814
ICQ UIN 13107913
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Monday, 28 May 2001 11:57 AM
To: Fusebox
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
