Xavier MONTILLET wrote:
> Scott Sauyet 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.
If my object is a dumb data container with no behavior, then I
probably want direct access to its properties. Perhaps I don't care
if it's calculated, read-only, or normal. But perhaps I do. I
certainly don't want to have to wrap a try-catch around setting the
property on the off-chance it might be read-only. And I don't want to
have to do a for-in just to find out what features my object supports,
at least not when its design is something already in my control.
There are new language features creeping in that will allow us to do
C#-style setters and getters, but I've almost never had a need for
them in Javascript. The following is a great example, though, of
where it might be useful, and where your approach makes the most sense
to me:
> 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.
If we could count on the new syntax [1], I agree that being able to
get the area property directly as a property would be nice, but there
is an expectation mismatch, too. If we can do this:
var a = myRectangle.area;
we often expect to be able also to do
myRectangle.area = a;
That's pretty much how it works in JS. If on the other hand we had
var a = myRectange.getArea();
we don't automatically assume that we can also do
myRectangle.setArea(a);
Or at least I don't assume so.
But I simply can't see the advantage of turning this:
myRectangle.height = 3;
myRectangle.width = 5;
var area = myRectangle.getArea();
into this:
myRectancle.set("height", 3");
myRectancle.set("width", 3");
var area = myRectangle.get("area");
I can't even buy that the latter would be better than
myRectangle.setHeight(3);
myRectangle.setWidth (5);
var area = myRectangle.getArea();
Have you thought through how you might document your API? I love
tools like JSDoc, but can't see how to use anything like it with your
code. Do you have other ideas?
> [ ... [
> 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.
I'm not sure it's a matter of caring. It's a matter of what
facilities the language provides, and what glosses you are trying to
provide. You seem to be promoting something that to me makes it less
clear what's going on. I understand that you don't see it that way,
but having an object with only three properties, the functions `get`,
`set`, and `forIn` just confuses things for me.
> [ ... ]
>> 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.
When myRectangle has numeric properties `height` and `width` and a
function `getArea`, I have a pretty good idea how to use it. If
myRectangle exposes `get`, `set`, and `forIn`, which is the same API
exposed by mySpaceship and myHttpRequest, I'm really not certain how
to use any of them.
> 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.
I don't think it's that they don't care what it does, but that they
don't care how it does it. But speaking of jQuery, could you imagine
a version of it using your Accessors? What would it look like for a
jQuery wrapped object? How would the `.data()` function be
structured? How about `.addClass()` or `.attr()`? Or it's not a
candidate for using your tool, what would distinguish a good
candidate?
> 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/1dd7b8f2cbe14b68a807...
That's what I suspected. I'm curious about the environment you're
using this sort of code in? It reminds me a bit of the JavaBeans spec
-- great for tooling and other applications where the consumer knew
nothing about your API but just an additional burden for direct
consumers who are using your API semantically.
Thanks again. A very interesting conversation.
-- Scott
[1]
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Working_with_Objects#Defining_Getters_and_Setters
--
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]
