Scoping rules in WebDNA 4.0
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 29328
interpreted = N
texte = 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
Associated Messages, from the most recent to the oldest:
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
Grant Hulbert
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:
emailer (1997)
[WebDNA] Digest from talk@webdna.us (2018)
Download URL & access on the fly ? (1997)
Dynamically Generated Pages & WC? (2000)
[WriteFile] problems (1997)
Limiting user access to .tmpl files (1997)
Include a big block of text (1997)
[replace] fails with too many formvariables? (2000)
WebCat2.0 [format thousands .0f] no go (1997)
Cart ID (1999)
WebCommerce: Folder organization ? (1997)
Online magazine- monthly updates and such (1999)
Card clearance, problems - solutions? (1997)
WCS Newbie question (1997)
[WriteFile] problems (1997)
[TaxableTotal] - not working with AOL and IE (1997)
# fields limited? (1997)
Problem displaying search result (1997)
MS Access data conversion (2001)
Limitations on fields? Server is crashing (1997)