Add support for lazy transformers.

pkg/barback/lib/src/lazy_transformer.dart

+// Copyright (c) 2014, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+library barback.lazy_transformer;
+
+import 'dry_run_transformer.dart';
+
+/// An interface for [Transformer]s that indicates that the transformer's
+/// outputs shouldn't be materialized until requested.
+///
+/// The [dryRun] method is used to figure out which assets should be treated as
+/// "lazy." Lazy assets will only be materialized if they're requested by the
+/// user or if they're used by a non-dry-run transformer.
+abstract class LazyTransformer extends DryRunTransformer {}

[Bob Nystrom, 2014/01/30 19:33:44]

Is this so that you can distinguish between:

1. A transformer that can declare its outputs but also wants to be run eagerly.
2. A transformer that declares its outputs but only generates them lazily.

?

I like being able to express this distinction, but I think using types for this
may be confusing to users. They may not realize that choosing which of two
identical interfaces to implement affects the runtime behavior of their
transformer.

It's also less flexible, since this is a static declaration. A transformer can't
choose to be lazy sometimes and eager others.

How about just having an isLazy getter on DryRunTransformer?

[nweiz, 2014/01/31 03:43:27]

Yes. The former is broadly useful (at least in theory), and we should encourage
any transformer that can to implement it.
A getter seems to invite the question "when is the getter accessed?". It's not
clear to me how the class communicates with a getter when laziness should be
activated or deactivated, or indeed what activating and deactivating laziness
means. If I toggle [isLazy] to false, does that mean all my existing lazy assets
become materialized?

I like having the conceptual clarity between being always and never lazy. I
think having laziness declared in the type of the class also helps surface to
users reading the docs that this transformer works differently than others.

I get what you're saying about checking interfaces being confusing, but I think
that's a problem to be solved with documentation. I think the fact that
LazyTransformer doesn't add any additional members is actually helpful here; it
prompts users to ask the question "so why does it exist?", thus leading them to
the documentation which will explain its purpose.

[Bob Nystrom, 2014/01/31 18:28:53]

+1.
How about we make it a method on DryRunTransform? So while the transformer is
doing the dry run, one thing it can do is tell barback, "hey, you should run me
lazily." That gives it control at runtime over this, and is the natural point in
time (while its looking at its inputs) where it should be expressed.

[nweiz, 2014/02/04 01:43:25]

I think the conceptual complexity of a transformer that's sometimes lazy is a
lot higher than one that always is, and I don't think we have a clear use-case
for it anyway. If someone really wanted to do so, they could accomplish it with
a transformer group, but I don't think they're likely to.