Re: Scoping rules in WebDNA 4.0
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 29344
interpreted = N
texte = I like it the lazy way. >Here's another small discussion to help me decide which way to go. >This information is confidential, and should not be discussed outside >this list. > >Background: it is sometimes possible to have several variable or >context names overlap in such a way that the user gets confused about >which one holds precedence in a particular scope. The [server:date] >vs. [orderfile:date] confusion is a classic example. The actual >implementation is actually very simple to predict, in that scoping >always goes 'from inside outwards', but sometimes this is not >intuitive. > >In earlier versions of WebCatalog, we had more explicit scoping, such >as [math]x[/math] to retrieve the value of a math variable. Due to >overwhelming requests to simplify the syntax, we created a 'lazy >syntax' which allowed constructs like [x]. Naturally this introduced >new confusion, as people had trouble knowing which scope the value of >x was to be displayed. > >So now we are back to square one, and the question is, what scoping >rules are appropriate?. If we require explicit scope when >retrieving variable value, we can avoid many of the confusions that >people have now when they happen to name their own variables or >database fields the same as existing context or variable names. But >of course the syntax then becomes more difficult to read. > >Original syntax: >[math]x=12[/math] >[search db=blah] > [founditems] > [x] <-- returns 12 if there are no database fields named x, >otherwise return field value > [/founditems] >[/search] > >New syntax: >[math]x=12[/math] >[search db=blah] > [founditems] > [GetMathVar name=x] <-- retrieves math variable from explicit >math context > [GetFoundItemsVar name=x] <-- retrieves database field x from >enclosing [search] > [/founditems] >[/search] > >So every context which has tag values within it would need a >corresponding Get function, uniquely named, so that one could get >its values. And the syntax would *require* you to explicitly name >the context so you could get at the value (because it's this whole >lazy syntax that seems to mess people up). > >I personally like the current 'lazy' syntax better, because in the >vast majority of coding, you are typically using values that are >'close' to your local context, and don't even really need to think >about how it all works. We were going after non-programmers at >first, and this style made the most sense. > >Grant Hulbert, Director of Engineering ********************************** >Smith Micro, Internet Solutions Div | eCommerce (WebCatalog) >16855 West Bernardo Drive, #380 | ------------------------- >San Diego, CA 92127 | Software & Site Development >Main Line: (858) 675-1106 | http://www.smithmicro.com > Fax: (858) 675-0372 ********************************** > >############################################################# >This message is sent to you because you are subscribed to > the mailing list
. >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > >To switch to the INDEX mode, E-mail to > >Send administrative queries to ############################################################# This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
Associated Messages, from the most recent to the oldest:
I like it the lazy way. >Here's another small discussion to help me decide which way to go. >This information is confidential, and should not be discussed outside >this list. > >Background: it is sometimes possible to have several variable or >context names overlap in such a way that the user gets confused about >which one holds precedence in a particular scope. The [server:date] >vs. [orderfile:date] confusion is a classic example. The actual >implementation is actually very simple to predict, in that scoping >always goes 'from inside outwards', but sometimes this is not >intuitive. > >In earlier versions of WebCatalog, we had more explicit scoping, such >as [math]x[/math] to retrieve the value of a math variable. Due to >overwhelming requests to simplify the syntax, we created a 'lazy >syntax' which allowed constructs like [x]. Naturally this introduced >new confusion, as people had trouble knowing which scope the value of >x was to be displayed. > >So now we are back to square one, and the question is, what scoping >rules are appropriate?. If we require explicit scope when >retrieving variable value, we can avoid many of the confusions that >people have now when they happen to name their own variables or >database fields the same as existing context or variable names. But >of course the syntax then becomes more difficult to read. > >Original syntax: >[math]x=12[/math] >[search db=blah] > [founditems] > [x] <-- returns 12 if there are no database fields named x, >otherwise return field value > [/founditems] >[/search] > >New syntax: >[math]x=12[/math] >[search db=blah] > [founditems] > [GetMathVar name=x] <-- retrieves math variable from explicit >math context > [GetFoundItemsVar name=x] <-- retrieves database field x from >enclosing [search] > [/founditems] >[/search] > >So every context which has tag values within it would need a >corresponding Get function, uniquely named, so that one could get >its values. And the syntax would *require* you to explicitly name >the context so you could get at the value (because it's this whole >lazy syntax that seems to mess people up). > >I personally like the current 'lazy' syntax better, because in the >vast majority of coding, you are typically using values that are >'close' to your local context, and don't even really need to think >about how it all works. We were going after non-programmers at >first, and this style made the most sense. > >Grant Hulbert, Director of Engineering ********************************** >Smith Micro, Internet Solutions Div | eCommerce (WebCatalog) >16855 West Bernardo Drive, #380 | ------------------------- >San Diego, CA 92127 | Software & Site Development >Main Line: (858) 675-1106 | http://www.smithmicro.com > Fax: (858) 675-0372 ********************************** > >############################################################# >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to > >To switch to the INDEX mode, E-mail to > >Send administrative queries to ############################################################# This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to
Charles Kline
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
WebCat2b15MacPlugin - [protect] (1997)
Bug alert! (1997)
update on wn searching (1997)
[WebDNA] Uploading Specific File Types (2009)
GuestBook example (1997)
Great product and great job ! (1997)
redirect with frames (1997)
Summing fields (1997)
Web Catalog vs. ICAT (1997)
File not found error message (1998)
Generating unique SKU from [cart] - FIXED! (1997)
Need Sample Template - just purchased (1997)
Using Applescript to process WebCatalog functions (1998)
can WC render sites out? (1997)
WebCat2b15MacPlugin - [protect] (1997)
Relative URL quirk (1999)
wrong input values? (1997)
default value from Lookup (was Grant, please help me) (1997)
webcat2b12 CGI -- Date comparisons (1997)
not interpreting Q (2001)