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:
One more time (1997)
Proper file locations (1997)
Attn: Bug in GeneralStore example b15 (1997)
Shared conversion under WebTen (1998)
Next X hits (1996)
two unique banners on one page (1997)
Google does it... can WebDNA? Showing only the section (2003)
Protect (1997)
SSL and reg web* (1997)
Country & Ship-to address & other fields ? (1997)
PCS Frames (1997)
I'm Baaaaaaaaaack - Questions! (2000)
WebCat2 - Getting to the browser's username/password data (1997)
OUTSIDE LINKS TO SHOW SHOPPING CART????????? (1998)
Find one not all, code not working (2003)
Getting URL's entered manually (1997)
Nested tags count question (1997)
[WebDNA] Emailer breaking format (2015)
More on the email templates (I like it) (1997)
searching for last file in a directory (1999)