(Just a quick note to say that if I read your tone correctly, you seem to be offense to my comments. I just want to say that although I disagree here, I've seen many of your posts in cljs and hold a good deal of respect for you. I just seem to use JS in a very different way than you do.)
Michael Haufe (TNO) wrote: > Scott Sauyet wrote: >> [ ... ] When I program in Javascript, I don't usually >> think in terms of classes of objects, but in one-off objects that may >> or may not have certain properties. One of the great things about the >> language is the ability to add and remove arbitrary properties of >> objects. > > And if you want scalable code you'll change what terms you consider > again. The "great things" about the language are also terrible things > when dealing with scale, hence the large number of meta-object > features introduced in ES5. I'm not sure what you consider scale. My current project involves ~65 JS files with just over 20K lines of JS code. It's a single-page web application, AJAX-heavy, with JS required to use it. (Not my choice!) The main data configuration used per client is between 20KB and 300KB, with an object count in the thousands or tens of thousands, or in rare cases in the low hundreds of thousands, never in the millions. The user base will be moderate, measuring in the tens of thousands, but not hundreds of thousands or millions, and probably not more than a few hundred simultaneous users. What sort of scale do you think is required to make your suggestion necessary? We do an awful lot with configuration object parameters to our functions, merging them with default values where appropriate. But there are many cases when we simply branch on the existence of certain properties in objects supplied. We haven't run into any issues except for slightly less readable code than we might have if we had the sort of static contract you discuss. We have not introduced any general nested property access of the sort suggested by Peter van der Zee, but we do have the equivalent for the main data configuration object, which is simply a JSON-ified version of an industry-standard XML format in which many elements at various levels are optional. It works as you might expect, a get of "path.to.property" returns null if any of the nodes are missing. A set for the same path creates empty objects for any of the missing nodes. We could of course create a data model of constructor functions for every level of the data model, and hook them together in an appropriate way. But in the last six months, we've already done three updates to the structure of the data model to later versions of the industry standard. This involved no changes to our core data-access mechanism. Had we tried to work with such a data model, it would have been substantially more work, and I can't see that it would have gained us anything. The ES5 meta-object features make OO-style programming easier, but they don't take away from the purely functional mechanisms that are also available, and which we are using to a great extent on this project. >> [U]nless you're quite certain that no code has done the equivalent of > >> delete person2.address, > >> you still need something like that to ensure your code won't fail >> horribly. > > Object.seal(...) If you're fortunate enough to be working in an ES5 environment, or you code these features yourself, and if no one is passing you an unsealed clone of your object, and no one has set the `address` property to a non-object value, then maybe you can count on this working. But there are probably other cases too where it still won't work. >> The point is simply that JS is a class-free language. You can >> simulate classes to some degree, but it's never an exact match with >> what's available in class-based languages. > > I don't recall saying anything about classes nor their simulation nor > any feature that is necessarily shared with them. You seem to be > trying to present a Straw man. Not intentionally, I assure you. So what is the point of introducing the Person and Address constructor functions in your earlier message if not to use them as the equivalent of class constructors? I thought the whole point was the contract that every person would have an address which would have a zip code. If that is the point, then how does that differ from OO-style classes? -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
