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:
Browser Check for WebDNA compatability (1999)
Replacing a variable within a variable. (1998)
WebCat 3.04-3.07 plug-in dying on server.... (2000)
WC2.0 Memory Requirements (1997)
Logging purchases (1997)
Problems getting parameters passed into email. (1997)
Menu to select product variations (1997)
Two prices in shoppingcart? (1997)
4.51 Triggers (2003)
Return records from another (1997)
showif and cart (1997)
Webcatalog, Webstar and Crasharama (1999)
[math] show=F exists? (1997)
Close Databases Crash? (1998)
stats (2001)
php vs WebCatalog (2000)
Sort Order on a page search (1997)
Running 2 two WebCatalog.acgi's (1996)
Was 5.0 Pricing, now Sandbox versus Website and ruminating (2003)
Limit on nested [ShowIf]'s? (1997)