Ubiquitous conditionals
The monocle shines here... (comments inline)
On Mon, Jan 23, 2012 at 1:43 PM, Herby Vojčík <herby at mailbox.sk> wrote:
Hello,
not very often, but also not very rare, is there the case of this kind of code:
var result = { model: model, seats: seats }; if (space) { result.truck = true; result.space = space; }
var result = { model: model, seats: seats };
if ( space ) { result.{ truck: true, space: space } }
Rick Waldron wrote:
The monocle shines here... (comments inline)
?
On Mon, Jan 23, 2012 at 1:43 PM, Herby Vojčík <herby at mailbox.sk <mailto:herby at mailbox.sk>> wrote:
Hello, not very often, but also not very rare, is there the case of this kind of code: var result = { model: model, seats: seats }; if (space) { result.truck = true; result.space = space; }var result = { model: model, seats: seats }; if ( space ) { result.{ truck: true, space: space } }
Yes, but it is just a little more dataized version of the code before. The intent of the programmer is not to create a constant-structure harness and then (however elegantly) patch it afterwards, it is to create one data structure with some parts conditional.
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.
If the form below, you cannot do whatever you please inside then-body or else-body - just put there the nested data-production.
Object literal extension (and get/set before them) have shown that blocks can be used in object literal. I propose to have possibility to write var result = { model: model, seats: seats, if (space) { truck: true, space: space } }; in object literal, and similar possibility of conditional definition in the body of a class. Herby
Herby
P.S.: And, well, this is not the only thing I have in mind, but if I post whatever longer, I got tl;dr-ed. I drew more inspiration from code structures that can be useful by porting to data side, having the same semantics, but descriptive instead of imperative nature. But I must go one by one.
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 'if' statements into object literals as a special form.Why not switch statements? Why not loops with computed property names?
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.
We have imperative forms (statements). We have object literals. Keeping them from blurring together is better for readability in my opinion. Add to this the relative rarity of needing such an if. Then add the ability to use .{ or whatever it'll be called.
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.
Herby Vojčík wrote:
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. ... they are not a problem; they are on the same level.
(somehow end of expression have slipped)
On Wed, Jan 25, 2012 at 10:28 PM, Brendan Eich <brendan at mozilla.org> wrote:
The form you showed was every bit as imperative. I don't like punning 'if' statements into object literals as a special form.Why not switch statements? Why not loops with computed property names?
Switch statements could work, loop probably not. You can, usually meaningfully, make a syntactic category conditionally processed. For statements there is "if", for expressions "?:". This suggestion is about conditionally processed declarations. ECMAScript don't usually make a big deal about declarations as being different from statements (which is probably why people started doing function statements). An object literal is the only scope where only declarations are valid, so it makes sense that that is where a wish for conditional declarations appear.
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.
We have imperative forms (statements). We have object literals. Keeping them from blurring together is better for readability in my opinion.
ACK. readability would suffer with the suggested syntax.
Add to this the relative rarity of needing such an if. Then add the ability to use .{ or whatever it'll be called.
The .{ and <| operators are trying to make complex imperative initialization sequences into (shorter) expressions. We are doing the computation in order to create a single value, and we don't really care about the way it's done, so it seems like a prime target for becoming an expression, taking the imperatives out of what is really a value operation. If you repeat a sequence of statements often enough, it'll be abstracted into either a function or, in this case, an operator. The argument here seems to be that the need for conditionally declaring properties of an object literal isn't happening often enough that it warrants an abstraction. (And that seems reasonable from what I've seen too).
Lasse Reichstein wrote:
The argument here seems to be that the need for conditionally declaring properties of an object literal isn't happening often enough that it warrants an abstraction. (And that seems reasonable from what I've seen too).
The problem with this the process of discussion. This if-in-literal is not an isolated proposal. It is part of a bigger thing: blog.herby.sk/blosxom/Programming/ES-next/empowered-data.html
The issue with bigger things is, they only get one type of response: tl;dr (and I confess I do it myself :-( ).
If one tries to go in small steps and tries to get things in feature-by-feature, he get a response of "who needs it?" (how many times did I hear it). Yes, isolated, the feature seem of little use, but as a part of a whole, its need is much more apparent. The only problem is, "the whole" is tl;dr.
It seems there is no way to present something more complex. How to present something bigger so it gets actually considered?
Hello,
not very often, but also not very rare, is there the case of this kind of code:
var result = { model: model, seats: seats }; if (space) { result.truck = true; result.space = space; }
Object literal extension (and get/set before them) have shown that blocks can be used in object literal.
I propose to have possibility to write
};
in object literal, and similar possibility of conditional definition in the body of a class.
Hello, not very often, but also not very rare, is there the case of this kind of code: var result = { model: model, seats: seats }; if (space) { result.truck = true; result.space = space; } Object literal extension (and get/set before them) have shown that blocks can be used in object literal. I propose to have possibility to write var result = { model: model, seats: seats, if (space) { truck: true, space: space } }; in object literal, and similar possibility of conditional definition in the body of a class. Herby