[swift-evolution] Pitch: Replacement for FileHandle

[Zach Waldowski]

I can scarcely think of a less productive or more disrespectful thing to
do in a thread chock full of Apple engineers actively trying to help you
out. They're just humans, led by other humans. They can't divine the
presence of issues, just like they can't divine the priorities of
individual tasks without a holistic view of them. It would be far more
productive to figure out how we can get the changes we want done in a
public release of software as soon as possible. Everything else is
extraneous.


Best,

Zachary



On Thu, Feb 16, 2017, at 08:08 AM, Nick Keets via swift-evolution wrote:
> I’m going OT here, but even though I understand your reasons, you need
> to acknowledge that for developers the rational thing to do is to not
> file radars at all.
> 

> Any bug fix will get released at best a few months later and you can
> only actually take advantage of it a few years later (if you care
> about supporting older versions). More realistically we are talking
> 3-4 years of having to work around it (in the best cases). This is a
> lot of work (with almost zero feedback) for some far future benefit
> that probably will not even be relevant to you then.
> 

> So to me, when an Apple developer asks me to file a radar, it feels
> like they are asking me to do their job.
> 

> I’m sorry for the off-topic rant.

> 

> On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution <swift-
> evolution at swift.org> wrote:
>> 

>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka
>>> <cocoadev at charlessoft.com> wrote:
>>> 

>>>> On Feb 15, 2017, at 3:11 PM, Itai Ferber <iferber at apple.com> wrote:
>>>> 

>>>> FYI, Tony is the manager of the Foundation team. :) We care very
>>>> much about making sure that the experience of using our framework
>>>> is a positive one — the more Radars we get, the better we can
>>>> prioritize improving APIs that are not working as well as they
>>>> could be for our users. Even if the Radar gets duped to an existing
>>>> one, thats one more +1 for that Radar saying "this is a problem".
>>> Yeah I know, but it’s a frustrating experience, spending a half hour
>>> writing a detailed bug report (sometimes with videos attached to
>>> demonstrate the issue), just to effectively do the same thing as
>>> spending 5 seconds to hit the +1 button on most issue trackers you
>>> come across.
>>> 

>>> Especially since you never find out what happened to the original
>>> bug report. You can see if it’s open or closed, but did they fix it
>>> in some internal build? Did they decide it “behaves correctly?” Did
>>> somebody just skim your report, and mistakenly attach it to some
>>> other, unrelated issue? There’s no way to know.
>>>> I will search for your old Radar, but in any case, please do file a
>>>> new one about this, and about any other issues you have, because we
>>>> are indeed listening.
>>> I was pretty sure I'd submitted something way, way back in the misty
>>> days of yore, but I can’t find it. I’ve filed a couple of new ones:
>>> rdar://30543037 and rdar://30543133.
>>> 

>>> Charles

>>> 

>> 

>> Thanks for filing these.

>> 

>> Sometimes, for process reasons, we do indeed mark bugs as dupes of
>> other ones. Usually the polite thing to do is to dupe to the earliest
>> filed one. Sometimes this comes across with an appearance of not
>> caring to the filer of the new bug, but our intent is simply to
>> consolidate the reports we have so that we know that the issue is
>> serious.
>> 

>> We do not make API changes without going through a vigorous review
>> process, to avoid churn for the many clients above us. The flip side
>> is that this can take some time. I’m sure you understand that all
>> software engineering is about tradeoffs.
>> 

>> All of that said, we’ll take a look at these and see what
>> improvements we can make here. As I said, I’m not a fan of exception-
>> based API.
>> 

>> - Tony

>> 

>> 

>> 

>> _______________________________________________

>>  swift-evolution mailing list

>> swift-evolution at swift.org

>> https://lists.swift.org/mailman/listinfo/swift-evolution

>> 

> _________________________________________________

> swift-evolution mailing list

> swift-evolution at swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170216/c32a3a1b/attachment.html>