What is a software engineer?
in [JavaScript]
|
Prev: html form in javascript variable
Next: Microsoft and attributes--will they ever figure them out?
From: Garrett Smith on 24 Nov 2009 23:57 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Richard Cornford wrote: >>> Garrett Smith wrote: >>>> The eval call, as used there, has potential to modify variables >>>> in the calling context's scope chain. Using new Function or >>>> a call to eval in global context and scope avoids that. ES5 >>>> would "fix" that: >>>> >>>> | 10.4.2: In Edition 5, indirect calls to the eval function use >>>> | the global environment as both the variable environment and >>>> | lexical environment for the eval code. In Edition 3, the >>>> | variable and lexical environments of the caller of an indirect >>>> | eval was used as the environments for the eval code. >>>> >>>> That would be a significant change, but one that would be of >>>> use to jQuery here. >>> It would be of use to anyone who wanted to dynamically import script >>> source text. It is a pity that much of the dynamic importing of script >>> source text that goes on at present is already largely inadvisable. >> Importing script source text is possible by assigning a property to a >> globally-accessible identifier. Given an |items| object: ^^^^^^^^^^^^^^^^^^^^^^^^ >> >> "if(typeof items !== 'undefined') {" >> + "items.myNewItem = { name : 'a' };" >> +"}"; >> >> What is inadvisable? > > 1. There is no `items' object. There is, at most, a property with > that name that stores a reference to an object. uh, "given an items object says there is. > 2. What does this have to do with importing "script source text"? The example posted is a string. That string could have been fetched via XHR, which can be eval'd. I should have mentioned that. > Would you not want to use source code in a template in the same > context in which you included it, as in other languages? The > global meaning should be optional. > 3. The spacing. `if' is not a function. Did you figure that out all by yourself? > 4. The assignment, if `items' refers to a host object. The intention of the hypothetical example is using a user-defined object (not a primitive, no, not a host object). That was stated in the paragraph before the example. The example did not include a call to eval or Function. The use of eval or Function constructor was part of the discussion. That should be clearer now. BTW, Thomas, I've never cared for your pedantic snits and stop sending me such emails. One more of those and I'm going to add an email filter. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 24 Nov 2009 23:59 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Richard Cornford wrote: >>> Garrett Smith wrote: >>>> The eval call, as used there, has potential to modify variables >>>> in the calling context's scope chain. Using new Function or >>>> a call to eval in global context and scope avoids that. ES5 >>>> would "fix" that: >>>> >>>> | 10.4.2: In Edition 5, indirect calls to the eval function use >>>> | the global environment as both the variable environment and >>>> | lexical environment for the eval code. In Edition 3, the >>>> | variable and lexical environments of the caller of an indirect >>>> | eval was used as the environments for the eval code. >>>> >>>> That would be a significant change, but one that would be of >>>> use to jQuery here. >>> It would be of use to anyone who wanted to dynamically import script >>> source text. It is a pity that much of the dynamic importing of script >>> source text that goes on at present is already largely inadvisable. >> Importing script source text is possible by assigning a property to a >> globally-accessible identifier. Given an |items| object: ^^^^^^^^^^^^^^^^^^^^^^^^ >> >> "if(typeof items !== 'undefined') {" >> + "items.myNewItem = { name : 'a' };" >> +"}"; >> >> What is inadvisable? > > 1. There is no `items' object. There is, at most, a property with > that name that stores a reference to an object. uh, "given an items object says there is. > 2. What does this have to do with importing "script source text"? The example posted is a string. That string could have been fetched via XHR, which can be eval'd. I should have mentioned that. > Would you not want to use source code in a template in the same > context in which you included it, as in other languages? The > global meaning should be optional. > 3. The spacing. `if' is not a function. Did you figure that out all by yourself? > 4. The assignment, if `items' refers to a host object. The intention of the hypothetical example is using a user-defined object (not a primitive, no, not a host object). That was stated in the paragraph before the example. The example did not include a call to eval or Function. The use of eval or Function constructor was part of the discussion. That should be clearer now. BTW, Thomas, I've never cared for your pedantic snits. One more of those emails and I'm going to add an email filter. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 25 Nov 2009 00:54 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Richard Cornford wrote: >>>> Garrett Smith wrote: >>>>> The eval call, as used there, has potential to modify variables >>>>> in the calling context's scope chain. Using new Function or >>>>> a call to eval in global context and scope avoids that. ES5 >>>>> would "fix" that: >>>>> >>>>> | 10.4.2: In Edition 5, indirect calls to the eval function use >>>>> | the global environment as both the variable environment and >>>>> | lexical environment for the eval code. In Edition 3, the >>>>> | variable and lexical environments of the caller of an indirect >>>>> | eval was used as the environments for the eval code. >>>>> >>>>> That would be a significant change, but one that would be of >>>>> use to jQuery here. >>>> It would be of use to anyone who wanted to dynamically import script >>>> source text. It is a pity that much of the dynamic importing of script >>>> source text that goes on at present is already largely inadvisable. >>> Importing script source text is possible by assigning a property to a >>> globally-accessible identifier. Given an |items| object: > ^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> "if(typeof items !== 'undefined') {" >>> + "items.myNewItem = { name : 'a' };" >>> +"}"; >>> >>> What is inadvisable? >> >> 1. There is no `items' object. There is, at most, a property with >> that name that stores a reference to an object. > > uh, "given an items object says there is. You clearly don't know what you are talking about. >> 2. What does this have to do with importing "script source text"? > The example posted is a string. That string could have been fetched via > XHR, which can be eval'd. I should have mentioned that. Yes, you should have. In any case, anybody aware of how `eval' would work in current implementations would never be blindly eval()ing XHR responses, regardless of what ES5 has to say about it. >> Would you not want to use source code in a template in the same >> context in which you included it, as in other languages? The >> global meaning should be optional. >> 3. The spacing. `if' is not a function. > > Did you figure that out all by yourself? No, I got me an assistant for that :-> >> 4. The assignment, if `items' refers to a host object. > The intention of the hypothetical example is using a user-defined object > (not a primitive, no, not a host object). That was stated in the > paragraph before the example. It wasn't, fool. Maybe that's what you thought, but not what you wrote. > The example did not include a call to eval or Function. The use of eval > or Function constructor was part of the discussion. That should be > clearer now. > > BTW, Thomas, I've never cared for your pedantic snits and stop sending > me such emails. One more of those and I'm going to add an email filter. You are such a complete idiot. I could have ignored your psychotic rambling about things you evidently don't have the slightest clue of, I could have exposed your idiocity in public. But I chose not to, and tried to reason with you in private instead, in the hopes that you would be a reasonable person after all. Evidently now, you are not. Go set up your e-mail filter -- your loss. Score adjusted PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Garrett Smith on 25 Nov 2009 01:15 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> Richard Cornford wrote: >>>>> Garrett Smith wrote: [snip] > Score adjusted > That is exactly what I'm talking about with pedantic snits. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Richard Cornford on 25 Nov 2009 07:07
On Nov 25, 4:57 am, Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Richard Cornford wrote: <snip> >>>> It would be of use to anyone who wanted to dynamically import >>>> script source text. It is a pity that much of the dynamic >>>> importing of script source text that goes on at present is >>>> already largely inadvisable. >>> Importing script source text is possible by assigning a property >>> to a globally-accessible identifier. Given an |items| object: > > ^^^^^^^^^^^^^^^^^^^^^^^^ >>> "if(typeof items !== 'undefined') {" >>> + "items.myNewItem = { name : 'a' };" >>> +"}"; >>> >>> What is inadvisable? <snip> >> 2. What does this have to do with importing "script source text"? > > The example posted is a string. That string could have been fetched > via XHR, which can be eval'd. I should have mentioned that. <snip> I did wonder what you were on about, and how you expected anyone to judge the (lack of) advisability of a fragment of code without any context. What you are saying is that this is an instruction to act (set the value of a property) sent from the server to the client, where the instruction and its parameters are represented by the code that takes the action. The problem I would have with that example is that it has implied a coupling between the code coming from the back-end and the code/ environment on the client while spreading the client-side code across multiple sources. This is not something that I have ever considered advisable, and is something that I have seen cause problems. specifically, if something needs to be changed (in the client-side code, say) it can either become difficult to change it because of the trouble/inconvenience/impossibility of changing the server-side code and/or database entries, or the attempt to make those changes across the multiple locations fails to update all the relevant code coming from the server, leaving odd errors popping up when those unaltered code fragments are sent from the client. Sending a chunk of code to be - eval-ed on the client is a very simple way for the server to issue an instruction to the client, but abstracting the issuing of instructions does not have to significantly more complex. In the case of your example, what you appear to have is a conditional instruction to set the value of a property named 'myNewItem' on an object identified as 'items' to a JSON-like (i.e. pure name/value pair data) object reference, but in addition to that the code sent has also mandated how that action will be carried out. View the thing sent form the server as an action to take and a set of parameters for that action and it should be easy to see how the same could be achieved with little or no coupling between the server-side and the client side. The instruction could be sent as JSON such as:- '{"action":"conditionalAssign","subject":"item","property":"myNewItem'","value": { "name":"a"}}' - and the client-side code can examine that to determine how it is going to set about carrying out the required action. In this way the details of how it acts are completely independent of the instructions to act issued by the server, and so can be freely modified (extended, etc.) without any need to even look at the code issuing the instructions. It is, of course, possible to send sequences of such instructions (say as arrays of such data) to achieve more complex outcomes on the client. Richard. |