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:
Too many lines too add in one go (2003)
Running _every_ page through WebCat ? (1997)
HTML file size limit (1998)
NT [delete] (1998)
[WebDNA] WebDNA slow processing (2011)
How does 4DWebSTAR V's cache work? (2002)
selectively replacing records within a [founditems] (2000)
convertWords... NEW (2001)
Using a database with a short url (2000)
Disappearing data (2002)
WebCat2b13MacPlugin - [math][date][/math] problem (1997)
Contribution (2000)
Document Contains No Data! (1997)
[WebDNA] anyone build a webdna tab library for dreamweaver? (2008)
All choice in popups (1997)
TCPSend / Netscape Server 4.1 (2003)
Fufillment e-mail? (1998)
dates and hex formatting (1997)
unique ascending numbers (2003)
creative use of webcatalog (1998)