Having an object for Each property is a dead end. https://github.com/xavierm02/XJSAccessors/blob/OneObjectPerProperty/XJSAccessors.js It seems cool but in the end you get the value (that should be independant for each instance) and the getters / setters (that could be shared between several instances) in the same object. You still could copy all of the things that have to be shared but it would be much longer than just having am object with all the getters and so on. You could try having the object with only the value inherit from another that has the getters setters and so on but then, you would need to be able to call property.getter no matter what because detecting whether it has one or not would be a pain. But property.getter needs the value of the object you add accessors to so you would need a reference to the object, which is part of an instance so you wouldn't be able to do something general easily.
Anyway, I'll stick with the old thing. On Wed, Aug 31, 2011 at 2:58 PM, Xavier MONTILLET <[email protected]> wrote: >>I guess I have different priorities than you. I want my APIs to be as > simple and descriptive as possible > > Well I just don't understand your point of view... > If you want a property, you don't care "whether" it is calculated, > readonly or a normal property: you just need it. > > Then if you want an optimiwed code, you'll want to access the smallest > possible number of calculated properties but will you calculate the > area property from the height et the width properties? No, the area > property is here to do it for you... So if you need the area, you'll > use it. > > Then there is the fact that you want to store calculated properties in > local variables if used more than once and you wouldn't know which one > is calculated. Well you should put it in a local variable anyway since > this: > > var p = o.p; > console.log( p ); > console.log( p ); > > is faster than this: > > console.log( o.p ); > console.log( o.p ); > > I don't understand why you need to know if a variable is calculated... > if you put the result in a local variable if needed more than once, > you just shouldn't care. > > Same thing goes for setters. You don't want to know what the script > does with your value. You just want to avoid getting an error. > (Therefore, I allow to check if a property is protected > https://github.com/xavierm02/XJSAccessors/commit/d8c333b35abda40be33a76eadb58c4a721153b78 > ) > >>What advantages do you see to an API which exposes only `get`, `set`, > and `forIn`? > > You can't mess the thing and you don't need to know how it works to > use this. On the contrary of an API which expose both o.prop and > o.getProp2() which neds you to know which property is calculated / > readOnly and which is not. > And many people seem to really don't care about what the object does > as long as the API is simple since jQuery is widely used. > > ------------------------------------------------------------------------------- > > About tu forIn, I wasn't doing it on the right object >_< > Now it does work on properties with values but not on other properties. > https://github.com/xavierm02/XJSAccessors/commit/1dd7b8f2cbe14b68a8073f2453e120c78107cc64 > > I'll probably rework the storage so that each property has an object > and this way, I will just have to iterate through a list of those > objects. > Plus it should shorten the lookup time. We'll see. > > > > > On Wed, Aug 31, 2011 at 2:01 PM, Scott Sauyet <[email protected]> wrote: >> Xavier MONTILLET wrote: >> >>> And this is the whole point of those getters and setters: Some >>> properties need to be calculated, others don't. >>> When you use an object, do you want to have to remember which one is >>> calculates and which one isn't? Certainly not (because you're a good >>> guy and you cache it in a local variable anyway). >>> You don't want to remember is it is selection.rangeCount or >>> selection.getRangeCount(). You just have a simple syntax, the same for >>> all properties, calculated of "static": selection.get( 'rangeCount' ). >> >> I guess I have different priorities than you. I want my APIs to be as >> simple and descriptive as possible. If I have a mutable property, I >> probably just expose it as a property: >> >> myObj.prop1; >> >> If it's accessible but not mutable, I'll expose it as >> >> myObj.getProp1(); >> >> If it's not a simple property, but the result of some dynamic >> calculation, I'll expose it as something like >> >> myObj.calcProp1(); >> >> I find this much more readable, and incidentally, easier to document >> than >> >> myObj.get('prop1'); >> >> where I can't even tell on quick inspection what values for the `get` >> parameter can be reasonably supplied. >> >> What advantages do you see to an API which exposes only `get`, `set`, >> and `forIn`? >> >> >>> You'll tell me there is the solution of keeping only >>> selection.getRangeCount( ) but then, you can't use for in... >> >> The `forIn` I saw in your code [1] only seems to report the names >> `get`, `set`, and `forIn`, which certainly doesn't seem helpful. (I >> haven't looked at the latest versions though.) Is this not how you >> intend it to be used?: >> >> var x = new XJSSelection(); >> console.log(x.get('selection')); >> >> x.forIn(function(val, name, obj) { >> console.log(val, name, obj); >> }); >> >>> ...and if you ever need a dynamic name selection[ name ], >>> you'll have to handle putting it uppercase... >> >> I suppose that if this worked the way I think you mean it to, there >> would be some point in having, say, a `Rectangle` class that had among >> its iterable properties not only `height` and `width` but also `area` >> and `perimeter`, even though those are always calculated values. I >> haven't really found the need for those, but if I did, I think I would >> write a separate Introspector object that would report the properties >> of an input object, rather than introducing it into the design of my >> constructor functions. >> >>> Thanks for you interest btw :) >> >> I'm curious about this. But as I've said, I haven't yet seen anything >> that makes me want to use this in my own projects. Keep trying >> though. I am intrigued. >> >> -- Scott >> >> [1] Fixed a misspelling of "arguments" at >> http://scott.sauyet.com/Javascript/Test/2011-08-31a/ >> >> -- >> 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] >> > -- 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]
