[dart-misc] What is up with quiver?

[Alec Henninger]

It looked like quiver was being split into multiple packages under
github.com/QuiverDart, but they haven't seen a lot of activity, and
google/quiver-dart seems to be the only one getting updates. They've also
both diverged, with some fixes only under QuiverDart/* and some fixes only
in google/quiver-dart.

I'm not complaining; I empathize with everyone who is busy with a number of
things dart. But I am wondering, what's the game plan? Is the ultimate
intention still to split it up into multiple packages? Or are there too
many projects still relying on quiver-dart? Should new projects depend on
quiver-dart, or the individual packages under QuiverDart/* ?

Thanks!

['Chris Bracken' via Dart Misc]

+Yegor Jbanov <***@google.com>

Actually we've been having the same discussion amongst ourselves as well
and are fairly interested in getting people's feedback and hearing your
preference.

We got some fairly strong feedback last year in favour of breaking Quiver
up into smaller, more focused packages. Quiver had been pretty stable and
1.0 seemed like a reasonable time to do this, so we blasted away some of
the deprecated dirt and grime from package:quiver and pushed the
sub-packages.

It turns out that internally at Google, developers very strongly preferred
the single monolithic package. There's a small amount of extra cognitive
work to figure out whether a given bit of functionality lives in
quiver_this or quiver_that, and either way, when building for the web,
tree-shaking kills off the bits you don't use. On the VM, you only pull in
what you import. The end result is that at Google, we use package:quiver
and that's where we see most PRs for fixes.

There's a third (waffly) possibility, which is to have package:quiver just
re-export the sub-packages so we're at least back to a single codebase.

As I say, we'd love to hear your preferences. What do you think?

Cheers,
Chris

Post by Alec Henninger
It looked like quiver was being split into multiple packages under
github.com/QuiverDart, but they haven't seen a lot of activity, and
google/quiver-dart seems to be the only one getting updates. They've also
both diverged, with some fixes only under QuiverDart/* and some fixes only
in google/quiver-dart.
I'm not complaining; I empathize with everyone who is busy with a number
of things dart. But I am wondering, what's the game plan? Is the ultimate
intention still to split it up into multiple packages? Or are there too
many projects still relying on quiver-dart? Should new projects depend on
quiver-dart, or the individual packages under QuiverDart/* ?
Thanks!
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[DoHyung Kim]

To me, it's ok either way. But I found it is far clear to figure out what
are available when split into smaller focused chunks. That is, it's more
approachable.
I think Googlers' preference of single package is somewaht similar to the
situation with Guava in Java. But even in the case with Guava, I feel it's
difficult to figure out what're inside before digging into and being
accustomed to it.

Anyway, I hope that it settles either way as soon as possible.

Regards,
DH

+Yegor Jbanov <javascript:>
Actually we've been having the same discussion amongst ourselves as well
and are fairly interested in getting people's feedback and hearing your
preference.
We got some fairly strong feedback last year in favour of breaking Quiver
up into smaller, more focused packages. Quiver had been pretty stable and
1.0 seemed like a reasonable time to do this, so we blasted away some of
the deprecated dirt and grime from package:quiver and pushed the
sub-packages.
It turns out that internally at Google, developers very strongly preferred
the single monolithic package. There's a small amount of extra cognitive
work to figure out whether a given bit of functionality lives in
quiver_this or quiver_that, and either way, when building for the web,
tree-shaking kills off the bits you don't use. On the VM, you only pull in
what you import. The end result is that at Google, we use package:quiver
and that's where we see most PRs for fixes.
There's a third (waffly) possibility, which is to have package:quiver just
re-export the sub-packages so we're at least back to a single codebase.
As I say, we'd love to hear your preferences. What do you think?
Cheers,
Chris

Post by Alec Henninger
It looked like quiver was being split into multiple packages under
github.com/QuiverDart, but they haven't seen a lot of activity, and
google/quiver-dart seems to be the only one getting updates. They've also
both diverged, with some fixes only under QuiverDart/* and some fixes only
in google/quiver-dart.
I'm not complaining; I empathize with everyone who is busy with a number
of things dart. But I am wondering, what's the game plan? Is the ultimate
intention still to split it up into multiple packages? Or are there too
many projects still relying on quiver-dart? Should new projects depend on
quiver-dart, or the individual packages under QuiverDart/* ?
Thanks!
--
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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Alec Henninger]

There are merits to both approaches for sure so it's hard to go wrong, as
long as whichever approach used embraces its strengths. If I were in your
position, I would probably keep the monolith, for some of the reasons you
stated. I expect the effort in splitting it up, from both a quiver
developer and quiver consumer perspectives, would be effort not worth the
value.

The comparison to guava is natural. In practice I like that guava is one
package because it means I get a lot of high quality conveniences on my
classpath, easily discovered via my IDE. "I wonder if there's a guava way
to do this?" is a question I ask myself and pretty commonly get a great
answer just by searching types in my IDE. This experience translates
especially well to dart because of built in tree shaking. (On the other
hand, the jdk has more warts and holes compared to the dart sdk of course,
so guava has more opportunity to shine there.)

One downside I can see (in either strategy, really) is there is potential
for some redundancy between quiver and specialized packages like collection
and async. I expect it will take some discipline to keep quiver and these
packages distinct and non-overlapping. Perhaps new features should first be
considered in a specialized library before adding them to quiver. In any
case, some clear guidelines would be appreciated for contributors and
consumers alike.

Cheers!

Post by DoHyung Kim
To me, it's ok either way. But I found it is far clear to figure out what
are available when split into smaller focused chunks. That is, it's more
approachable.
I think Googlers' preference of single package is somewaht similar to the
situation with Guava in Java. But even in the case with Guava, I feel it's
difficult to figure out what're inside before digging into and being
accustomed to it.
Anyway, I hope that it settles either way as soon as possible.
Regards,
DH

Post by 'Chris Bracken' via Dart Misc
+Yegor Jbanov
Actually we've been having the same discussion amongst ourselves as well
and are fairly interested in getting people's feedback and hearing your
preference.
We got some fairly strong feedback last year in favour of breaking Quiver
up into smaller, more focused packages. Quiver had been pretty stable and
1.0 seemed like a reasonable time to do this, so we blasted away some of
the deprecated dirt and grime from package:quiver and pushed the
sub-packages.
It turns out that internally at Google, developers very strongly
preferred the single monolithic package. There's a small amount of extra
cognitive work to figure out whether a given bit of functionality lives in
quiver_this or quiver_that, and either way, when building for the web,
tree-shaking kills off the bits you don't use. On the VM, you only pull in
what you import. The end result is that at Google, we use package:quiver
and that's where we see most PRs for fixes.
There's a third (waffly) possibility, which is to have package:quiver
just re-export the sub-packages so we're at least back to a single codebase.
As I say, we'd love to hear your preferences. What do you think?
Cheers,
Chris

It looked like quiver was being split into multiple packages under

Post by 'Chris Bracken' via Dart Misc

Post by Alec Henninger
github.com/QuiverDart, but they haven't seen a lot of activity, and
google/quiver-dart seems to be the only one getting updates. They've also
both diverged, with some fixes only under QuiverDart/* and some fixes only
in google/quiver-dart.
I'm not complaining; I empathize with everyone who is busy with a number
of things dart. But I am wondering, what's the game plan? Is the ultimate
intention still to split it up into multiple packages? Or are there too
many projects still relying on quiver-dart? Should new projects depend on
quiver-dart, or the individual packages under QuiverDart/* ?
Thanks!
--
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
---
You received this message because you are subscribed to the Google
Groups "Dart Misc" group.

To unsubscribe from this group and stop receiving emails from it, send an
--

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
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[tatumizer-v0.2]

It's not a problem of monolithic quiver or partitioned quiver. Either way,
the stuff is not discoverable.
E.g. there's no link to quiver from dart collection library
<https://api.dartlang.org/stable/1.18.1/dart-collection/dart-collection-library.html>
So how people are supposed to find out about it? E.g. try googling "dart
collection library extension".
If you don't know about quiver in advance, you will never find it.

In many cases, you don't even know how to verbalize what you are looking
for specifically - just want to find out what types of collections are
there, somewhere -
you are *learning* the stuff from APIs (including concepts and
terminology). There are things you would gladly use if you knew they
existed.

Can dart maintain a curated, categorized by topic, list of libraries in a
well-known location? Possibly linked from core dartdoc?

[Matthew Butler]

I agree on the discoverability issue, but I highly disagree about linking
to packages from the dart core libraries. Even a package curated by Google,
is an external package subject to depreciation or surpassed by a superior
package. In either case, the Dart core libraries should document themselves
and not suggest other 3rd party packages.

Discoverability is something that needs another way to be addressed, but
unfortunately there's no simple solution for it. Maintaining a list of
"awesome packages" has been done
(eg https://github.com/yissachar/awesome-dart ). Is it Google/Dart team's
responsibility to maintain their own list on the dartlang page or some
other location to say what is awesome or what is a project worth listing?
Is it there responsibility to try each one and vouch for it? Or ensure it's
still active/maintained in two years time?
By putting any recommendation on the dart lang page, they are effectively
giving it their stamp of approval, regardless of how many disclaimers are
put on the page. Once a package goes sour (left-pad), then it reflects on
Dart itself.

Best thing for discoverability is people using packages, and talking about
it. Be it social media posts (I have a lot of Dart devs I follow on G+),
blog posts and more. If the writing is good enough it may even be
referenced/featured by the Dart official accounts (Twitter, G+ and Dart
news blog).

Just my $0.02CAD

Matt

Post by tatumizer-v0.2
It's not a problem of monolithic quiver or partitioned quiver. Either way,
the stuff is not discoverable.
E.g. there's no link to quiver from dart collection library
<https://api.dartlang.org/stable/1.18.1/dart-collection/dart-collection-library.html>
So how people are supposed to find out about it? E.g. try googling "dart
collection library extension".
If you don't know about quiver in advance, you will never find it.
In many cases, you don't even know how to verbalize what you are looking
for specifically - just want to find out what types of collections are
there, somewhere -
you are *learning* the stuff from APIs (including concepts and
terminology). There are things you would gladly use if you knew they
existed.
Can dart maintain a curated, categorized by topic, list of libraries in a
well-known location? Possibly linked from core dartdoc?

[tatumizer-v0.2]

In either case, the Dart core libraries should document themselves and

not suggest other 3rd party packages
They suggest 3rd part packages already, they just don't do it consistently.
E.g. go
to https://api.dartlang.org/stable/1.18.1/dart-collection/ListBase-class.html
and find the phrase:
" or, preferably, use DelegatingList from
"package:collection/wrappers.dart" instead".

True, the location of the package is a bit off, but you can google it - and
you will find it ... in quiver!!!.

Now, suppose dartdoc omits the reference. Along with it, "preferable"
recommendation is gone. As a result, you get stuck with subpar ListBase,
b/c you know nothing about by far superior DelagatingList That is, your
principles are making you poorer.

How did this all happen? My speculation is that dart noticed that his
libraries are growing in size by leaps and bounds, and decided to
arbitrarily split them into core part and extension part, which, for some
reason, was codenamed "quiver".

My revised suggestion: *for library extensions*, have a curated list,
referred to from main page via "see also" reference . By "curated", I mean
"curated by dart proper", not by some random dude with too much time on his
hands.

How about that?

['Lasse R.H. Nielsen' via Dart Misc]

Post by Matthew Butler

In either case, the Dart core libraries should document themselves and

not suggest other 3rd party packages
They suggest 3rd part packages already, they just don't do it
consistently. E.g. go to https://api.dartlang.org/
stable/1.18.1/dart-collection/ListBase-class.html
" or, preferably, use DelegatingList from "package:collection/wrappers.dart"
instead".

That's not a third-party package. It's actually a first-party package (I
wrote both the comment and the class). It's the package where we put things
we would have put in the dart:collection library if it wasn't because we
didn't want to make it too big.

Post by Matthew Butler
True, the location of the package is a bit off, but you can google it -
and you will find it ... in quiver!!!.

Or you can find it where it says it is:

https://pub.dartlang.org/packages/collection
https://www.dartdocs.org/documentation/collection/1.9.0/dart.pkg.collection.wrappers/DelegatingList-class.html

:)

Post by Matthew Butler
My revised suggestion: *for library extensions*, have a curated list,
referred to from main page via "see also" reference . By "curated", I mean
"curated by dart proper", not by some random dude with too much time on his
hands.
How about that?

Try looking at package:collection, package:async, package:convert,
package:isolate and package:typed_data. They might be what you want.

How "curated" you think they are might depend on what you expect :)

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[tatumizer-v0.2]

Oh I see! Dart has 2 DelegatingLists, one in collection.wrappers, another -
in quiver A bit of healthy competition never hurts (especially between 2
wings of the same team). Core collection doc refers to the former, but when
you go google it, unless you are very pedantic with your choice of
keywords, you see the latter (due to superior Search Optimization
technique).

Which means, in another thread, I just sent people to the wrong
DelegatingList???. That's embarrassing!

Now I understand why fuchsia needs an AI bot
<https://fuchsia.googlesource.com/modular/> to deal with the problem.

[tatumizer-v0.2]

Spent better part of the day conducting comprehensive comparative study of
DelegatingList in quiver_collection vs DelegatingList in package:collection.

Two basic findings:

1. Two versions of DelegatingList have something in common - e.g. they
agree on the name: each calls itself "DelegatingList". This is good news.
2. However, methods of implementation are radically different: one passes
the underlying list in constructor, another makes use of "delegate"
property.
Due to Search Optimization, quiver version was the starting point of my
study. I admit that seeing "delegate" property was a bit unexpected to me,
so I first went "WTF"? and then "WOW", and still oscillating between these
2 extremes, like pendulum.

In contrast, reading collection.wrapper.DelegatingList initially left me
underwhelmed. On the surface, Implementation chooses well-beaten path: it
accepts user's list in constructor. Excuse me? Constructor??? Only after
third read did I finally notice the fine nuance: this is not just a
faceless "constructor", this is "const" constructor!!! WOW! "Delegate"
version can't match it: no const for you bro.

Overall, I was equally impressed by both versions: despite all differences
in style, each provides much food for thought. Time well-spent, both for
authors and the reviewer.

['Yegor Jbanov' via Dart Misc]

Quiver will remain a strictly 3rd-party package even though the maintainers
are googlers. We'll need to address the discoverability issue in a way that
does not involve an endorsement from the Dart team.

As Chris said the split didn't provide much value to internal users, but
Google has its own approach
<https://qconsf.com/sf2010/dl/qcon-sanfran-2010/slides/AshishKumar_DevelopingProductsattheSpeedandScaleofGoogle.pdf>
to building software, so we're soliciting feedback from the larger
community. So far, aside from discoverability, I'm not seeing any strong
preferences in the comments.

I like the idea of having separate packages re-exported through
package:quiver. So if we have package:quiver_collection/collection.dart we
also have package:quiver/collection.dart. However, to simplify the
development process I think the repositories could be merged. There's no
requirement for having one pubspec.yaml per git repository. Each
sub-package will increment its version independently. However,
package:quiver will need to increment its version with any sub-package
atomically with every commit. I'm also thinking the dependencies of
package:quiver should be locked to precise versions of the sub-packages (no
version ranges).

Post by Matthew Butler
I agree on the discoverability issue, but I highly disagree about linking
to packages from the dart core libraries. Even a package curated by Google,
is an external package subject to depreciation or surpassed by a superior
package. In either case, the Dart core libraries should document themselves
and not suggest other 3rd party packages.
Discoverability is something that needs another way to be addressed, but
unfortunately there's no simple solution for it. Maintaining a list of
"awesome packages" has been done (eg
https://github.com/yissachar/awesome-dart ). Is it Google/Dart team's
responsibility to maintain their own list on the dartlang page or some
other location to say what is awesome or what is a project worth listing?
Is it there responsibility to try each one and vouch for it? Or ensure it's
still active/maintained in two years time?
By putting any recommendation on the dart lang page, they are effectively
giving it their stamp of approval, regardless of how many disclaimers are
put on the page. Once a package goes sour (left-pad), then it reflects on
Dart itself.
Best thing for discoverability is people using packages, and talking about
it. Be it social media posts (I have a lot of Dart devs I follow on G+),
blog posts and more. If the writing is good enough it may even be
referenced/featured by the Dart official accounts (Twitter, G+ and Dart
news blog).
Just my $0.02CAD
Matt

Post by tatumizer-v0.2
It's not a problem of monolithic quiver or partitioned quiver. Either
way, the stuff is not discoverable.
E.g. there's no link to quiver from dart collection library
<https://api.dartlang.org/stable/1.18.1/dart-collection/dart-collection-library.html>
So how people are supposed to find out about it? E.g. try googling "dart
collection library extension".
If you don't know about quiver in advance, you will never find it.
In many cases, you don't even know how to verbalize what you are looking
for specifically - just want to find out what types of collections are
there, somewhere -
you are *learning* the stuff from APIs (including concepts and
terminology). There are things you would gladly use if you knew they
existed.
Can dart maintain a curated, categorized by topic, list of libraries in
a well-known location? Possibly linked from core dartdoc?

[tatumizer-v0.2]

Fine, another idea (I have plenty): in quiver submodules, add subtitles
like "dart collection library extension".
Then let google discover it. User will be instructed to google for
extensions using exact subtitle.
Somebody else will be able to write other extensions, with same subtitle.

Then use similar pattern to subtitle other dart resources. Provide a
"subtitle guide" in a visible place
How about that?