"child" and "children" add a lot of value

[Hixie]

There's an assertion in https://github.com/munificent/ui-as-code/blob/master/in-progress/parameter-freedom.md that the "child" and "children" named arguments should become unnamed because they don't add value.

There is nothing special about "child" or "children"; not all widgets use those names, e.g. MaterialApp (the first widget people come across) uses "home", while Scaffold and AppBar (the next two predefined widgets they come across) use "body" and "appbar" and "leading" and "title" and so on.

Having the clear distinction of "child" and "children", and of other common names like "builder", is important to convey how many children a widget takes, what role the child has, how it should be expressed (e.g. static widget vs closure), and to make a clear link from the parameter in the constructor to the property on the widget. It also makes it much easier to reference the parameter in documentation.

In conclusion, I do not believe we would make that change even if the language made it easy to do so. We have in the past experimented with using unnamed arguments (e.g. for a while the child was always the first argument, unnamed), and we moved away from this very purposefully.

[munificent]

There is nothing special about "child" or "children"; not all widgets use those names, e.g. MaterialApp (the first widget people come across) uses "home", while Scaffold and AppBar (the next two predefined widgets they come across) use "body" and "appbar" and "leading" and "title" and so on.

Yeah, for other non-"child" and "children" names, I would expect them to stay named. But from what I've heard from other Flutter users and even team members, the names "child" and "children" in particular are not worth their weight in screen real estate. The syntactic nesting itself implies a certain parent-child relationship.

But, of course, ultimately it's up to you folks to design the APIs you think are best for your users based on the affordances the language provides.

(e.g. for a while the child was always the first argument, unnamed), and we moved away from this very purposefully.

Was the problem that it was unnamed, or that it was first? In Dart today, making a parameter positional also forces you to place it before the named arguments. You end up with code like:

Container(
  Row(
    children: [
      IconButton(
        icon: Icon(Icons.menu),
        tooltip: 'Navigation menu',
      ),
      Expanded(
        child: title,
      ),
      IconButton(
        icon: Icon(Icons.search),
        tooltip: 'Search',
      ),
    ],
  ),
  height: 56.0,
  padding: const EdgeInsets.symmetric(horizontal: 8.0),
  decoration: BoxDecoration(color: Colors.blue[500]),
);

That pushes height, padding, etc. very far away from the name of the widget they apply to.

This proposal allows you to have named arguments before positional ones specifically to solve that, so you could do:

Container(
  height: 56.0,
  padding: const EdgeInsets.symmetric(horizontal: 8.0),
  decoration: BoxDecoration(color: Colors.blue[500]),
  Row(
    children: [
      IconButton(
        icon: Icon(Icons.menu),
        tooltip: 'Navigation menu',
      ),
      Expanded(
        child: title,
      ),
      IconButton(
        icon: Icon(Icons.search),
        tooltip: 'Search',
      ),
    ],
  ),
);

[Hixie]

Certainly requiring it to be first didn't help, but I don't think it was the main issue. It's been a while though.

I agree that removing child and children is a common piece of feedback, and it makes sense to explore what that would enable. The reason I don't think we'd do that change overall is that while it seems to make sense in some common cases, it makes the overall design less coherent and predictable, and has downstream effects (such as those on the documentation) that are subtle and easily overlooked but nonetheless IMHO quite detrimental to the overall health and usability of the API.

[yjbanov]

There actually is something special about child and children, but it's not a technical feature, but how these arguments are used. Namely, they predominantly come as the last argument in the argument list. This likely means that in developers' minds child widgets are conceptually separate from "properties", so they put them last. This holds even in Flutter's own code.

However, I'm not arguing that rest args is the right solution for this problem. Rest args is a useful language feature, just not for ui-as-code. I think we should keep looking for a solution, one that's applicable beyond single-slot child models, and includes "home", "body", "leading" and so on, which are as special or as not special as child and children are.

[munificent]

This likely means that in developers' minds child widgets are conceptually separate from "properties", so they put them last.

Yes! One of the reasons I was interested in exploring a JSX-like syntax is because that notation gives you a very explicit visual distinction between attributes and children. Unfortunately, I was never able to come up with a syntax I liked that worked well with named single arguments (child, body, etc.), named collection arguments (children, actions, etc.), and positional arguments.

I also spent a lot of time exploring a block-based syntax but couldn't figure out a syntax that I felt covered enough of the bases to be worth the additional complexity and switching costs. In particular, a block based syntax that still requires you to two sets of brackets to specify a list of children seems unsatisfactory to me:

Row {
  children: [
    item,
    item
  ]
}

I noodled some on being able to hoist those out of the outer brackets:

Row() children [
  item,
  item
]

Syntactically, I think this might actually work. But I'm really worried it's just too weird. It's not totally unexplored territory. Grace supports something similar. It would take a lot of time to investigate this and see if something hangs together. There's a good chance it falls apart once you try to figure out how it interacts with things like method chains, subscript operators, etc.

[yjbanov]

a block based syntax that still requires you to two sets of brackets to specify a list of children seems unsatisfactory to me

I wonder if we are thinking about child widget properties backwards. These properties indicate "slots" inside a parent, but at the technical level we chose to use parameters to express them. So this parameter bias keeps following us into all of our proposals. Let's consider the Scaffold widget. It has multiple slots, but let's focus on body and persistentFooterButtons for a moment.

Currently you would use Scaffold like this:

Scaffold(
  body: Home(
    ...
  ),
  persistentFooterButtons: [
    FlatButton(
      ...
    ),
    RaisedButton(
      ...
    ),
  ],
);

While these slots are technically properties (passed as arguments), perhaps conceptually they are actually widgets, even though we do not have an explicit widget classes for them. This might sound weird, but in the HTML world (including Angular, JSX, etc) you might express this as:

<scaffold>
  <body>
    <home>...</home>
  </body>
  <persistentFooterButtons>
    <flat-button>...</flat-button>
    <raised-button>...</raised-button>
  </persistentFooterButtons>
</scaffold>

So if HTML elements are like Flutter widgets, then "body" and "persistentFooterButtons" elements are also "widgets". If we syntactically translate this back to the block proposal, what we get is this:

Scaffold {
  body {
    Home {
      ...
    }
  };

  persistentFooterButtons {
    FlatButton {
      ...
    };
    RaisedButton {
      ...
    };
  };
};

I admit, I have no idea how something like this can fit into the language. But I like how it looks! And the extra brackets are actually useful.

[Hixie]

amusingly, it was the result of exactly the opposite line of reasoning that led to where we are now. we started with html, then web components. in a world with aggressive composibility, there's really nothing special about a slot taking a particular type of widget, or a slot taking an arbitrary widget, or any other kind of argument. Flutter certainly commonly uses widgets, but there's no reason why you have to use them as your child of your widget... for example we sometimes use TextSpan objects as children. Indeed in Flutter Sprites you transition to an entirely different class hierarchy.

A lot of our design is drawn from trying to avoid the design limitations that we saw on the web as a result of the approach you describe above.

[yjbanov]

That's why I wrote "widgets", and not widgets :) They don't have to be instances of sub-classes of Widget. So TextSpan would qualify. I'm also not trying to argue that HTML as a whole is good UI language. It just happened to work for this particular case. HTML attaches a lot of undesired semantics to that syntax, in addition to the semantics that developers and framework authors want, and there's plenty that it can't do that developers want it to, leading to awkwardness (see Angular's "directives" and the numerous annotations for binding to HTML). There are plenty of non-HTML examples btw, such as Anko - a DSL for Android layouts for Kotlin, or QML that uses block syntax not just for building widget hierarchies, but also for state machines.

I think a language's job is not only to provide a sufficient number of nouns and verbs for developers to express logic, but also provide syntactic visual cues that can be used by libraries and frameworks to guide the developer when they read and try to understand code. For example, visual locality and isolation of related logic is very powerful for code understanding. That's why we have functions, closures and classes. Blocks simply extend that to anonymous non-reusable pieces of related logic (for example, initializing arguments, writing unit-tests), and they do that without any extra runtime cost. For example, they do not allocate objects.

However, we definitely need to make sure there is place in the framework where new syntax actually provides useful guidance. That's something I haven't fully wrapped my head around. Widgets created inside build methods are one obvious place. But that's not enough. It should be applicable in more places. Hence the idea above.

Perhaps the defining characteristic of what should use the special syntax is when something takes up space on the UI (think layout), something you can point at on the screen, give it a name and that name will coincide with a name used in the code. Think Padding, FlatButton, children, home, TextSpan, builder. I would also expect it to be something that has a lifespan. It's not just a paint operation, like drawRect, but either an object by itself (e.g. a widget), or owned by an object (e.g. a property of a widget). So the visual cue of the name { } brackets implies a UI building block, and sets it apart from name() and name = .

[munificent]

I did toy with a syntax similar to what you have here, and also played around with something like:

Scaffold {
  body: Home {
    ...
  }

  persistentFooterButtons:
  FlatButton {
    ...
  };
  RaisedButton {
    ...
  };
};

It got weird pretty fast and I couldn't come up with anything that I felt held together. With your syntax, what are the actual semantics you have in mind? It seems like you use a postfix block to mean two different things in different contexts. In some places, it's an argument block where the name is a constructor/function and in others the name is a named parameter and the block is the list of values for it.

Is that what you had in mind? How would the language reliably know which behavior you intend in any given context?

[yjbanov]

With your syntax, what are the actual semantics you have in mind?

For Scaffold { ... } it's the AIB as in the current proposal. For body { ... } and persistentFooterButtons { ... } the closest thing I can think of is initializer lists from C++. For example, the nlohmann JSON library uses them as DSL for expressing JSON:

// create an empty structure (null)
json j;

// add an object inside the object
j["answer"]["everything"] = 42;

// add an array that is stored as std::vector (using an initializer list)
j["list"] = { 1, 0, 2 };

// add another object (using an initializer list of pairs)
j["object"] = { {"currency", "USD"}, {"value", 42.99} };

// instead, you could also write (which looks very similar normal JSON)
json j2 = {
  {"pi", 3.141},
  {"happy", true},
  {"name", "Niels"},
  {"nothing", nullptr},
  {"answer", {
    {"everything", 42}
  }},
  {"list", {1, 0, 2}},
  {"object", {
    {"currency", "USD"},
    {"value", 42.99}
  }}
};

(source)

It seems like you use a postfix block to mean two different things in different contexts. In some places, it's an argument block where the name is a constructor/function and in others the name is a named parameter and the block is the list of values for it.

Right. We already use { } for all kinds of things: classes, maps, named parameters, methods, functions, switch statements, etc. This just continues the trend.

How would the language reliably know which behavior you intend in any given context?

Haven't thought about it that far yet :) Borrowing from C++ initializer lists, the type of the LHS "expression" could be used. The language knows that body is a parameter of type Widget which inside an AIB can only be assigned to, therefore body { ... } can be treated as assignment. persistentFooterButtons is the same, except its a List and so the language treats persistentFooterButtons as a "list initializing block". Obviously, we'll need to introduce this "list initializing block" in the first place. I'm guessing it will differ from the normal "block", as in, it's not a list of statements (otherwise we'll need something like yield, which is a no go). Perhaps a list of expressions is sufficient, if it can also be supported by the control flow proposal. Optional semi-colons and optional commas could help here so users do not have to think about the different kinds of punctuation.

[munificent]

Right. We already use { } for all kinds of things: classes, maps, named parameters, methods, functions, switch statements, etc. This just continues the trend.

That's true, but in those cases, we can syntactically distinguish what the use is.

Haven't thought about it that far yet :) Borrowing from C++ initializer lists, the type of the LHS "expression" could be used. The language knows that body is a parameter of type Widget which inside an AIB can only be assigned to, therefore body { ... } can be treated as assignment.

That raises my hackles.

Consider:

foo {
  bar {
    baz
  }
}

If bar is a function, then baz is parsed as an expression statement. But if
bar is a named parameter of foo, then baz is an implicitly yielded value
passed to bar.

This means we rely on type information to parse. That way leads to madness,
especially in Dart where identifies may be imported from other libraries.

Obviously, we'll need to introduce this "list initializing block" in the first place. I'm guessing it will differ from the normal "block", as in, it's not a list of statements (otherwise we'll need something like yield, which is a no go). Perhaps a list of expressions is sufficient, if it can also be supported by the control flow proposal.

Right, but my thinking is that if we have to do the control flow proposal anyway, we may as well use that for named arguments too:

Scaffold(
  if (blah) body:
    Home(
      ...
    )
  ),
  persistentFooterButtons: [
    FlatButton(
      ...
    ),
    if (blah) RaisedButton(
      ...
    )
  ]
};

The blocks don't really buy you much, at least not for Flutter's use case where you're just constructing an object.

Where blocks would buy you something is in other DSLs where you're doing imperative work, like:

sql.inTransaction {
  var record = sql.query(...);
  if (record.isSomething) {
    sql.delete(...)
    sql.insert(...)
  } else {
    sql.update(...)
  }

  sql.recalculateIndex();
}

So I'm inclined to leave that syntax available so that we can use it for something more along these lines.

I do like that you're pushing on this, and I admit cramming more stuff to into the existing parentheses-and-commas syntax isn't ideal. But doing an incremental refinement of that dramatically lowers the switching cost when users need a little conditional logic in an existing constructor call. I think it's overall a better fit for Flutter's need which is much more declarative (i.e. expression-based) than imperative (statement-based).

[leafpetersen]

I do like that you're pushing on this

+1

This is a very useful discussion.

I posted it before in another thread, but this is the more appropriate place.
The main idea (or conjecture, if you will) is that while scanning the line, our eye gives disproportionate attention to the first character. I would say, extremely disproportionate. Unfortunately, I don't know how to measure it exactly, but let's assume this is true, just for the sake of argument. What immediately follows is that while writing parameters/children in these literals, we need a good first character that triggers some neurons in the brain, so to speak.

Card {
  .color= Colors.white;
  +Center {
    +Column {
      .mainAxisSize = MainAxisSize.min;
      .crossAxisAlignment = CrossAxisAlignment.center;
      +Icon(choice.icon, size: 128.0, color: textStyle.color);
      +Text(choice.title, style: textStyle);
    }
  }
}

Of course, you can write any procedural logic in the initialization block, and with prefixes, it remains readable

Card {
  .color= Colors.white;
  +Center {
    +Column {
      .mainAxisSize = MainAxisSize.min;
      .crossAxisAlignment = CrossAxisAlignment.center;
      +Icon(choice.icon, size: 128.0, color: textStyle.color);
      for (int i=0; i<10; i++) {
        +Text("line${i}", style: textStyle);
      }
    }
  }
}

In my opinion, this format is just "good enough" for the eye. Whether dart can accommodate it naturally is another issue, but I think it's just a minimal addition to the proposals discussed above. Except "child". For "child", we also need plus, and I don't know how to formally justify it for a single-valued parameter.

EDIT 0: proposed block initialization syntax should be limited to constructors (as opposed to regular functions/methods), otherwise it may lead to confusion. E.g., the following should work, too

    //...
    Column {
      .mainAxisSize = MainAxisSize.min;
      .crossAxisAlignment = CrossAxisAlignment.center;
      +Icon(choice.icon, size: 128.0, color: textStyle.color);
      [1, 2, 3].forEach( (n) =>
        // we are still in the context of Column init block, not in the context of "forEach" method
        +Text("line${n}", style: textStyle); 
      );
    }

EDIT 1: for single-valued components like "child", we can simply choose another symbol - e.g. "*" instead of "+". What makes this syntax attractive is : not only the start of the element is easy to spot, but also - we have a clear vertical rhythm in the layout, by virtue of "+" (or "*") aligned vertically with the closing bracket of initialization block. I think this kind of vertical alignment is something that makes JSX so appealing to some users who otherwise hate XML with a passion, but the aesthetic value of vertical alignment is so strong, it makes it difficult to resist.

In attempt to find a scientific justification for my "first character effect" claim, I did some research on internet and found this post.

https://www.creativebloq.com/ux/how-human-eye-reads-website-111413463

The article claims that the first scan of the document is vertical: the eye is looking for the points of interest. I tried to conduct an experiment: opened several Flutter examples to see how I scan them. Indeed, I scan them vertically, and the points of interest (at least for me) are nested widgets. Attributes don't matter much at that point. At the first scan, my eye is focused only on the leftmost part of the code. But with the current way of presentation, the points of interest are hidden. There's too much noise in the code (esp. 'child' and 'children'), and nothing in particular really stands out. So the initial scan completely fails to identify the structure. If we are concerned about the ease of reading - then emphasizing the points of interest should be the first step IMO.

The trick with plus and asterisk helps with that. But leading dots in the names of attributes - I'm not sure about them. If the idea of "initialization block" gets any traction, these dots might be good for disambiguation (in case of name collisions with the local variables), but on the other hand, they might create too many "points of interest".

Is there anybody who likes the idea of asterisk and plus symbols? They are easy to explain:
\*X is simply a shortcut for child=X, and +X - shortcut for children.add(X). There;s nothing magic about the names child/children - it can be any attribute, appropriately annotated.

[yjbanov]

@tatumizer That is an intriguing idea. Certainly looking at your examples, despite my eyes untrained to such syntax, I can tell properties apart from child widgets. So I think the "first character" effect works. I bet if we add syntax highlighting it can be even clearer.

Having said that, it does not seem to solve the "child" vs "children" vs "home" vs "persistentFooterButtons" problem, i.e. it does not have child slots that many widgets have.