Brendan Eich wrote:
Herby Vojčík wrote:
The code above is till too imperative - it is really carrying out the
if statement and the doing whatever one pleases inside (so one must
scan if it really is only result.{...}), and has one level of nesting
more.
The form you showed was every bit as imperative. I don't like punning
I still see big difference there, I don't see it as imperative, just as
a conditional data.
'if' statements into object literals as a special form.Why not switch
statements? Why not loops with computed property names?
No loops, exactly because they are imperative. Loops do not have their
place in object literal. But conditionals? What's wrong on part of a
literal being only included when condition is met?
Restricting the consequent or loop body to be more declarative does not
remove the ability to do a great many imperative things in the initial
value expressions.
Loops aside (I did not want them), what is expression in property
initialization value part (foo: expr) different from one inside if? I
have already though of "if contains expression", but since every
property: value pair has it as well.
We have imperative forms (statements). We have object literals. Keeping
them from blurring together is better for readability in my opinion. Add
I am on the other side here... giving data production more expressional
power, not only define strict structure and every other thing must be
done be manipulating with code; but also define something a little more.
Object literal is shortcut for 'var x = {}; x.foo = 4; x.name =
"example";' code. Not a nice code. Why allow shortcut for this
(essentially description, but done with code because there is no
powerful data-production; in case there wasn't an object literal), but
not for one containing ifs (which is also, essentially, description,
just with conditional parts)?
to this the relative rarity of needing such an if. Then add the ability
to use .{ or whatever it'll be called.
Yes, it can be done that way. I am in fact big fan of .{ . But I think
object literal should be powerful on its own (making .{ even more
useful, by the way).
/be
Herby
P.S.: My reasons are not very pragmatic, that's why it's hard to sell
them. But my look at this is (for a long time, I do this every time I
program if possible): a structure of code should match with a structure
of human thoughts, if possible. If something is so complex I would
rather describe a process to get it rather than its structure,
(imperative) code should be used to build it. But when I would describe
it a structure "having this and this element; then this containing this
and that; and if foo>60 then also this and this", then object literal
should be used.
Mapping if (cond) {then-part} [else {else-part}] seems just natural
choice since it is familiar.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss