Re: Scoping rules in WebDNA 4.0
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 29365
interpreted = N
texte = Lazy scoping is fine, as long as the rules are stated explicitly, so we can determine the precedence. I have no problem with the thought that the same variable name can have different meanings depending on the context that contains it, but then I am a Perl Hacker in real life ;~0I also use an editor that can be completely reprogrammed to generate the correct code easily so if you wanted to go with the faceted approach, I'm OK with that, i.e. [dbname.date] vs [cart.date] vs [sys.date]John Peacock ____________________Reply Separator____________________ Subject: Scoping rules in WebDNA 4.0 Author:
Date: 3/20/00 5:25 PMHere'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:
Lazy scoping is fine, as long as the rules are stated explicitly, so we can determine the precedence. I have no problem with the thought that the same variable name can have different meanings depending on the context that contains it, but then I am a Perl Hacker in real life ;~0I also use an editor that can be completely reprogrammed to generate the correct code easily so if you wanted to go with the faceted approach, I'm OK with that, i.e. [dbname.date] vs [cart.date] vs [sys.date]John Peacock ____________________Reply Separator____________________ Subject: Scoping rules in WebDNA 4.0 Author: Date: 3/20/00 5:25 PMHere'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
jpeacock@univpress.com
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:
Running subtotal? (1998)
X etc.... (1999)
Re:2nd WebCatalog2 Feature Request (1996)
ANother SHOWIF problem (1997)
reading a email (2000)
PCS Frames (1997)
Netscape (1997)
[Price] (1997)
Sense/Disallow HTML tags during $Append (1997)
Online reference (1997)
Duplicate Cart ID (2001)
Running 2 two WebCatalog.acgi's (1996)
WebCat 4.0.1 (2000)
[numfound] within summ=t (2000)
Error Lob.db records error message not name (1997)
php vs WebCatalog (2000)
WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997)
embedded showif statements (2000)
WebCat2_Mac RETURNs in .db (1997)
[WebDNA] SOAP support (2014)