***************************** Rock Star Programmer
*****************************
it's not a matter of which one is better. It's a matter of which one
everyone should use. Without that small amount of standardization making
tools to assist developers would be near impossible.
Steve Nelson
"Fred T. Sanders" wrote:
>
> It would be nice if people put this much energy into actually get work done.
> :)
> If people want to use javascript/perl/php (and I'm sure I missed a few)
> styled conditional logic in there
> freakin fusedocs, who cares. "|" instead of "or" ohhhhhhhhhhhhhhhhhh I
> saved a whole character while typing it out.
> Yes I know there's more that people want to add, but what does it really
> buy? Its like quibbling over --> or ==> for a variable that's going to be
> passed in, just because it doesn't screw with the color coding in studio.
>
> Fred
>
> ----- 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
