[dart-misc] 09/17 DEP meeting notes

['Bob Nystrom' via Dart Misc]

Here's my notes from yesterday's meeting:

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-16%20DEP%20Committee%20Meeting.md

Cheers!

- bob

['Brian Slesinsky' via Dart Misc]

It seems like the const language is a subset of Dart, right? I mean, other
than that there are too many "const" keywords. So I'm not sure that the
objections about it being a separate language apply; it's not really a
separate thing to learn.


On Thu, Sep 17, 2015 at 10:30 AM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-16%20DEP%20Committee%20Meeting.md
Cheers!
- bob
--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by 'Brian Slesinsky' via Dart Misc
It seems like the const language is a subset of Dart, right?

There's canonicalization rules.

Post by 'Brian Slesinsky' via Dart Misc
I mean, other than that there are too many "const" keywords. So I'm not
sure that the objections about it being a separate language apply; it's not
really a separate thing to learn.

It would be separate in the sense that there would be some functions or
APIs you can use in const expressions and some you can't. Think of the fun
of trying to write const-correct code in C++.

- bob

[tatumizer-v0.2]

@Bob: recently introduced ".packages" file already adds a level of
indirection by mapping library names used in "import" to names/locations of
real libraries.
It's easy to add conditions to the syntax of this file, something like (I'm
making it up):
myLib:../../packages/mylib-io-0.1/lib if platform=="standalone"
myLib:../../packages/mylib-browser-0.1/lib if platform=="browser"

In dart program, you can simply import "myLib". If you are using it in
several files, no need to copy&paste import conditions - compiler just
follows indirection for "myLib" as configured in .packages file.
No need to define library interface or make any other changes to the
language.

This seems to cover everything up to phase 0 (inclusive). If there's a
desire to go beyond phase 0, you can write standalone utility that checks
compatibility of different variants of the library (e.g. mylib-browser and
mylib-io) Again, no changes in the language are necessary for this.

Are you sure your proposal achieves so much more than that to justify
complexity, development effort, ugliness, unknown number of
yet-to-be-discovered problems, etc. ?
Unless I miss something important, these 2 solutions are otherwise
equivalent, it's just one of them is trivial, another is complicated.

[Günter Zöchbauer]

@Bob:  recently introduced ".packages" file already adds a level of indirection by mapping library names used in "import" to names/locations of real libraries.
myLib:../../packages/mylib-io-0.1/lib if platform=="standalone"
myLib:../../packages/mylib-browser-0.1/lib if platform=="browser"
In dart program, you can simply import "myLib". If you are using it in several files, no need to copy&paste import conditions - compiler just follows indirection for "myLib" as configured in .packages file.
No need to define library interface or make any other changes to the language.
This seems to cover everything up to phase 0 (inclusive). If there's a desire to go beyond phase 0, you can write standalone utility that checks compatibility of different variants of the library (e.g. mylib-browser and mylib-io) Again, no changes in the language are necessary for this.
Are you sure your proposal achieves so much more than that to justify complexity, development effort, ugliness, unknown number of yet-to-be-discovered problems, etc. ?
Unless I miss something important, these 2 solutions are otherwise equivalent, it's just one of them is trivial, another is complicated.

You would need to create a different package for each platform. That would be against the intention to build packages that can be used on several platforms by encapsulation differences with platform-specific libraries.

Also the intention seems to be to also cover situations where a stripped-down SDK is used for constraint environments where some of the core libraries are not included.

['Erik Ernst' via Dart Misc]

I think we have two main design choices on the table: You can (1) get a lot
of flexibility with a textually based mechanism (e.g., introducing some
kind of `if` mechanism in '.packages' such that a given import directive
can be redirected to whatever you want; or using the `part` mechanism we
already have to compile the same code in multiple static contexts), and you
can (2) get the static guarantees associated with a proper in-language
mechanism, where there could (and should ;-) be a library signature and a
"type check" to ensure that each possible choice conforms to the given
signature. It seems unrealistic to achieve static guarantees with
'.packages', because that requires Dart the language to know about the
syntax used in '.packages'. But if we don't care about static guarantees
then I'm not sure it's worthwhile to change the language, then '.packages'
looks like an obvious way to go.

Post by tatumizer-v0.2

Post by tatumizer-v0.2
@Bob: recently introduced ".packages" file already adds a level of

indirection by mapping library names used in "import" to names/locations of
real libraries.

Post by tatumizer-v0.2
It's easy to add conditions to the syntax of this file, something like
myLib:../../packages/mylib-io-0.1/lib if platform=="standalone"
myLib:../../packages/mylib-browser-0.1/lib if platform=="browser"
In dart program, you can simply import "myLib". If you are using it in

several files, no need to copy&paste import conditions - compiler just
follows indirection for "myLib" as configured in .packages file.

Post by tatumizer-v0.2
No need to define library interface or make any other changes to the

language.

Post by tatumizer-v0.2
This seems to cover everything up to phase 0 (inclusive). If there's a

desire to go beyond phase 0, you can write standalone utility that checks
compatibility of different variants of the library (e.g. mylib-browser and
mylib-io) Again, no changes in the language are necessary for this.

Post by tatumizer-v0.2
Are you sure your proposal achieves so much more than that to justify

complexity, development effort, ugliness, unknown number of
yet-to-be-discovered problems, etc. ?

Post by tatumizer-v0.2
Unless I miss something important, these 2 solutions are otherwise

equivalent, it's just one of them is trivial, another is complicated.
You would need to create a different package for each platform. That would
be against the intention to build packages that can be used on several
platforms by encapsulation differences with platform-specific libraries.
Also the intention seems to be to also cover situations where a
stripped-down SDK is used for constraint environments where some of the
core libraries are not included.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
Unless I miss something important, these 2 solutions are otherwise
equivalent, it's just one of them is trivial, another is complicated.

What GÃŒnter said: the ".packages" file only gives you package level
granularity, but we want to be able to configure it per-library.

We also don't want to require users to regenerate a ".packages" file in
order to change configurations. That means we'd still need some kind of
conditional logic and the VM and dart2js would have to handle it. We could
put that logic in the ".packages" file, but that doesn't really make it any
less complex than putting it in the language.

Cheers!

- bob

[tatumizer-v0.2]

We could put that logic in the ".packages" file, but that doesn't really

make it any less complex than putting it in the language.

It makes it less complex and more "right" IMO. ".packages" file is a single
place where you configure "linking", instead of N places with the same
logic. E.g. If your app targets android and ios, almost every file will
contain (repetitive) import ... if ... if, instead of just plain and DRY
import.

Also, as soon as you mention the thing like "library interface", you need
to define it in the language spec, which is complicated and unnecessary IMO.
And you (probably) have to define the rules of conformance between library
interface and implementation - another big and boring piece of work

In contrast, with .packages configuration, you totally "separate concerns"
(I don't like this expression, it's often used to justify separation of the
inseparable, but here I think we have a valid case). Plus, conformance can
be verified by separate tool, instead of compiler - this does make things
simpler.

I don't know whether this idea was already considered and rejected, or
whatever, but please give it another thought, there's no rush :)

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2

We could put that logic in the ".packages" file, but that doesn't really

make it any less complex than putting it in the language.
It makes it less complex and more "right" IMO. ".packages" file is a
single place where you configure "linking", instead of N places with the
same logic.

That's a possible interpretation of the ".packages" file, but it's
different from how the Dart platform interprets it today. Today, it's just
the registry of URL prefixes that "package:" URLs resolve to. It's that,
and only that.

It has no policy, or semantics, or aspirations. It's just a bit of plumbing
to get some data from pub to the other tools in the SDK without coupling
those tools to lots of pub details.

Post by tatumizer-v0.2
E.g. If your app targets android and ios, almost every file will contain
(repetitive) import ... if ... if, instead of just plain and DRY import.

Heavens no. Dart's library mechanisms are more than expressive enough to
address this repetition. The whole point of this proposal is to let you
*encapsulate* configuration decisions in one place. The idea is *not* that
you'll have a hundred imports in your code like:

import 'logging.dart'
if (dart.library.html) 'logging_web.dart'
if (dart.library.io) 'logging_console.dart';


So that every place that needs to log can do so in a platform-appropriate
way. It's that you'll have *one* library like this:

// logging.dart
export 'logging_interface.dart'
if (dart.library.html) 'logging_web.dart'
if (dart.library.io) 'logging_console.dart';


And everything else will just have:

import 'logging.dart';

Post by tatumizer-v0.2
Also, as soon as you mention the thing like "library interface", you need
to define it in the language spec, which is complicated and unnecessary IMO.
And you (probably) have to define the rules of conformance between library
interface and implementation - another big and boring piece of work
In contrast, with .packages configuration, you totally "separate concerns"
(I don't like this expression, it's often used to justify separation of the
inseparable, but here I think we have a valid case). Plus, conformance can
be verified by separate tool, instead of compiler - this does make things
simpler.

All of the static analysis sections of the proposal, like you suggest,
would only be implemented in tools and not in dart2js, the VM, Fletch, etc.

I would be perfectly happy—I would strongly prefer it, in fact—if those
pieces of the proposal don't get enshrined in the language spec itself.
DEPs don't always have to land in the *spec*, they just need to land
in the *Dart
platform*. For example, the ".packages" DEP entailed almost no spec
changes. It was basically just an agreement on what the other various tools
would support.

Cheers!

- bob

[George Moschovitis]

Post by 'Bob Nystrom' via Dart Misc
So that every place that needs to log can do so in a platform-appropriate
// logging.dart
export 'logging_interface.dart'
if (dart.library.html) 'logging_web.dart'
if (dart.library.io) 'logging_console.dart';
import 'logging.dart';

Yeah, I was always curious why you where concentrating on import examples,
where actually export will be used in practice.
Perhaps you should add this clarification in the DEP.

[tatumizer-v0.2]

If you consider Android vs iOS, each coming with a large set of libraries,
you will need to write N auxiliary files like this:
// foo.dart
export 'foo_interface.dart'
if (dart.library.ios) 'foo_ios.dart'
if (dart.library.android) 'foo_android.dart';

So, a lot of tiny dart files, none of which actually looking like a
program. Rather, they are pieces of configuration. And they are not DRY by
any measure: "bar.dart" will be a copy of "foo.dart" with substitution
s/foo/bar/g, etc - and same for each library.
And in which package will you put all those?

In a recent thread, Eric argued against the idea of static id for a closure
on a basis that the feature belongs to reflection (not to runtime per se).
But if we apply same logic here, this "configured imports" idea looks like
a roundabout and complicated way to implant pieces of *configuration* into
the program, so similar argument can be made: the thing doesn't belong in a
program, it should be part of some config file, or metadata, or something.

Looking at it from different perspective: if library is intended for use
only on android platform, wouldn't it be logical for this program to
declare this fact explicitly (e.g. via some pragma, or "library foo for
*platform*" etc)? Or maybe the whole package deals with android - it can
say "for android only" in pubspec? There are several ways to proceed from
here. (I'm sure this option was considered. What exactly was found wrong
with it?)

[Filipe Morgado]

I like the proposal... and I don't think we'll be repeating ourselves that much. Even so, DRY is no problem here.

['Erik Ernst' via Dart Misc]

Post by tatumizer-v0.2
If you consider Android vs iOS, each coming with a large set of libraries,
// foo.dart
export 'foo_interface.dart'
if (dart.library.ios) 'foo_ios.dart'
if (dart.library.android) 'foo_android.dart';
So, a lot of tiny dart files, none of which actually looking like a
program. Rather, they are pieces of configuration. And they are not DRY by
any measure: "bar.dart" will be a copy of "foo.dart" with substitution
s/foo/bar/g, etc - and same for each library.
And in which package will you put all those?
In a recent thread, Eric argued against the idea of static id for a
closure on a basis that the

(that might be me, in which case it's with a 'k' ;)

Post by tatumizer-v0.2
feature belongs to reflection (not to runtime per se). But if we apply
same logic here, this "configured imports" idea looks like a roundabout and
complicated way to implant pieces of *configuration* into the program, so
similar argument can be made: the thing doesn't belong in a program, it
should be part of some config file, or metadata, or something.

If you have a lot of tiny libraries just containing a configurable 'export'
then you are implicitly turning all the importers (of one or more of those
tiny libraries) into configuration dependent code: If they really get to
import different bodies of code depending on the configuration then the
meaning of every tiny snippet of code in those importers might be different
in different configurations. For instance, the occurrence of `x` in the
body of a method could resolve to a tear-off of an inherited method in one
configuration, and it might denote a top-level const variable of type `int`
in another configuration. It might even work, somehow. ;-) In this case
you'd need to have the complete list of possible interpretations of every
snippet of code in mind whenever you are trying to read the code in those
importers, and of course even more when you are modifying existing code or
writing new code.

I've stubbornly argued that this complicates the software, and it would be
better to encapsulate the configuration dependencies and have the rest of
the software use configuration dependent features via a well-defined,
explicit, configuration independent interface, and checking statically that
it is used and implemented correctly, with the strictness-vs-soundness
trade-off that we know from the rest of the language.

The obvious alternative is that we could compare the imported interfaces
and make sure they are "sufficiently similar". But I never liked
introducing structural type equivalence into Dart, because it is a whole
new not-quite-identical copy of the type system---hardly a way to make
things simple. That's the reason why I've proposed not importing types
configurably; all types visible to "configuration independent code" should
be strictly configuration independent (otherwise that code ain't
configuration independent at all), and configuration dependent code should
then conform to those types (it's perfectly OK for a configuration
dependent library to import configuration independent ones, so it can
easily get to see the relevant types).

So I'm much less happy about a configuration dependent _export_ than I am
about a configuration dependent _import_ which is used to provide a
configuration independent set of features to the configuration independent
domain. It's more verbose to provide a configuration independent interface
and to tie an existing implementation up to it, but I believe that those
fewer keystrokes could end up being an expensive short-cut in perspective.

Looking at it from different perspective: if library is intended for use

Post by tatumizer-v0.2
only on android platform, wouldn't it be logical for this program to
declare this fact explicitly (e.g. via some pragma, or "library foo for
*platform*" etc)? Or maybe the whole package deals with android - it can
say "for android only" in pubspec? There are several ways to proceed from
here. (I'm sure this option was considered. What exactly was found wrong
with it?)

That is quite interesting! ..but configurable imports might as well be used
for non-platform variants, e.g., software product lines. I don't think that
it would be possible to make all the configuration related choices based on
information on the form "this library inherently cannot be used here".

best regards,
--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

[Alex Tatumizer]

@Erik, I'm sorry for repeatedly misspelling your name.
*..but configurable imports might as well be used for non-platform
variants, e.g., software product linesI don't think that it would be
possible to make all the configuration related choices based on information
on the form "this library inherently cannot be used here".*

Suppose we can add platform annotations at the level of package: when
package knows it can be used only on android, it says so in pubspec. Next,
when pub loads all dependencies for my projects, it generates .packages
file, and copies "applicable to android only" annotation there (syntax can
be figured out).
However, this is not the end of a story: .packages file can be edited by
programmer to override locations AND platform annotations. At this point
you can specify non-standard "platforms" and environments.

I'm not sure there's any other way to handle "general case" of non-standard
scenarios, even with proposed conditional imports/exports: with hardcoded
imports, you don't have any way to change these imports in the packages you
use (you can change import in your own package only).

Here's an example. In Java, you can replace jar file with another one, and
if this "another one" implements same classes in compatible manner, ALL
other classes pick up this implementation - all of them, regardless of
whether they are your classes or 3rd party's. Java provides general
solution for this without even mentioning it in language spec. You write a
build script, construct classpath depending on conditions - done. AFAICS,
current proposal doesn't have this kind of generality

['Erik Ernst' via Dart Misc]

Post by Alex Tatumizer
@Erik, I'm sorry for repeatedly misspelling your name.

Repeatedly no problem. ;-)

Post by Alex Tatumizer
*..but configurable imports might as well be used for non-platform
variants, e.g., software product linesI don't think that it would be
possible to make all the configuration related choices based on information
on the form "this library inherently cannot be used here".*
Suppose we can add platform annotations at the level of package: when
package knows it can be used only on android, it says so in pubspec. Next,
when pub loads all dependencies for my projects, it generates .packages
file, and copies "applicable to android only" annotation there (syntax can
be figured out).
However, this is not the end of a story: .packages file can be edited by
programmer to override locations AND platform annotations. At this point
you can specify non-standard "platforms" and environments.

I think this might be the core of a mechanism for redistributing the
configurable imports, such that the package itself (in its 'pubspec.yaml')
could provide the information needed in the configurable imports that
clients would otherwise have to write. Maybe you would be able to simply
write "import 'dart:html';" and then you'll effectively have a configurable
import right there, because 'dart:html' resolves to different libraries on
different platforms.

But it does have the opposite rationales than the ones that I'm usually
looking for:
- It would make a large amount of code configuration dependent, even
though you cannot see that in the syntax of the affected libraries.
- There is a work-around: if you create a configuration independent
'html.dart' library that configurably imports whatever it takes (e.g.,
'dart:html' on the browser) and offers the services from there under a
configuration independent interface, then the clients could as well import
'html.dart' and then they'd be genuinely configuration independent.
- It doesn't really cover things like software product lines and other
kinds of software configuration management where a concept like "[virtual]
platform" would be very artificial, so we would still need a general
mechanism whereby configurable imports specify the list of potentially
imported libraries and some selection criteria.

I'm not sure there's any other way to handle "general case" of non-standard

Post by Alex Tatumizer
scenarios, even with proposed conditional imports/exports: with hardcoded
imports, you don't have any way to change these imports in the packages you
use (you can change import in your own package only).

I'd certainly expect the environment to be available to the entire program.
If you are using a library that contains configurable imports then they'd
be guided by that environment. If such a configurable import is guided by
the platform then the choice would presumably be forced, and the client
should be happy with the choice of platform that the depended-upon package
makes, and if it is more like "include_feature_F" then it would presumably
be guided by a `-Dinclude_feature_F` argument to the compiler, and it might
affect any number of libraries/packages that know about this feature.

So, even though you wouldn't in general be able to edit other packages, it
should certainly be possible to have configurable imports in them which are
making predictable and useful configuration related choices for you.

Here's an example. In Java, you can replace jar file with another one, and

Post by Alex Tatumizer
if this "another one" implements same classes in compatible manner, ALL
other classes pick up this implementation - all of them, regardless of
whether they are your classes or 3rd party's. Java provides general
solution for this without even mentioning it in language spec. You write a
build script, construct classpath depending on conditions - done. AFAICS,
current proposal doesn't have this kind of generality

Java's setup includes class loaders and a bunch of other highly complex
features. Dart's import mechanism was designed to be much simpler, and that
was not an accident. Configurable imports is a step in the opposite
direction (introducing more flexibility, power, and complexity), but we
probably don't want anything which is even nearly as contorted as Java. ;)

best regards,
--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

[tatumizer-v0.2]

Upon some head-scratching, I'd like to (slightly) modify the idea of using
.packages file for configurable import.
Here is take 2: no changes in format of .packages are necessary, no "ifs"
or anything. Just plain redirection.
E.g. .packages can contain the line
http.dart:http_server.dart
or
http.dart:http_browser.dart
but not both. In simple cases, you can switch between the two by editing
file manually (by commenting/uncommenting certain lines), but generally
it's not a very good idea. Better way is to have .packages file generated
by your own build.dart script, which gets automatically invoked when you
compile/run a program. E.g. build.dart can support naming conventions
(generating suffix _android vs _ios) or logic of any kind.

I think it's important to keep data files clean. Any "if" appearing in
config file will turn data format into ad-hoc programming language, which
is a bottomless pit.

(Some notes in dart tutorial indicate that build.dart was kind of
deprecated in favor of transformers This was a mistake IMO. Transformers
didn't live up to expectations anyway).

[Günter Zöchbauer]

Post by tatumizer-v0.2
Upon some head-scratching, I'd like to (slightly) modify the idea of using
.packages file for configurable import.
Here is take 2: no changes in format of .packages are necessary, no "ifs"
or anything. Just plain redirection.
E.g. .packages can contain the line
http.dart:http_server.dart
or
http.dart:http_browser.dart
but not both. In simple cases, you can switch between the two by editing
file manually (by commenting/uncommenting certain lines), but generally
it's not a very good idea. Better way is to have .packages file generated
by your own build.dart script, which gets automatically invoked when you
compile/run a program. E.g. build.dart can support naming conventions
(generating suffix _android vs _ios) or logic of any kind.
I think it's important to keep data files clean. Any "if" appearing in
config file will turn data format into ad-hoc programming language, which
is a bottomless pit.
(Some notes in dart tutorial indicate that build.dart was kind of
deprecated in favor of transformers This was a mistake IMO. Transformers
didn't live up to expectations anyway).

`build.dart` was a DartEditor feature. It seems to get a revival though
because code-generation becomes more popular. See
Alexandres https://pub.dartlang.org/packages/build_system for example.

['Bob Nystrom' via Dart Misc]

In simple cases, you can switch between the two by editing file manually
(by commenting/uncommenting certain lines), but generally it's not a very
good idea. Better way is to have .packages file generated by your own
build.dart script, which gets automatically invoked when you compile/run a
program. E.g. build.dart can support naming conventions (generating suffix
_android vs _ios) or logic of any kind.

Pub would step on your changes since it expects to be able to write the
file. Also, there's a circularity problem: you generally need to have a
.packages already before you can run build.dart, so it would be weird if it
also modified or wrote it.

This also doesn't play nice with transitive dependencies. If your app uses
foo, which uses bar, which uses http, how do you know that you need to
configure this mysterious http package in your build.dart file?

I think it's important to keep data files clean. Any "if" appearing in

config file will turn data format into ad-hoc programming language, which
is a bottomless pit.

Yeah. I agree. If you want logic, it belongs in the language proper, which
is why I've always been in favor of proposals that handle this at the
language level.

(Some notes in dart tutorial indicate that build.dart was kind of
deprecated in favor of transformers This was a mistake IMO. Transformers
didn't live up to expectations anyway).

They are rarely used for what they're designed for. :(

We designed them for things like SASS->CSS or simple textual
transformations. Then, because web frameworks need compile time
metaprogramming and Dart didn't really have any other solution for that,
people started using them for big static analysis code transformation
stuff. That wasn't what transformers were designed for, and has never been
a good fit.

I agree that some kind of code generation is a better path. Well, an ever
*better* path would be to have a real metaprogramming story in the language
that plays nice with offline static compilation, but until we get that, I
think codegen makes more sense for many cases.

Cheers!

- bob

[tatumizer-v0.2]

Post by 'Bob Nystrom' via Dart Misc
This also doesn't play nice with transitive dependencies. If your app

uses foo, which uses bar, which uses http, how do you know that you need to
configure this mysterious http package in your build.dart file?

There are several ways to address this. The simplest is to add "virtual
dependency" in pubspec. Now these dependencies won't be that mysterious.
Whether pub can set up meaningful default for virtual dependencies is an
open issue. The repertoire of different platform-specific implementations
of same library will be limited anyway, maybe we can agree on simple naming
conventions to be able to do that. If figuring out the default
automatically is impossible, then dependency will remain unresolved - then
you get error message from compiler. So what? The underlying
implementations of 2 libraries are already loaded, so you go ahead and fill
the blank space in ".packages" file.

This way, we reformulate the problem in more familiar terms (resolving
external dependencies). Simple, flexible and conforms with "All problems in
computer science can be solved by another level of indirection" :)

In any case, even with "conditional import", it would be difficult to
completely hide these "conditional dependencies". They need special
attention (e.g. semantic versioning becomes moot; conditions of import
might not be exactly what application wants; etc.)

['Bob Nystrom' via Dart Misc]

On Fri, Sep 18, 2015 at 9:37 PM, George Moschovitis <

Post by 'Bob Nystrom' via Dart Misc
So that every place that needs to log can do so in a platform-appropriate

Post by 'Bob Nystrom' via Dart Misc
// logging.dart
export 'logging_interface.dart'
if (dart.library.html) 'logging_web.dart'
if (dart.library.io) 'logging_console.dart';
import 'logging.dart';

Yeah, I was always curious why you where concentrating on import examples,
where actually export will be used in practice.
Perhaps you should add this clarification in the DEP.

I use import mostly because it's the more familiar directive. Also, I think
in practice, the different configurations will tend to share a lot of code.
Given that, I think the pattern will less likely be:

// logging.dart
export 'logging_interface.dart'
if (dart.library.html) 'logging_web.dart'
if (dart.library.io) 'logging_console.dart';


And more likely be:

// logging.dart
import 'logging_impl_interface.dart'
if (dart.library.html) 'logging_impl_web.dart'
if (dart.library.io) 'logging_impl_console.dart';

log(message) {
// config-independent stuff...

logImplShowMessage(message);
}

// lots more config-independent code...


In other words, I expect a configuration-independent library to import the
configuration-specific parts of its implementation. You could have a
library where the whole implementation is configuration-specific, at which
point the public library is reduced to nothing but an export, but I think
that won't be common.

Cheers!

- bob

[George Moschovitis]

You could have a library where the whole implementation is
configuration-specific, at which point the public library is reduced to
nothing but an export, but I think that won't be common.

On the contrary, I expect *that* to be the common case. E.g., I want to
import 'websocket.dart' in my code, don't want to add any ifs etc.

-g.

[Günter Zöchbauer]

You could have a library where the whole implementation is

configuration-specific, at which point the public library is reduced to
nothing but an export, but I think that won't be common.

On the contrary, I expect *that* to be the common case. E.g., I want to
import 'websocket.dart' in my code, don't want to add any ifs etc.

For package users it will be this way. What Bob said is for developers of
packages containing several platform-specific implementations.

-g.

['Bob Nystrom' via Dart Misc]

On Mon, Sep 21, 2015 at 12:28 PM, George Moschovitis <

You could have a library where the whole implementation is

configuration-specific, at which point the public library is reduced to
nothing but an export, but I think that won't be common.

On the contrary, I expect *that* to be the common case. E.g., I want to
import 'websocket.dart' in my code, don't want to add any ifs etc.

That is what you'll do, but the *implementation *of websocket.dart will be
an actual library containing all of the shared, configuration-independent
code. It will then delegate just the config-specific bits to a
configuration-specific import it uses internally.

Cheers!

- bob

[George Moschovitis]

OK, we are saying the same thing. Love it :)

-g.

That is what you'll do, but the *implementation *of websocket.dart will be

Post by 'Bob Nystrom' via Dart Misc
an actual library containing all of the shared, configuration-independent
code. It will then delegate just the config-specific bits to a
configuration-specific import it uses internally.

['Bob Nystrom' via Dart Misc]

On Mon, Sep 21, 2015 at 1:37 PM, George Moschovitis <

Post by George Moschovitis
OK, we are saying the same thing. Love it :)

\o/