Question about constructor property vs. instanceof
in [JavaScript]
|
Prev: How to link CSS(s) already linked to parent frame into child iframe using javascript
Next: Error getElementbyClassName
From: Dmitry A. Soshnikov on 12 Jan 2010 06:48 On Jan 12, 3:42 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > The OP may not have been aware of what I posted. > I thought you was talking to me as replying on my message. ok /ds
From: wmc on 12 Jan 2010 07:48 Garrett Smith wrote: > > (You quoted my signature). > > The OP may not have been aware of what I posted. I saw Garrett's post, too, and as I said, when I get a little time I'm going to continue reading and writing some code to try get more comfortable with prototypal inheritance. If I can do that soon, I may come back with some questions on this thread for which any feedback would be welcome. Understood that the JS is incredibly dynamic compared to strongly typed languages like Java and C++ and as DS said there are no types. But, of course there *is* the need to produce similar type of objects from other objects and many patterns have been used, factory, constructor, parasitic inheritance, pseudo-classical and on and on. I need to get a better feel for all that. Although it's easy in the sense of possible to do something like clobber your own constructor property, do you find that that's a major problem in your own code, assuming you're the only programmer working on you app? I've never built anything large-scale in JS, so I have no insight into the issue. I think in the Crockford book he talks a lot about JS depending on the global scope for what he calls "linkage", so it does make sense that when projects get complex it could become a big problem.
From: Garrett Smith on 12 Jan 2010 11:36 wmc wrote: > Garrett Smith wrote: >> (You quoted my signature). >> >> The OP may not have been aware of what I posted. > > I saw Garrett's post, too, and as I said, when I get a little time I'm > going to continue reading and writing some code to try get more > comfortable with prototypal inheritance. If I can do that soon, I may > come back with some questions on this thread for which any feedback > would be welcome. > The diagram in the ECMA-262r3 s4.2.1 is actually good. > Understood that the JS is incredibly dynamic compared to strongly typed > languages like Java and C++ and as DS said there are no types. I do not believe he said that. I read:- | It's not correct regarding to ECMAScript to talk about the "type" with | such checks. In language with "duck typing" it's not so. Nether | constructor function, nor prototype object in ECMAScript's ideology | are "types". That's possibly to talk about Java - that's class of an | object - is it's type, but not in ECMAScript (though, pair | "constructor function + prototype object" can abstractly called as a | "class" - in quotes). That does not say there are "no types." ECMA-262 r3 (ES3) has five primitive types, Object, and three internal types Reference, List, and Completion. Reference is used in operators typeof and delete, and also in Function calls. List is used for arguments. The List type is specified to be "of any length", so that means you can have parameter lists of 1e99; in practice, implementations restrict that (Safari). Completion type is for break, throw, return, continue. There are also host objects, which may behave very differently in ES3. ES5 applies sensible, conservative restrictions host objects. There is also E4X (ECMA 357) which describes xml type. typeof <a></a>; "xml" But, of > course there *is* the need to produce similar type of objects from other > objects and many patterns have been used, factory, constructor, > parasitic inheritance, pseudo-classical and on and on. I need to get a > better feel for all that. > > Although it's easy in the sense of possible to do something like clobber > your own constructor property, do you find that that's a major problem > in your own code, assuming you're the only programmer working on you > app? I've never built anything large-scale in JS, so I have no insight > into the issue. > I don't fully understand the problem you are describing. Can you provide an example? > I think in the Crockford book he talks a lot about JS depending on the > global scope for what he calls "linkage", so it does make sense that > when projects get complex it could become a big problem. I don't know what that means, either. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: John G Harris on 12 Jan 2010 13:25 On Tue, 12 Jan 2010 at 07:48:14, in comp.lang.javascript, wmc wrote: <snip> >Although it's easy in the sense of possible to do something like clobber >your own constructor property, do you find that that's a major problem >in your own code, assuming you're the only programmer working on you >app? I've never built anything large-scale in JS, so I have no insight >into the issue. <snip> Remember that the 'constructor' property is entirely voluntary if you build the prototype object yourself instead of using the Function's default object. I don't see a good case for having that property anyway. An object surely knows how to do its own job. If it doesn't then something has gone wrong with OO. John [ Yes, Dmitry, the second paragraph is an opinion. ] -- John Harris
From: wmc on 12 Jan 2010 13:36
Garrett Smith wrote: > The diagram in the ECMA-262r3 s4.2.1 is actually good. > thx, I'll check that out... --williamc |