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]

+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

--
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 email to misc+uns...@dartlang.org.

[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

2016년 8월 9일 화요일 오전 2시 20분 39초 UTC+9, Chris Bracken 님의 말:

[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!

[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

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

[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?

 

 

  

[Yegor Jbanov]

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 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).

[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?

[Lasse R.H. Nielsen]

On Mon, Aug 15, 2016 at 9:11 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

> 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".

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.

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

:)

 

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 - l...@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 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.