Live data from Hacker News

Learn Dart in 15 Minutes

learnxinyminutes.com

1–10 of 42 posts

Re: Learn Dart in 15 Minutes

#3
One of the examples reminded me of some xml/html trivia I picked up a few years back -- attributes do not need to have double-quotes. (Yes, in practice you can leave out quotes altogether if the attribute has no spaces because browsers are tolerant, but the spec allows for single or double quotes, so if you're going to parse markup you need to allow for both.)

It occurred to me that HTML5 might have tightened up this rule, but it remains as before:

http://www.w3.org/TR/html-markup/syntax.html#attribute

Re: Learn Dart in 15 Minutes

#5
post #3

One of the examples reminded me of some xml/html trivia I picked up a few years back -- attributes do not need to have double-quotes. (Yes, in practice you can leave out quotes altogether if the attribute has no spaces because browsers are tolerant, but the spec allows for single or double quotes, so if you're going to parse markup you need to allow for both.) It occurred to me that HTML5 might have tightened up this…

Note that XML attribute values do need to be quoted, so this is only true for HTML and not XHTML.

Re: Learn Dart in 15 Minutes

#6
This seems rather odd from example 14:

    // Boolean expressions need to resolve to either true or false, as no
    // implicit conversions are supported.

I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

Re: Learn Dart in 15 Minutes

#7
post #6

This seems rather odd from example 14: // Boolean expressions need to resolve to either true or false, as no // implicit conversions are supported. I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

Implicit coercion is often a source of bugs. Some languages simply mandate that you be explicit about your intent. It can be slightly more verbose, but you gain clarity and reduce ambiguity.

With implicit coercion, the programmer must mentally keep track of how values get coerced (are negative numbers truthy? are empty strings? empty lists? empty objects?). Different languages have different answers for all of these things. As a result, I prefer to always be explicit.

If you've never seen the WAT?[1] talk, I suggest watching it. It has some great examples of type coercion gone wrong in Ruby and JS.

[1] https://www.destroyallsoftware.com/talks/wat

Re: Learn Dart in 15 Minutes

#8
post #6

This seems rather odd from example 14: // Boolean expressions need to resolve to either true or false, as no // implicit conversions are supported. I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

> I think I'd miss patterns like `if (arr.length) { ... }`

At least for this particular example, dart supports an 'isNotEmpty' property on all iterables[0], so it'd just be this:

    if (arr.isNotEmpty) { ... }
The core libraries support a lot of useful properties like that.

[0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...

Re: Learn Dart in 15 Minutes

#9
post #6

This seems rather odd from example 14: // Boolean expressions need to resolve to either true or false, as no // implicit conversions are supported. I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

I think this is wrong or at least misleading. According to the Ecma standard:

  Boolean conversion maps any object o into a boolean. Boolean conversion is defined by the function application
  (bool v){
    assert(v != null);
    return identical(v, true);
  }(o)

Re: Learn Dart in 15 Minutes

#10
post #6

This seems rather odd from example 14: // Boolean expressions need to resolve to either true or false, as no // implicit conversions are supported. I'm sure they have good reason for this, does anyone know of the rationale? I think I'd miss patterns like `if (arr.length) { ... }`

> I think I'd miss patterns like `if (arr.length) { ... }` At least for this particular example, dart supports an 'isNotEmpty' property on all iterables[0], so it'd just be this: if (arr.isNotEmpty) { ... } The core libraries support a lot of useful properties like that. [0] https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...

It's actually important to prefer .isNotEmpty over .length here. In some iterables (think generators, or sequences transformed by higher-order functions), calculating the length requires traversing the entire sequence where .isNotEmpty can stop after finding a single item.
Post reply on HN