Ubiquitous conditionals

Herby Vojčík herby at mailbox.sk
Wed Jan 25 14:20:16 PST 2012

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


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.

More information about the es-discuss mailing list