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:
WebCat2 - [format thousands] (1997)
Shopping Cart - prices? (1997)
showif field is number (1997)
Transfering [text] variables (2000)
webdna page not found redirect (2007)
Exclamation point (1997)
problems with 2 tags (1997)
SKU (1997)
FEW QUESTIONS (1997)
installing webcatalog problem. HELP! (1998)
[ShowCart] and GET vs. POST (1997)
HTTP header line is too long? (1997)
[writefile] (1997)
Help name our technology! (1997)
Multiple Merchant Accounts? (1997)
[WebDNA] Successful, working WebDNA7/CentOS install? (2013)
Summing fields (1997)
Db design question (relational vs. flat?) (1998)
Re:Running 2 two WebCatalog.acgi's (1996)
Separate SSL Server (1997)