Характерные особенности языка Dart

Original author: Bob Nystrom
  • Translation
  • Tutorial
Dart был разработан так, чтобы выглядеть знакомо для программистов на таких языках, как Java и JavaScript. Если постараться, можно писать на Dart практически так же, как на одном из них. Если очень постараться — можно даже превратить его в Фортран, но при этом вы упустите множество неповторимых и классных особенностей Dart.

Эта статья поможет вам научиться писать код в стиле Dart. Так как язык всё ещё активно развивается, многие идиомы тоже могут измениться в будущем. В некоторых местах мы пока сами не определились, что является наилучшей практикой (может быть вы нам поможете?) Тем не менее, вот несколько моментов, на которые стоит обратить внимание, чтобы переключить свои мозги из режима Java или JavaScript в режим Dart.

Конструкторы


Мы начнем эту статью так же, как начинают свою жизнь объекты — с конструкторов. Каждому объекту предстоит быть созданным в конструкторе, и его определение — важный момент в создании качественного класса. У Dart есть несколько интересных особенностей.

Автоматическая инициализация полей

Для начала избавимся от занудных повторений. Конструкторы часто берут аргументы и просто присваивают их значения полям класса:

class Point {
  num x, y;
  Point(num x, num y) {
    this.x = x;
    this.y = y;
  }
}

Нам пришлось набрать x четыре раза просто чтобы инициализировать поле. Полный отстой! Лучше сделать так:

class Point {
  num x, y;
  Point(this.x, this.y);
}

Если в списке аргументов конструктора перед именем аргумента идет this., поле с этим именем будет автоматически инициализировано значением аргумента. В нашем примере использована ещё одна маленькая хитрость — если тело конструктора пустое, можно использовать ; вместо {}.

Именованные конструкторы

Как большинство динамических языков, Dart не поддерживает перегрузку. В случае методов это не так страшно, потому что мы просто можем придумать другое имя. Конструкторам повезло меньше. Чтобы облегчить их участь, Dart позволяет использовать именованные конструкторы:

class Point {
  num x, y;
  Point(this.x, this.y);
  Point.zero() : x = 0, y = 0;
  Point.polar(num theta, num radius) {
    x = Math.cos(theta) * radius;
    y = Math.sin(theta) * radius;
  }
}

У класса Point есть три конструктора — обычный и два именованных. Вот как их можно использовать:

var a = new Point(1, 2);
var b = new Point.zero();
var c = new Point.polar(Math.PI, 4.0);

Обратите внимание, что мы используем new с именованными конструкторами, это не обычные статические методы.

Фабричные конструкторы

Иногда бывает полезно использовать шаблон проектирования “фабрика”. Например, вам нужно создать экземпляр класса, но необходима некоторая гибкость, просто захардкодить вызов конструктора определенного типа недостаточно. Возможно вы хотите вернуть кешированный экземпляр, если таковой имеется, или объект другого типа.

Dart позволяет сделать это, не изменяя код в месте создания объекта. Вы можете создать фабричный конструктор, который вызывается так же, как и обычный. Например:

class Symbol {
  final String name;
  static Map<String, Symbol> _cache;

  factory Symbol(String name) {
    if (_cache == null) {
      _cache = {};
    }

    if (_cache.containsKey(name)) {
      return _cache[name];
    } else {
      final symbol = new Symbol._internal(name);
      _cache[name] = symbol;
      return symbol;
    }
  }

  Symbol._internal(this.name);
}

Мы определили класс Symbol. Символ — это примерно то же, что и строка, но мы хотим гарантировать, что в любой момент времени существует только один символ с данным именем. Это дает возможность безопасно проверять символы на равенство, просто убедившись, что они указывают на один и тот же объект.

Перед определением конструктора по-умолчанию (безымянного) стоит ключевое слово factory. Когда он вызывается, новый объект не создается (внутри фабричного конструктора отсутствует this). Вместо этого нам надо явно создать и возвратить объект. В этом примере мы сначала проверяем, есть ли символ с таким же именем в кеше, и возвращаем его, если есть.

Клёво, что всё это прозрачно для вызывающего кода:

var a = new Symbol('something');
var b = new Symbol('something');

Второй вызов на самом деле не создаст новый символ, а вернет уже имеющийся. Это удобно, так как если сначала нам не был нужен фабричный конструктор, а потом оказалось, что таки был, нам не придется где-то в коде менять new на вызов статического фабричного метода.

Функции


Как в большинстве современных языков, функции Dart — объекты первого класса, с замыканиями и облегченным вариантом синтаксиса. Любая функция — это объект, и вы можете без стеснения делать с ней что угодно. Мы широко используем функции для обработчиков событий.

В Dart есть три способа создания функций. Первый — именованные функции:

void sayGreeting(String salutation, String name) {
  final greeting = '$salutation $name';
  print(greeting);
}

Это выглядит, как обычное объявление функции в C или метода в Java или JavaScript. В отличие от C и C++, объявления функций могут быть вложенными. Второй способ — анонимные функции:

window.on.click.add((event) {
  print('You clicked the window.');
})

В этом примере мы передаем анонимную функцию методу add() в качестве обработчика события. Наконец, для маленьких функций, состоящих из единственного выражения, существует облегченный синтаксис:

var items = [1, 2, 3, 4, 5];
var odd = items.filter((i) => i % 2 == 1);
print(odd); // [1, 3, 5]

Аргумент в скобках, за которым идет стрелка (=>) и выражение, создают функцию, которая принимает этот аргумент и возвращает результат вычисления выражения.

На практике мы предпочитаем использовать стрелочную нотацию везде, где это возможно, из-за её лаконичности (не в ущерб выразительности). Мы часто используем анонимные функции для обработчиков событий и коллбэков. Именованные функции используются довольно редко.

В Dart есть ещё один фокус (это одна из моих любимых фишек языка) — вы можете использовать => для определения членов класса. Конечно, можно делать это так:

class Rectangle {
  num width, height;

  bool contains(num x, num y) {
    return (x < width) && (y < height);
  }

  num area() {
    return width * height;
  }
}

Но зачем, если можно так:

class Rectangle {
  num width, height;
  bool contains(num x, num y) => (x < width) && (y < height);
  num area() => width * height;
}

Мы находим стрелочную нотацию великолепной для определения простых геттеров/сеттеров и других однострочных функций.

Поля, геттеры и сеттеры


Для работы со свойствами Dart использует стандартный синтаксис вида object.someProperty. В Dart вы можете определить методы, которые будут выглядеть, как обращение к полю класса, но при этом выполнять произвольный код. Так же, как и в других языках, такие методы называются геттерами и сеттерами:

class Rectangle {
  num left, top, width, height;

  num get right()           => left + width;
      set right(num value)  => left = value - width;
  num get bottom()          => top + height;
      set bottom(num value) => top = value - height;

  Rectangle(this.left, this.top, this.width, this.height);
}


У нас есть класс Rectangle с четырьмя «настоящими» свойствами — left, top, width, и height и двумя логическими свойствами в виде геттеров и сеттеров — right и bottom. При использовании класса нет никакой видимой разницы между натуральными полями и геттерами и сеттерами:

var rect = new Rectangle(3, 4, 20, 15);
print(rect.left);
print(rect.bottom);
rect.top = 6;
rect.right = 12;

Стирание границы между полями и геттерами/сеттерами — одно из фундаментальных свойств языка. Лучше всего думать о полях именно как о наборе “магических” геттеров и сеттеров. Из этого следует, что вы вполне можете переопределить унаследованный геттер натуральным полем и наоборот. Если в интерфейсе требуется геттер, в реализации вы можете просто задать поле с таким же именем и типом. Если поле изменяемое (не final), можно написать требуемый интерфейсом сеттер.

На практике это означает, что нет никакой необходимости тщательно изолировать поля класса кучей геттеров и сеттеров, как в Java или C#. Смело объявляйте публичные свойства. Если вы хотите предотвратить их модификацию, используёте ключевое слово final.

Позже, если появится необходимость делать валидацию или что-то ещё в этом роде, вы всегда сможете заменить это поле геттером и сеттером. Например, мы хотим, чтобы наш класс Rectangle всегда имел неотрицательный размер:

class Rectangle {
  num left, top;
  num _width, _height;

  num get width() => _width;
  set width(num value) {
    if (value < 0) throw 'Width cannot be negative.';
    _width = value;
  }

  num get height() => _height;
  set height(num value) {
    if (value < 0) throw 'Height cannot be negative.';
    _height = value;
  }

  num get right()           => left + width;
      set right(num value)  => left = value - width;
  num get bottom()          => top + height;
      set bottom(num value) => top = value - height;

  Rectangle(this.left, this.top, this._width, this._height);
}

Мы добавили в класс валидацию без необходимости менять код в любом другом месте.

Определения верхнего уровня


Dart — чистый объектно-ориентированный язык. Всё, что можно поместить в переменную, является объектом (никаких изменяемых “примитивов”), а каждый объект — экземпляр какого-либо класса. Тем не менее, это не “догматическое” ООП — не обязательно помещать всё внутрь классов. Вместо этого вы можете определять переменные, функции и даже геттеры и сеттеры на верхнем уровне.

num abs(num value) => value < 0 ? -value : value;

final TWO_PI = Math.PI * 2.0;

int get today() {
  final date = new DateTime.now();
  return date.day;
}

Даже в языках, которые не требуют помещать всё внурь классов или объектов, вроде JavaScript, принято делать так чтобы избежать конфликтов имен: глобальные определения в разных местах могут вступать в коллизии. Чтобы справиться с этим, в Dart есть система библиотек, которая позволяет импортировать определения из других файлов, добавляя к ним префиксы, чтобы избежать неоднозначности. Так что нет необходимости прятать определения внутрь классов.

Мы всё ещё исследуем, как эта особенность может повлиять на способ написания библиотек. Большая часть нашего кода помещает определения внутрь классов, например Math. Трудно сказать что это — укоренившаяся привычка из других языков, или полезная и для Dart практика программирования. В этой области нам очень нужна обратная связь от других разработчиков.

У нас есть несколько примеров использования определений верхнего уровня. Прежде всего — это main(). При работе с DOM, “переменные” document и window — это геттеры, определенные на верхнем уровне.

Строки и интерполяция


В Dart есть несколько видов строковых литералов. Вы можете использовать двойные и одинарные кавычки, а также тройные кавычки для многострочных литералов:

'I am a "string"'
"I'm one too"

'''I'm
on multiple lines
'''

"""
As
am
I
"""

Чтобы объединить несколько строк в одну, вы можете использовать конкатенацию:

var name = 'Fred';
var salutation = 'Hi';
var greeting = salutation + ', ' + name;

Но интерполяция будет чище и быстрее:

var name = 'Fred';
var salutation = 'Hi';
var greeting = '$salutation, $name';

На место знака доллара ($), после которого идет имя переменной, будет подставлено значение переменной (если это не строка, будет вызван метод toString()). Внутрь фигурных скобок можно помещать выражения:

var r = 2;
print('The area of a circle with radius $r is ${Math.PI * r * r}');

Операторы


Dart использует те же операторы, с теми же приоритетами, что и C, Java и другие подобные языки. Они будут вести себя так, как вы ожидаете. Тем не менее, внутренняя реализация имеет свои особенности. В Dart выражение с оператором вида 1 + 2 — просто синтаксический сахар для вызова метода. С точки зрения языка этот пример выглядит, как 1.+(2).

Это значит, что вы можете перегружать большинство операторов, создавая свои типы. Вот например, класс Vector:

class Vector {
  num x, y;
  Vector(this.x, this.y);
  operator +(Vector other) => new Vector(x + other.x, y + other.y);
}


Теперь мы можем складывать векторы, используя привычный синтаксис:

var position = new Vector(3, 4);
var velocity = new Vector(1, 2);
var newPosition = position + velocity;


Тем не менее, не стоит этой возможностью злоупотреблять. Мы даём вам ключи от машины в надежде, что вы не будете таранить столбы.

На практике, если типы, которые вы определяете, используют операторы в реальном мире, это хороший признак того, что стоит переопределять для них стандартные операторы: комплексные числа, векторы, матрицы и т.д. Во всех остальных случаях перегружать операторы, скорее всего, не стоит. Типы с перегружаемыми операторами обычно должны быть неизменяемыми.

Стоит отметить, что, так как операторы — это вызовы методов, им изначально присуща асимметрия. Поиск метода всегда делается для левого аргумента. Так что, когда вы пишете a + b, смысл операции зависит от типа a.

Равенство


Этому набору операторов стоит уделить особое внимание. В Dart есть две пары операторов равенства: == и != и === и !==. Выглядит знакомо для программистов JavaScript, но здесь они работают немного по-другому.

== и != служат для проверки на эквивалентность. 99% времени вы будете использовать именно их. В отличие от JavaScript, они не делают никаких неявных преобразований, так что они будут вести себя более предсказуемо. Не бойтесь использовать их! В отличие от Java, они работают с любыми типами, для которых определено отношение эквивалентности. Никаких больше someString.equals("something").

Вы можете перегружать == для своих типов, если это будет иметь смысл. При этом нет необходимости перегружать !=, Dart автоматически выведет его из ==.

Вторая пара операторов, === и !==, служит для проверки на идентичность. a === b вернет true только если a и b — один и тот же объект в памяти. Вам редко придется использовать их на практике. По-умолчанию, == полагается на ===, если для типа не определено отношение эквивалентности, так что === будет необходим в единственном случае — чтобы обойти переопределенный пользователем ==.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 99

    +5
    Scala, только от Google…
      0
      Пока не прочел про синтаксис думал, что это CoffeeScript от Google.
        +16
        не надо унижать scala
          0
          Это был укол в сторону Dart, a не Scala. Я сам пишу на Scala, это к тому, что они сделали велосипед, снова…
        +9
        Зачем все пытаются переизобрести велосипед? Почему никто не пробует создать БелАЗ или автобус? Почему бы не заложить в язык паттерны? Например, объявляешь синглетон: singleton class MyClass и все. Или удобные механизмы задания архитектуры проекта: уровни/слои и зависимости между ними. Я вот хочу указать, что проект состоит из трех слоев ABC и из С использовать A напрямую нельзя. Как мне это сделать в любом современном языке?
        Как на уровне языка отделить презентацию от модели? Я хочу объявить «слой модели» и запретить использовать в нем классы из UI. У меня вот проект состоит из трех сборок, в каждой из которых по 2-3 слоя, суммарно 8. Жду появления языка для больших проектов.
          0
          в скала можно описать объект те сингельтон.
          Но вот дальше — ждемс очередного витка.
            +3
            «Почему бы не заложить в язык паттерны?»
            Ну вот вам только что заложили в язык паттерн Factory (от которого, как мы понимаем, до синглтона совсем недалеко).

            «У меня вот проект состоит из трех сборок, в каждой из которых по 2-3 слоя, суммарно 8.»
            Специально для вас в VS (Ultimate) есть архитектурная валидация. Строго для вашего случая.
              +5
              это называется сферический конь в вакууме
              singleton это решается на уровне annotation или traits (если 1-2 словами нужно), а то что вы предлагаете заложить в язык кучу keywords причем в динамический, это вообще бред
              возьмите scala к примеру и на уровне типов запрещайте себе слои и т.п. в чем проблема? создайте свой dsl и радуйтесь
                +4
                Если вам не нравится современные языки, напишите свой с блекджеком и паттернами.
                  0
                  Я вот хочу указать, что проект состоит из трех слоев ABC и из С использовать A напрямую нельзя. Как мне это сделать в любом современном языке?
                  Как на уровне языка отделить презентацию от модели? Я хочу объявить «слой модели» и запретить использовать в нем классы из UI.


                  Ну это вы можете сделать уже давно. Почитайте про то, что такое на самом деле инкапсуляция/сокрытие, почитайте про «компонентное проектирование», почитайте про правильное использование пространств имён и про то что в вашем любимом языке уже есть package private область видимости — и пользуйтесь на здоровье.
                    0
                    > Почему бы не заложить в язык паттерны?

                    почему в питоне нет паттернов
                    почему в лиспе нет паттернов

                    ну, то есть здесь ответ примерно такой же, я думаю

                    +1
                    Дико понравились фишки с методами и пропертями класса через лямбда выражения (через =>), и «интерполяция» строк типа '$salutation, $name'. Хотя количество языков от гугл настораживает (Go, Dart).
                      +3
                      Добавлю ещё одну, на мой взгляд, важную подробность. Параллелизм в Dart будет реализован через акторы и обмен сообщениями:

                      3.3 Concurrency
                      Dart code is always single threaded. There is no shared-state concurrency in
                      Dart. Concurrency is supported via actor-like entities called isolates.
                      An isolate is a unit of concurrency. It has its own memory and its own
                      thread of control. Isolates communicate by message passing (10.14.4). No state
                      is ever shared between isolates. Isolates are created by spawning (10.11).

                      Спецификация
                        0
                        Насколько я понял это уже реализовано в Standalone VM. См. пример чат сервера в исходниках.
                        +3
                        неплохо, однако стоит уделить внимание некоторым «вычурным» на мой взгляд местам:
                        1)
                        var a = new Symbol('something');
                        var b = new Symbol('something');

                        >>Второй вызов на самом деле не создаст новый символ, а вернет уже имеющийся.
                        простите, но на мой взгляд, если я говорю new, то я имею ввиду создать новый, собственно, поэтому я и пишу new. Намного более гибким является использование статического метода.

                        >> Это удобно, так как если сначала нам не был нужен фабричный конструктор, а потом оказалось, что таки был, нам не придется где-то в коде менять new на вызов статического фабричного метода.
                        ну это вообще не оправдание для «ленивых», а собственно, возможный генератор ошибок.

                        2) >> Чтобы объединить несколько строк в одну, вы можете использовать конкатенацию:…
                        >> Но интерполяция будет чище и быстрее:…
                        Они не догадались сделать проверку типа скобок. Или это баг автора? К примеру, в php знак $ в строке с двойными кавычками является подстановкой значения переменной, а с одинарной — то что действительно записано в строке, что является более правильным подходом, на мой взгляд, так как дает разработчику выбор того, что он хочет вывести в строке без еще одного экранирования спец. символа. (кстати, здесь хоть экранирование '\$name' работает?)

                        3) Равенство ==/!= и ===/!==
                        Это вообще что-то страшное. В языке с динамической типизацией использовать == и != как проверку на эквивалентность (значение и тип)…
                          0
                          1) не правда, все работает так как и должно

                          2) экранирование работает

                          3) == и === не одно и то же.

                          try-dart-lang.appspot.com/s/MSsT
                            0
                            1) не понял, что в Вашем понимании «все работает так как и должно»?
                            2) хоть на этом спасибо )
                            3) я имел ввиду не равенство между == и ===, а раздел поста с названием «Равенство»
                              0
                              1) Не обращайте внимания, это я поспешил
                              3) после N-ого круга перечитывания фразы, я понял о чем вы =)
                                +2
                                3) Ваще фигня какая-то творится х_Х

                                try-dart-lang.appspot.com/s/s1wT
                                  0
                                  как раз то, что описано в разделе про «Равенство», == здесь является проверкой на эквивалентность, то есть проверка по значению и типу, и не выполняет каких либо преобразований типов
                                    –2
                                    Так получается она == и === — одно и то же. Раз примитивы сравниваются по значению (но по факту, они как в джаве ссылаются на один и тот же адрес в пуле), а сложные переменные по адресу…

                                    Не ясно зачем они так сделали… Вообще там сыро все… очень сыро… Может в светлом будущем…

                                    Лучше бы Кофескрипт скопировали, добавили опциональную типизацию и убрали один момент, где кофескрипт умничает и не дает создать локальную переменную с таким же именем, что и глобальная (или в родительском замыкании).
                              +2
                              Первый пункт, это же не особенность языка в целом, это особенность конкретного примера Factory конструктора. Если такое поведение не нравится, просто не пишите такие конструкторы
                                0
                                Как поступать со сторонними библиотеками? Пока в код не залезешь непонятно, используют они Factory конструктор или нет.
                                  +2
                                  Вызывающий код должен знать только публичный интерфейс библоиотеки. Factory-конструктор или обычный — это детали реализации, которые вам, как пользователю библиотеки знать незачем.

                                  И перечитайте пример кода еще раз. Factory Constructor != конструктор, всегда возвращающий один и тот же объект. Просто в гугле не очень удачный пример выбрали для демонстрации этой фичи
                                    –2
                                    Допустим, есть класс Point(x, y, z), я как пользователь не знаю реализации, и мне нужны две точки в одном месте: p1 = Point(1, 2, 3); p2 = Point(1, 2, 3); Как мне узнать p1 и p2 — это один и тот же объект или 2 разных? каждый раз проверять? А если они в разных местах инициализируются?
                                      +3
                                      Чукча не читатель, чукча — писатель? Дважды уже разъяснено в чем дело.
                                        +3
                                        Пример на старом добром JS:

                                        global oneEvilObject = {x:1, y:2, z:3};

                                        function Point() {
                                        return oneEvilObject;
                                        }

                                        p1 = new Point();
                                        p2 = new Point();

                                        Как вы определите что p1 и p2 это один объект не смотря в код и не делая явных проверок?
                                        Говнокодить можно на чем угодно. Повторюсь, кеш — это просто не самое удачное приминение для Factory-конструктора
                                          +2
                                          Такие фабрики для immutable объектов, а для них всё равно один это объект или два одинаковых
                                            0
                                            Пожалуй, солглашусь, для неизменяемых объектов это действительно весьма удобно и прозрачно будет
                                              0
                                              Да, но mutable объекты тоже можно запросто делать через такие фабрики. А с ними могут быть проблемы, очевидно же.
                                                +1
                                                Ну если ты используешь что-то подобное для изменяемых объектов, то ты должен понимать, что ты делаешь. В некоторых случаях это даже полезно, Borg pattern, например, частный случай.

                                                Если ты не знаешь, что ты делаешь, ну что ж, делать глупости не запретишь. На самом деле, запрещать делать глупости скорее вредно, чем полезно.
                                    +2
                                    В языке с динамической типизацией использовать == и != как проверку на эквивалентность

                                    Задолбали путать динамическую и слабую типизации, блин.
                                      0
                                      я не путаю эти понятия, просто в разделе «Равенство» написано, что будет произведена проверка без каких-либо неявных преобразований, такой акцент вызвал у меня обратную реакцию и я «прочитал между строк, что этот язык с динамической типизацией».
                                      0
                                      1) я думаю, что авторы языка исходили примерно из следующих соображений:

                                      изначально был
                                      class Symbol {
                                      Symbol (String name)…
                                      }

                                      теперь мы решили добавить фабрику. раньше мы бы просто объявили конструктор приватным, сделали бы статический метод и стали бы исправлять все места в коде, где создаются объекты

                                      гугловцы в данном случае избавились от последнего. если же нам действительно нужен ещё какой-то конструктор, который всегда-всегда возвращает новые объекты, нам никто не мешает создать дополнительный конструктор Symbol.alwaysCreateNew(String name)
                                        0
                                        я за new как за такой «дополнительный конструктор» ;)
                                        а вообще, это не трагедия, просто от этого страдает чистота языка что-ли
                                          0
                                          насколько я понимаю, можно как раз дополнительный конструктор сделать фабричным, а new сделать просто new.
                                          но с практической точки зрения мне больше их вариант нравится, с new не-нью.
                                      +8
                                      Ерунда какая-то, очередной полуимперативный-полуфункциональный язык, каких навалом вокруг. Все его штучки в том или ином виде давным давно есть в JS 1.6+, PHP 5.3+, а в питоне вообще в незапамятных времён. Зачем? Такой можно сочинить для развлечения, будучи студентом и изучая теорию компиляторов.

                                      Я всё-таки поддержу general. Давно пора начать думать о ещё более высокоуровневых языках, нативно и красиво реализующих те же контракты, аспекты и какие-то устаканившиеся паттерны.
                                        +4
                                        >> Все его штучки в том или ином виде давным давно есть
                                        А что вы хотели написать do Chuck Norris и программа готова? Вот и напишите спецификацию, устройте презентацию крупным компаниям, сможете доказать эффективность вашего сферического коня, может получите грант. А просто говорить о какой супер абстрагированном языке все могут.
                                        • UFO just landed and posted this here
                                            –2
                                            Все те вещи, что императивщики подсмотрели у функциональщиков — first-class functions, лямбды, замыкания и т.п.
                                            +1
                                            Вообще-то паттерны проектирования — это баги, а не фича. Попытка обойти ограничения ОО-языков.
                                            Если бы они написали настоящий функциональный язык — вот это было бы круто. И да, насчёт «высокоуровневых абстракций» — что может быть абстрактнее категорий? ОО — это как ассемблер vs. с# по сравнению с достойным функциональным языком.
                                            +3
                                            try-dart-lang.appspot.com/ — Потыкать в реальном времени.
                                              0
                                              Хм, по моим ощущениям такой комплект забавных но не критичных особенностей как-то не оправдывает необходимость введения нового стандарта (языка), ну разве что типизация.
                                              Хотя сейчас под него быстро портируют ключевые JS библиотеки и можно будет уже более предметно смотреть что к чему.
                                                +2
                                                ИМХО, NodeJS нуждается в подобной вещи.
                                                  0
                                                  Сам Node.JS не нуждается, там все таки все завязано на java script. Можно будет сделать новый сервер сайд по типу node.js.
                                                    +1
                                                    ryah: Dart is the JavaScript I've always wanted
                                                    twitter.com/ryah/status/123576132250501120
                                                    Ryan Dahl как бы одобряет Dart.
                                                      0
                                                      Ну это как бы прикольно. Я что-то не могу понять что Ryan сможет сделать связи с этим.
                                                +4
                                                Отличное название для языка, специально, чтобы было ничего не найти в гугле :)
                                                  +4
                                                  С предыдущим (Go) у них круче получилось.
                                                    +3
                                                    Да ладно, как будто вы никогда не гуглили ничего по С.
                                                  0
                                                  Ох велосипедисты.
                                                    +7
                                                    Я что-то не понял, почему нельзя просто
                                                    bool contains(num x, num y) {
                                                    return (x < width) && (y < height);
                                                    }

                                                    записать как
                                                    bool contains(num x, num y) { return (x < width) && (y < height); }
                                                    если очень хочется однострочник? Такая прям большая разница с
                                                    bool contains(num x, num y) => (x < width) && (y < height);
                                                    ? Я уж молчу, что если понадобится добавить вторую строчку, придётся всё равно на скобки переписывать.
                                                      +3
                                                      Dart integers are true integers, not
                                                      32 bit or 64 bit or any other ?xed range representation. Their size is limited only
                                                      by the memory available to the implementation.
                                                        +5
                                                        Эффект «uncanny valley», он же «зловещая долúна». Перестарались. Язык Dart слишком походит на джаву и джаваскрипт, поэтому воспринимается не как «интересный новый язык», а как «зачем джаву и джаваскрипт извратили, изверги».
                                                          0
                                                          Не понял одного момента: в начале статьи было сказано, что «как большинство динамических языков, Dart не поддерживает перегрузку», а потом описано создание перегруженных операторов. Получается, для класса можно объявить только один оператор+?
                                                            0
                                                            Там в первом случае overload, а во втором — override: overload vs override. Я немножко неаккуратно перевел, не люблю слово «переопределение»
                                                              +1
                                                              Значит в Dart нельзя сделать такое в одном классе?
                                                              operator +(num A) =>…
                                                              operator +(String a) =>…
                                                                0
                                                                Я пока сам толком не понял насчет «добровольно-принудительной» типизации. Вроде как она сделана больше для понятности кода, так что ваш пример для интерпретатора будет выглядеть, как
                                                                operator +(Dynamic A) =>…
                                                                operator +(Dynamic a) =>…
                                                                Так что нельзя. Сигнатуры одинаковые.
                                                            –3
                                                            Посмотрим на правдивые реалии. Многие юзают такую замечательную вещь, как jQuery(MooTools,Prototype и т.д.). Да и в JS в браузерах, есть поиск по селекторам. Если я юзаю JS в браузере, то с большей вероятностью, я буду работать с DOM-моделью. И как будет юзаться это с Dart? Нет, я потом конечно думаю увижу такие статьи как «Запуск jQuery на Dart.». Т.е. рождение костыля. При должном проектировании — всё это не так требуется. 80% нынешних разработчиков, которые используют JS в своих проектах, забывают про его асинхронную природу и правило «в функциях и методах, как можно скорее отдавать управление».

                                                            Мне совсем не нравится что в событийно-ориентированном, скриптовом языке, который преследует асинхронное выполнение, пытаются создать нового монстра. Может вы неправильно выбрали технологию для решения своих задач, если из одного языка, пытаетесь трансформировать в другой?

                                                            Дальше, еще больше. Есть возможность трансляции в JS код. Кто может гарантировать то, что транслированный код, будет успешно работать в браузерах, и не конфликтовать с их базовыми методами(и их реализациями) класса window. И в случае проблем — мне что, придется копаться в то, что сгенерировал транслятор? Ну уж спасибо — нет. Да и насколько оптимизированным получится код? Нынешние браузеры и так жрут нещадно память.

                                                            Вообще — стоит поизучать подходы решения задач в при однопоточном, но асинхронном выполнении. И если для вашей задачи это не подходит, выберите другой язык.
                                                            Тем кто разрабатывает новые языки, поверх JS. Разрабатывается черновик JS 1.9 и JS 2.0.Может стоит разработчикам спецификации выслать свое мнение? Причем с учетом направленности JS.

                                                            Всё выше относится и к Ноде. Кстати, где-то я находил (если найду в хистори, ссылку скину) классный профессиональный перевод, где Райан Дал, описывал рекомендации, при написании JS приложения. Тем — кто хочет видеть данный подход в Ноде, юзайте лучше EventMaschine с Ruby.
                                                              +3
                                                              1. Это не язык поверх JS. Это отдельный язык на данный момент использующий трансляцию в JS. Это не значит что это всегда так будет.
                                                              2. Не конфликтовать наверно может гарантировать область видимости, вы то сами как думаете? Вы же не ставите вопрос, «кто мне гарантирует в каждой браузере document.querySelector», логично что производитель браузера и гарантирует либо либа какая-то либо что вы сами себе гарантируете.
                                                              3. «Запуск jQuery на Dart… Т.е. рождение костыля» — может я открою для вас тайну но реализация DOM не имеет никакого отношения какой язык используется. Это API. Поэтому jquery вообще тут не причем.

                                                              Вас под дулом пистолета никто не заставляет использовать этот язык. Это язык даже без версии пока. Поэтому в продакшине адекватные люди врядли счас его будут использовать.
                                                                –1
                                                                1) для ие значит
                                                                2а) судя по тексту примера с 17k строчками кода — все в глобале
                                                                2б) есть такое старое и банальное понятие: «определение возможностей юзер агента»
                                                                3) а в джиквери только дом? megaalli66 говорил о существующей архитектуре — что с ней делать? транслировать в dart, а для ие — обратно в скрипт? тут как раз такой топик пробегал: habrahabr.ru/blogs/humour/130150/
                                                                +1
                                                                > в языке, который преследует асинхронное выполнение

                                                                погоня это хорошо. вы наверное прогуливали уроки литературы.

                                                                > Вообще — стоит поизучать подходы решения задач в при однопоточном, но асинхронном выполнении.

                                                                вы это гуглу, аудитории или самому себе? гугл в курсе, даже яваскриптовый движок написали, аудитория в основном тоже в курсе подходов решения задач при однопоточном выполнении. вопрос про литературу я уже задавал

                                                                > И если для вашей задачи это не подходит, выберите другой язык.

                                                                that's it! именно так они и поступили! другой язык! это НЕ javascript! да! именно другой язык! спасибо за совет! вы такой умный!
                                                                +2
                                                                Жаль что не поддерживает Destructuring assignment. Код выдает ошибку:
                                                                main() {
                                                                  num x = 1, y = 2;
                                                                  [x, y] = [3, 4];
                                                                  print(x);
                                                                }
                                                                  0
                                                                  Возможно слегка не по теме…
                                                                  Моей мечтой было бы увидеть реализацию двух пространств имен для объекта. Хотя это довольно экзотическая вещь. Например можно было бы всякие toString() toInt() toRainbow() писать в отдельный namespace и реализовать две ветки наследования. Это действительно может быть очень полезно при определенных архитектурах, ну и вспомните хотя бы про необходимость использовать сейчас hasOwnProperty (а если проверку нужно делать везде и для прямого родителя? с ума сойти). Еще можно вспомнить про заблокированное свойство name у функций.

                                                                  Выглядеть это могло бы например так:
                                                                  object.method() и object.$method()

                                                                  И надеюсь будет хоть какая-то возможность прототипировать функции.
                                                                    0
                                                                    Меня, как дизайнера, в эту статью привлек отличный логотип =)
                                                                        +2
                                                                        О боже
                                                                          +1
                                                                          17200 строк! Рантайм не самый легкий
                                                                            0
                                                                            ну они там весь рантайм подключают при отключенных оптимизациях, как я понял
                                                                            с оптимизациями значительно короче
                                                                            gist.github.com/1277306
                                                                              0
                                                                              если бы обфускация использовала eval зипованной строки, то получилось бы еще вдвое короче, а так код всего на 22'290% длиннее вышел.
                                                                                0
                                                                                если собрать в visual studio 2008 вот этот привет мир, то получится 90 кб. да плюс ещё msvcrt71.dll на 350 кб.

                                                                                #include int main() {
                                                                                std::cout << «Hello, world» << std::endl;
                                                                                }

                                                                                а на ассемблере, говорят, всего 500 байт. означает ли это, что нужно писать на ассемблере? нет, не означает.

                                                                                вернёмся к нашему дарту. если бы неоптимизированный вариант убирал неиспользуемый код из рантайм лайбрари, то кода было бы намного меньше. грубо говоря, компилятор в js работает следующим образом:
                                                                                result = compile(input)
                                                                                result += get_all_javascript_runtime_source
                                                                                if (optimize) {
                                                                                result = remove_unused_functions(result)
                                                                                result = optimize_cycles(result)
                                                                                result = remove_unused_sideeffects(result)
                                                                                result = do_something_noone_understands_except_author(result)
                                                                                result = obfuscate_and_compress_and_fuck_op(result)
                                                                                }
                                                                                  0
                                                                                  скорость загрузки страницы
                                                                                    0
                                                                                    кэшируем рантайм и вуаля. jquery все уже тоже давно тянут с внешних серверов и он не загружается каждый раз при загрузке каждой страницы
                                                                                      0
                                                                                      > все
                                                                                      ctrl+u нажми, например
                                                                                        0
                                                                                        ок, но сути не меняет
                                                                                        all.js
                                                                                        /javascripts/1318261449
                                                                                        GET
                                                                                        304
                                                                                        Not Modified
                                                                                        все равно кэшируется
                                                                                          0
                                                                                          это тоже сути не меняет. мы только что выяснили, что-таки не «все» используют cdn (имхо, далеко не 50%), и что при первом открытии сайта, написанного на dart, рантайм надо будет еще один раз. а при последующих (на 99% сайтов) — будет лететь запрос для даты обновления.
                                                                                            0
                                                                                            *рантайм надо будет грузить еще один раз
                                                                                      0
                                                                                      ты что, дурак? что значит «скорость загрузки страницы»? скорость загрузки страницы что? какой страницы?
                                                                                        0
                                                                                        ну я точно не гугль, чтобы тебе понятия расшифровывать.
                                                                                          0
                                                                                          лестница монокль утконос
                                                                                            0
                                                                                            а я тебя как бы спрашиваю: ну и что это значит? при чём тут «скорость загрузки страницы цветок сельдерей помидор»? а ты меня посылаешь в гугль.
                                                                                              0
                                                                                              ты мне как бы сказал: «ты что, дурак?» скорость загрузки страницы — это параметр прямопропорциональный возгласу «чтож все еле грузится!». чем больше надо грузить — тем хуже, и чем больше запросов — тем хуже. там 30 кило, там еще 30, еще несколько раз — и сайтик уже не «летает».

                                                                                              а при отпимизированном для каждой страницы рантайме аргументы от fleshy (см. выше) надо делить на кол-во страниц в интернете (ну за вычетом глубины просмотра).

                                                                                              и не надо сейчас говорить, что dart будет только на приложениях вроде гуглопочты использоваться.
                                                                                                0
                                                                                                спасибо, что пояснил свою мысль.

                                                                                                во-первых, я все-таки скажу то, чего ты сказал что говорить не надо.
                                                                                                использовать dart на маленьких страничках до тех пор, пока не будет нативной поддержки языка браузером — это глупость, даже глупее чем грузить jquery ради единственного вызова селектора по id — $('#id')

                                                                                                во-вторых, сейчас язык ещё даже не в альфа-версии. то есть оптимизацией никто как бы и не занимался особенно (ну, нафигачили за 10 минут вызов js-сжимателя, и как бы всё). думаю, что к бета-версии (если она вообще будет) проблема с большим рантаймом будет как-то решена. среди возможных вариантов:
                                                                                                1. оптимизировать руками (1 раз), потом сжать весь рантайм, выложить её на гугл-cdn
                                                                                                2. оптимизировать руками (1 раз), для каждого приложения делать свою сборку рантайма. будет уже не 30кб, а там 5 например. или меньше, смотря насколько они постараются.

                                                                                                да, это не идеальные решения, но любое из них жизнеспособно.
                                                                                                  0
                                                                                                  вопросов два.

                                                                                                  1) кто будет заниматься отпимизацией? т.е. не «огласите весь список, пожалуйста», а сколько разработчиков на это не забьют? 1%, 3%, 5%?

                                                                                                  поначалу вообще будут делать сайты на дарте только чтобы посмотреть что это за зверь такой — прямо на альфа-версии со всеми недостатками, даже не зная а нужно ли вообще этот дарт использовать.

                                                                                                  2) пока что я каких-то революционных плюсов у dart'а не заметил. как ни отпимайзь файлы — профит от их загрузки должен быть.

                                                                                                  ps 30кб это округленный вес gist.github.com/1277306 — как раз отпимизированного и минифаенного рантайма, откуда «5 например» получились?
                                                                                                    0
                                                                                                    1) оптимизацией будет заниматься Гугл. сейчас они на коленке нахерачили какой-то рантайм который хорош тем, что работает. других плюсов у него нет.
                                                                                                    когда будет релиз — я почти уверен, что они перепишут тот код, который есть сейчас, по-нормальному, и вместо 17к строк будет гораздо меньше.
                                                                                                    с другой стороны, оптимизатор (если использовать оптимизатор не для любых js-файлов, а с уклоном в js-файлы, получающиеся после компиляции дарта) сможет быть более агрессивным и выкидывать больше ненужных кусков кода. я уверен, что простыми машинными действиями можно свести размер хелловорлда до нескольких сот байт, но я также уверен, что это — не основное, куда стоит тратить ресурсы гуглу. поэтому, думаю, что какая-то оптимизация будет, но разумная. я выбрал разумную цифру в 5кб и сообщил её, чтобы наша дискуссия не висела в воздухе.
                                                                                                    естественно, что в текущем виде дарт можно использовать только для экспериментов. ну, для домашних страничек может быть

                                                                                                    2) а какие революционные плюсы должны быть? в своей области применения плюсы довольно очевидны: основной плюс это опциональная статическая типизация и отказ от этой js-ной прототипизации.
                                                                                                      0
                                                                                                      1) я про отпимизацию файлов, которую ты предложил:
                                                                                                      > 1. оптимизировать руками (1 раз), потом сжать весь рантайм, выложить её на гугл-cdn
                                                                                                      > 2. оптимизировать руками (1 раз), для каждого приложения делать свою сборку
                                                                                                      имхо, этим будут заниматься 5% разработчиков. не имхо, даже если все 20%, в целом инет станет помедленнее. никакого профита.

                                                                                                      2) этих двух плюсов достаточно для нового языка, требующего переписывания (пусть и автоматического) всех существующих библиотек? точнее даже одного плюса — опциональная статическая типизация. т.к. есть библиотеки/решения эмулирующие классические public/protected/private/extend. ну, это если прототипирование вообще относить к минусам.

                                                                                                      в новой екме class'ы обсуждаются. а вероятность реализации в ie следующей спецификации js выше (нулевой) вероятности имплементации языка от прямого конкуретна.

                                                                                                      я читал статью и вижу, что еще можно, например, оператор сложения переопределить — но действительно ли все это (для классов, повторюсь, есть библитечки.js) тянет на изучение нового синтаксиса и новых заморочек (тоже ==)?
                                                                                                        0
                                                                                                        я про отпимизацию файлов, которую ты предложил:
                                                                                                        да. «оптимизировать руками (1 раз)» — это сделает гугл. именно об этом я и говорил

                                                                                                        > в целом инет станет помедленнее

                                                                                                        в браузерах, которые не будут поддерживать этот язык нативно

                                                                                                        > выше (нулевой) вероятности имплементации языка от прямого конкуретна

                                                                                                        я бы не сказал, что вероятность нулевая. в Win8 и Metro мелкософтовцы взяли курс на HTML5+JS как основное средство для разработки приложений. я бы даже сказал, как «платформу для native-приложений». а дарт как раз для таких задач и предназначен. microsoft конечно не империя добра, но своего не упускает.

                                                                                                        > этих двух плюсов достаточно для нового языка, требующего переписывания (пусть и автоматического) всех существующих библиотек?

                                                                                                        это довольно сложный вопрос, который нужно адресовать авторам языка. видимо, достаточно.
                                                                            +2
                                                                            Язык хороший, но как быть с IE?
                                                                            Если MS его поддерживать не будет, то смысла на клиенте в нем не много…
                                                                              +1
                                                                              именно для этого и есть компилятор в javascript, который позволит использовать новый язык даже на старых говнобраузерах.

                                                                              ну а в будущем наверное поддержат, если у гугла получится широко распространить язык
                                                                                +1
                                                                                IE? Кто такой IE?
                                                                                  0
                                                                                  Google Chrome Frame?
                                                                                  0
                                                                                  Ну чо — круто :) В хромах работает? Как плагин можно зацепить к FF или IE?
                                                                                    0
                                                                                    А как с многопоточностью, как это запилили?
                                                                                    0
                                                                                    Я правильно понимаю, что язык не конкурент Node.js? Dart это альтернатива клиентскому JavaScript, а для бекенда google все также будут пилить Go?
                                                                                      0
                                                                                      Там же и серверная VM есть. Конкурент или не конкурент — пока не ясно.
                                                                                      +3
                                                                                      прошу прощения, что на английском

                                                                                      You appear to be advocating a new:
                                                                                      [ ] functional  [ ] imperative  [ ] object-oriented  [ ] procedural [ ] stack-based
                                                                                      [ ] "multi-paradigm"  [ ] lazy  [ ] eager  [ ] statically-typed  [ ] dynamically-typed
                                                                                      [ ] pure  [ ] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
                                                                                      [ ] non-programmer-friendly  [ ] completely incomprehensible
                                                                                      programming language.  Your language will not work.  Here is why it will not work.
                                                                                      
                                                                                      You appear to believe that:
                                                                                      [ ] Syntax is what makes programming difficult
                                                                                      [ ] Garbage collection is free                [ ] Computers have infinite memory
                                                                                      [ ] Nobody really needs:
                                                                                          [ ] concurrency  [ ] a REPL  [ ] debugger support  [ ] IDE support  [ ] I/O
                                                                                          [ ] to interact with code not written in your language
                                                                                      [ ] The entire world speaks 7-bit ASCII
                                                                                      [ ] Scaling up to large software projects will be easy
                                                                                      [ ] Convincing programmers to adopt a new language will be easy
                                                                                      [ ] Convincing programmers to adopt a language-specific IDE will be easy
                                                                                      [ ] Programmers love writing lots of boilerplate
                                                                                      [ ] Specifying behaviors as "undefined" means that programmers won't rely on them
                                                                                      [ ] "Spooky action at a distance" makes programming more fun
                                                                                      
                                                                                      Unfortunately, your language (has/lacks):
                                                                                      [ ] comprehensible syntax  [ ] semicolons  [ ] significant whitespace  [ ] macros
                                                                                      [ ] implicit type conversion  [ ] explicit casting  [ ] type inference
                                                                                      [ ] goto  [ ] exceptions  [ ] closures  [ ] tail recursion  [ ] coroutines
                                                                                      [ ] reflection  [ ] subtyping  [ ] multiple inheritance  [ ] operator overloading
                                                                                      [ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
                                                                                      [ ] covariant array typing  [ ] monads  [ ] dependent types
                                                                                      [ ] infix operators  [ ] nested comments  [ ] multi-line strings  [ ] regexes
                                                                                      [ ] call-by-value  [ ] call-by-name  [ ] call-by-reference  [ ] call-cc
                                                                                      
                                                                                      The following philosophical objections apply:
                                                                                      [ ] Programmers should not need to understand category theory to write "Hello, World!"
                                                                                      [ ] Programmers should not develop RSI from writing "Hello, World!"
                                                                                      [ ] The most significant program written in your language is its own compiler
                                                                                      [ ] The most significant program written in your language isn't even its own compiler
                                                                                      [ ] No language spec
                                                                                      [ ] "The implementation is the spec"
                                                                                         [ ] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you
                                                                                      [ ] Your type system is unsound  [ ] Your language cannot be unambiguously parsed
                                                                                         [ ] a proof of same is attached
                                                                                         [ ] invoking this proof crashes the compiler
                                                                                      [ ] The name of your language makes it impossible to find on Google
                                                                                      [ ] Interpreted languages will never be as fast as C
                                                                                      [ ] Compiled languages will never be "extensible"
                                                                                      [ ] Writing a compiler that understands English is AI-complete
                                                                                      [ ] Your language relies on an optimization which has never been shown possible
                                                                                      [ ] There are less than 100 programmers on Earth smart enough to use your language
                                                                                      [ ] ____________________________ takes exponential time
                                                                                      [ ] ____________________________ is known to be undecidable
                                                                                      
                                                                                      Your implementation has the following flaws:
                                                                                      [ ] CPUs do not work that way
                                                                                      [ ] RAM does not work that way
                                                                                      [ ] VMs do not work that way
                                                                                      [ ] Compilers do not work that way
                                                                                      [ ] Compilers cannot work that way
                                                                                      [ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
                                                                                      [ ] You require the compiler to be present at runtime
                                                                                      [ ] You require the language runtime to be present at compile-time
                                                                                      [ ] Your compiler errors are completely inscrutable
                                                                                      [ ] Dangerous behavior is only a warning
                                                                                      [ ] The compiler crashes if you look at it funny
                                                                                      [ ] The VM crashes if you look at it funny
                                                                                      [ ] You don't seem to understand basic optimization techniques
                                                                                      [ ] You don't seem to understand basic systems programming
                                                                                      [ ] You don't seem to understand pointers
                                                                                      [ ] You don't seem to understand functions
                                                                                      
                                                                                      Additionally, your marketing has the following problems:
                                                                                      [ ] Unsupported claims of increased productivity
                                                                                      [ ] Unsupported claims of greater "ease of use"
                                                                                      [ ] Obviously rigged benchmarks
                                                                                         [ ] Graphics, simulation, or crypto benchmarks where your code just calls
                                                                                             handwritten assembly through your FFI
                                                                                         [ ] String-processing benchmarks where you just call PCRE
                                                                                         [ ] Matrix-math benchmarks where you just call BLAS
                                                                                      [ ] Noone really believes that your language is faster than:
                                                                                          [ ] assembly  [ ] C  [ ] FORTRAN  [ ] Java  [ ] Ruby  [ ] Prolog
                                                                                      [ ] Rejection of orthodox programming-language theory without justification
                                                                                      [ ] Rejection of orthodox systems programming without justification
                                                                                      [ ] Rejection of orthodox algorithmic theory without justification
                                                                                      [ ] Rejection of basic computer science without justification
                                                                                      
                                                                                      Taking the wider ecosystem into account, I would like to note that:
                                                                                      [ ] Your complex sample code would be one line in: _______________________
                                                                                      [ ] We already have an unsafe imperative language
                                                                                      [ ] We already have a safe imperative OO language
                                                                                      [ ] We already have a safe statically-typed eager functional language
                                                                                      [ ] You have reinvented Lisp but worse
                                                                                      [ ] You have reinvented Javascript but worse
                                                                                      [ ] You have reinvented Java but worse
                                                                                      [ ] You have reinvented C++ but worse
                                                                                      [ ] You have reinvented PHP but worse
                                                                                      [ ] You have reinvented PHP better, but that's still no justification
                                                                                      [ ] You have reinvented Brainfuck but non-ironically
                                                                                      
                                                                                      In conclusion, this is what I think of you:
                                                                                      [ ] You have some interesting ideas, but this won't fly.
                                                                                      [ ] This is a bad language, and you should feel bad for inventing it.
                                                                                      [ ] Programming in this language is an adequate punishment for inventing it.
                                                                                      


                                                                                      отсюда

                                                                                      Only users with full accounts can post comments. Log in, please.