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]
