[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

On Thu, Nov 9, 2017 at 12:11 AM, Ted Kremenek <kremenek at apple.com> wrote:

>
>
> On Nov 8, 2017, at 12:08 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
>
>
>
> On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>>
>> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>>
>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I do not agree with Ted that only a few projects should be ranked,
>> everyone, as it is in npm should be available. Only be graded according to
>> recommendations.
>>
>>
>> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
>>
>>
>> Clearly I’m double confused.  That meant to read “I’m not sure what
>> comments of mine *you* are referring to”.
>>
>> I fully support having a broad spectrum of libraries that the community
>> builds and uses.  Any library that we decide to make part of “core Swift” —
>> IMHO at a mature point in a library’s evolution — would need to have high
>> value to the majority of the community and would need to feel solid enough
>> that we can lock it in for both source and binary compatibility, high
>> quality of implementation with sustained maintenance, etc.
>>
>
> i mean I don’t think these approaches are incompatible. The “swift core”
> could just make the process of independent libraries getting started
> easier. Like right now there’s really no place to say “hey I just started a
> library project for X, and anyone who wants to be involved should
> contribute at Y github repo where it lives right now”. I’ve tried sending
> that on this list before and it didn’t really work because mailing lists
> aren’t really a good medium for that and no one wants the swift-evolution
> list getting clogged with project-specific messages most people don’t care
> about.
>
>
> These are great points.
>
> FWIW, I’m getting optimistic about moving to a forum soon.  Would you
> expect that a forum could provide a better vehicle than a mailing list to
> arrange communication and interest within the community around building
> libraries?  Not just doing shout outs for projects, but also doing possible
> API design review, etc.?
>

this forum thing has been talked about for almost a year now and i am for
real convinced it will never happen tbh. if it did, it would probably be
more conducive but ultimately it comes down to the number of people
interested because right now it’s like there’s only a handful of people on
this list who want to write open source libraries (or really anything
without a graphical interface since it’s basically 90% ios devs here). will
a forum encourage more people to get involved in the language? maybe, for
me it took a really long time to actually sign up for this mailing list and
talk in it because mailing lists are just not easy to get involved in


>
> As an analogy, within Apple we have various mailing lists to review APIs,
> which is one mechanism used for different teams to co-review newly proposed
> APIs and consider how they compose together with other APIs.  It’s not
> always perfect, but it does help facilitate a culture of API review so that
> various APIs can be considered together and part of the same (or
> compatible) design philosophies.
>
> One of the things that resonated to me from Dave DeLong’s proposal was a
> sense about having a set of libraries that are well-considered and their
> efforts coordinated.  While the coordination pitched in Dave’s proposal was
> about a focused effort on a particular set of libraries/features,
> coordination can also take the form of having a community that cares about
> building good APIs and can constructively discuss them.  This can be done
> while also completely factoring out whether or not those APIs are part of
> “core Swift”.  Further, shared API review wouldn’t necessarily be about
> making actual decisions — which is the case of swift-evolution when
> evaluating language and standard library changes — but offering advice.
> Fundamentally the library author still stays in control of their library
> and APIs, but the community could help in shaping up the gestalt of what
> are considered well-crafted Swift APIs in general.
>
> Of course the big difference here with this idea compared to Apple’s
> internal API review process is that for Apple the APIs it vends are
> intended to be shipped together, and thus they must work together.  In open
> source, however, efforts on various libraries are often (usually?)
> independent.  Projects are usually created independently by different
> authors, and while it may be desirable for APIs from various libraries to
> feel natural to work with together, it’s not a requirement on their
> construction in general.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/9377589f/attachment.html>