|
Yes, also did that but my Forums label was already pretty busy! I think I need to turn off notifications for my forums label.
|
#
?
Feb 2, 2016 22:58
|
|
|
|
| # ? May 15, 2024 08:57 |
|
|
Doctor w-rw-rw- posted:Having taught programming before, the idea that the greater character count is more intimidating is absolutely preposterous. As a newcomer, I found Cocoa imposing and difficult to absorb. squidgee posted:For example, let's say I can't remember some particular method name. This happens to me all the time. I know that what I want exists, but I don't remember exactly what it's called. So how do I find the method name? 90% of the time, I use autocomplete to guess it on the first or second try. For instance, I know that the method for combining two strings is probably something like, "stringByCombiningWithAnotherString:," so I can punch in "stringBy" and stringByAppendingString: pops up. If stringByAppendingString: were renamed something terse like append:, I'd have to resort to the documentation to find it. It's even more terse than that: string1 + string2 
|
|
#
?
Feb 3, 2016 02:45
|
|
|
Toady posted:It's even more terse than that: string1 + string2 I knew someone was going to call me out on choosing that example, rather than addressing my point. 
|
|
#
?
Feb 3, 2016 02:53
|
|
|
I didn't mean to call you out. Your examples use Objective-C syntax, so I didn't know if you had used Swift.
|
|
#
?
Feb 3, 2016 03:16
|
|
|
Toady posted:I didn't mean to call you out. Your examples use Objective-C syntax, so I didn't know if you had used Swift. No worries. I actually have (started properly using it after Apple made good on open sourcing it). I really like it. Swift is a lovely modernization of Objective-C, and offers a nice balance between a scripting language and a low level language, with a bunch of other cool ideas thrown into the mix. Fingers crossed that it'll eventually offer a viable alternative to JS/Go/Rust on the server. nah thanks fucked around with this message at 06:46 on Feb 3, 2016 |
|
#
?
Feb 3, 2016 03:48
|
|
|
dizzywhip posted:You have to subscribe to the list to avoid the moderation queue: https://lists.swift.org/mailman/listinfo/swift-evolution Goddamn, they need to get control over the top-posting.
|
|
#
?
Feb 3, 2016 23:52
|
|
|
Dave Abrahams posted:No, really, I'm in the clarity team. Dave Abrahams posted:It is true that you can't know what context an API will be used in. Does that mean you should preemptively build in as many clarifications as possible in case the context leaves usage unclear? Dave Abrahams posted:IMO, no. 
|
|
#
?
Feb 4, 2016 00:03
|
|
|
In the spirirt of cherry picking for the sake of winning an argument. Since thats what those mailing list threads have devolved toquote:That's doable in a library, but by no means simple to code. So here I ericasadun agrees with us but I think also felt drowned out by that guy. People also keep mentioning context which to me is a very squishy term: Is it the surrounding 4 lines at the call site? Or ya know, the 1 line that matters, the line that actually calls the function. I think mathematical symbols would be even more clear. They are super well defined, and swift supports unicode operators. Does someone have a pet NLP project they want to incorporate into a compiler?
|
|
#
?
Feb 4, 2016 00:43
|
|
|
Kallikrates posted:Does someone have a pet NLP project they want to incorporate into a compiler? Larry Wall?
|
|
#
?
Feb 4, 2016 00:57
|
|
|
quote:
Are the apple script folks around?
|
|
#
?
Feb 4, 2016 00:59
|
|
|
Is the clarity team an actual team in the Swift project? If he sees it as an Us(me) vs them thing maybe that's why he can sit on those threads all day.
|
|
#
?
Feb 4, 2016 01:03
|
|
|
The comparison to Python 2/3 makes me chuckle a bit. Apple's control of Xcode means that there is a bright line between old and new ecosystems. You won't see Old Swift linger for very long in github repos or such; as soon as the new Xcode is out, people will update master and orphan an old tag for people stuck on Xcode N-1. Apple can, logistically, be extremely forceful in migrating people to the new version of the language, whether people are happy with the changes or not. I couldn't be more jealous.
|
|
#
?
Feb 4, 2016 01:13
|
|
|
Yeah I was saying in IRC I care, but not as much as the guys who are pro the changes. I'll probably hit the Migrator tool next(?) September(?) and try and forget these emails.
|
|
#
?
Feb 4, 2016 01:29
|
|
|
Your first experience with an open language design list is very special, hold onto this moment.
|
|
#
?
Feb 4, 2016 01:30
|
|
|
Kallikrates posted:Is the clarity team an actual team in the Swift project? If he sees it as an Us(me) vs them thing maybe that's why he can sit on those threads all day. No, there is not a literal clarity team. Dave is the lead of the (very small) standard library team. He has been teaching programming and working in language communities and standardization efforts for several decades, and he treats this kind of community communication as a very serious and almost sacred duty, to the point of being a major and unending distraction to his other work. Acting like he's being some sort of argumentative rear end in a top hat because you decided to have a Funny Internet Reaction and don't like what he's saying is pretty loving uncharitable.
|
|
#
?
Feb 4, 2016 01:52
|
|
|
Kallikrates posted:Is the clarity team an actual team in the Swift project? If he sees it as an Us(me) vs them thing maybe that's why he can sit on those threads all day. Dave Abrahams works at Apple as a language designer and technical lead on the standard library. He's a co-author of the proposal, so naturally he's heavily involved in the discussions. I'm not sure what is meant by "us vs. them thing," though. He was addressing each point raised like one would expect on a mailing list devoted to language design. I think some of you have the wrong impression. It's not about brevity versus clarity. What's being removed are redundant words that don't add clarity to the semantics. For example, addSubview(_:) is unchanged.
|
|
#
?
Feb 4, 2016 02:09
|
|
|
Where did I say he was being argumentative or that I don't like the API he's talking about? (I am not a fan for mostly other reasons) Just that I can't keep up with it or digest the comments fast enough. Maybe the evolution mailing list isn't for me with my other obligations, but we were directed to comment there on our thoughts. Maybe the proposals are more limited in scope than at first glance but often I see discussion end paraphrasing: "make a new proposal about that particular use/edge case with a solution". Not where I was going with that comment. I do think that bucketing involved parties in terms of Team X and Team Y is not helpful for topics that aren't black and white. I asked about the team because I think using the word Team invokes a win all lose all situation or us vs them. When reality is a discussion about opinions... If an individual isn't on Team Clarity where do they stand? Maybe that's just me. Kallikrates fucked around with this message at 02:27 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 02:17
|
|
|
"Team brevity" is just a snarky term someone used in the discussion.
|
|
#
?
Feb 4, 2016 02:24
|
|
|
rjmccall posted:No, there is not a literal clarity team. Dave is the lead of the (very small) standard library team. He has been teaching programming and working in language communities and standardization efforts for several decades, and he treats this kind of community communication as a very serious and almost sacred duty, to the point of being a major and unending distraction to his other work. Acting like he's being some sort of argumentative rear end in a top hat because you decided to have a Funny Internet Reaction and don't like what he's saying is pretty loving uncharitable. Who's calling him an rear end in a top hat? It's just funny that he created a straw man that was not only reasonable, but the way things have been. I do want my APIs to have a lot of information baked in to them. For the benefit of others, here's the non-cherry-picked quote: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008904.html posted:No, really, I'm in the clarity team. The same rules that go for English With that said, fighting for language purity in a way that worsens developer ergonomics is wrong and I disapprove of his viewpoint, because it is a) complex, b) can't be implemented perfectly, yet can't be undone without even more massive disruption, and c) is a problem for essentially the entire rest of Swift's life. And that's independent of my disagreement with his statements with regards to teachability and clarity. It seems to me that his head is much more grounded in the concepts, whereas I am a much more visual person that scans code more effectively when it has the words there, just like I do with Java. The whole proposal is creating ridiculously complex rules in comparison to the ridiculously simple rules to completely change...what? The aesthetics of the language to be more exactly like some embodiment of the language which the language does not itself meet? To distinguish it from the very thing it's fundamentally bridged with? In a way that must systematically apply not just once (to Cocoa), but again and again, to any code written in the very, very, established old way in the other language? After two years of working and working well? Congratulations, this is a problem that will last for the entire rest of Objective-C's life, which at this rate, is probably not going to die for a very, very long time. EDIT: word choice happen -> die Doctor w-rw-rw- fucked around with this message at 03:37 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 03:26
|
|
|
Toady posted:[Dave Abrahams] was addressing each point raised like one would expect on a mailing list devoted to language design. Yeah he very nicely addressed each point by spelling out his reasoning. That thread was basically "please don't do what you've been working on" which is a non-starter. There really wasn't a consensus / goal / proposal, and he could have easily just brushed it off. I still don't like the changes or agree with his reasoning, but at least they're open to listening to us moan. Also, it's loving hard to not sound argumentative on an email mailing list, even when you try. What an awful format.
|
|
#
?
Feb 4, 2016 03:34
|
|
|
Doctor w-rw-rw- posted:... To be fair new API in the various iOS Frameworks will probably not pass review if they create issues with these new guidelines. I would hope at least. It wouldn't be the first time some Swift rubbed off on Obj-C.
|
|
#
?
Feb 4, 2016 03:42
|
|
|
I can tell you, there's nothing worse than having people talk about your coworkers (who, thankfully, aren't top-posters) on Something Awful. I mean, except for having a neverending stream of people trying to make your proglang and/or API be horrible with their bad ideas.rjmccall posted:No, there is not a literal clarity team. Dave is the lead of the (very small) standard library team. He has been teaching programming and working in language communities and standardization efforts for several decades, and he treats this kind of community communication as a very serious and almost sacred duty, to the point of being a major and unending distraction to his other work. Acting like he's being some sort of argumentative rear end in a top hat because you decided to have a Funny Internet Reaction and don't like what he's saying is pretty loving uncharitable.
|
|
#
?
Feb 4, 2016 04:41
|
|
|
Doctor w-rw-rw- posted:With that said, fighting for language purity in a way that worsens developer ergonomics is wrong legibility is relative, get over yourself
|
|
#
?
Feb 4, 2016 05:27
|
|
|
sarehu: Well, goons have talked poo poo about my previous employer, previous CEO, and previous coworkers for a very long time. But perhaps it isn't the nicest thing and I've grown too thick a skin.Echo Video posted:legibility is relative, get over yourself -- I thought the humor would come off as slightly amusing rather than as a personal attack, and didn't intend to paint him as an rear end in a top hat, so for what it's worth, I'm sorry for that, rjmccall. To restate some of how I feel in a way that is hopefully less confrontational: I think that the naming change is a catastrophe. That this change doesn't seemed to be acknowledged as a bad thing is really unfortunate. It won't stop me from writing Objective-C code, but it will make me more wary of writing Swift for a while. I care a lot about this change, because it removes something I really like about Swift, which I think is also valuable across the board from newbies to veterans. It's not that I can't adapt, or won't (given time), it's that it will make the experience of developing with Swift significantly less fun, so if I'm going to be writing code day in and day out, I'm going to prefer the other thing for a long time. With so much inertia behind Swift at this point, I find unpleasant the prospect of having the language as I know and enjoy it altered so dramatically.
|
|
#
?
Feb 4, 2016 05:29
|
|
|
Doctor w-rw-rw- posted:Legibility is relative, which is why brevity, having fewer clues, is less clear to more people. right, legal contracts that are 60 pages long are the models of clarity I'm sorry you don't like this change, but calling it a catastrophe is overblown and really being a jerk towards everyone who has thought about this (guaranteed) a lot longer than you
|
|
#
?
Feb 4, 2016 05:50
|
|
|
tbh it's just kind of hard to take the 'catastrophe' pov seriously having spent years programming in each of cocoa, java and .net. they're directly comparable stacks - OO application development languages with large standard libraries and managed memory and so on, where you write a lot of business logic and classes with names like CustomersView or StoreNotifyingDelegate. objective-c has always been the standout for extremely verbose method names, which made some degree of sense as it had far less type-safety and worse tooling - but this is no longer the case. Swift has a real type system and automated refactoring capabilities, and we've been able to observe for years that these things are a sufficient or superior alternative to repeating type names in method names. you're talking about falling back to Hungarian notation, for goodness' sake.. people used to make the same arguments for why that would be a clearer way to code, and they haven't proven out. i'm not fond of the gerunds, which may just be unfamiliarity. on the jvm or clr the famous example would probably be yourInput.TrimCharacters(Whitespace) ..but of course the real function signature is String TrimCharacters(CharacterSet trimming). there's the exact same information as was present in stringByTrimmingCharactersInCharacterSet, in a form which is enforced by the compiler and which doesnt add noise to the process of scanning code for semantic correctness and functional comprehension. we should not be optimising for the authoring ability of beginners who aren't aware of docs or ide mechanisms. this stuff is read far more than its written, by developers who are neither novices nor experts. what's useful to them is a clear layout of the flow of well-named data between well-named operations; types are almost irrelevant. types are the thing the compiler checked, so you don't have to worry about those!
|
|
#
?
Feb 4, 2016 05:54
|
|
|
Every single person involved in Swift knew that opening language direction to public discussion was going to be like chewing glass. For none of them is this the first rodeo, and all these rodeos suck. They're a huge distraction and emotionally draining. And yet, because it leads to a marginally better language and much stronger ecosystem, they braced themselves and took a nice big bite. Even if I thought they were wrong about everything, I'd still have a ton of respect for their willingness to engage and their admirable demeanor while doing so. They are doing all the right things to build a language and community that deserves to underpin the most important software ecosystem since the web, and they don't have to. They had to fight and sacrifice and make enemies at Apple in order to be allowed to open the door and get a tomato in the face. Whether I agree with their decisions or not (lol, "trimming"), it's exactly the sort of team I'd want designing a language I bet my livelihood on. If they find themselves in MPK, the drinks are on me.
|
|
#
?
Feb 4, 2016 05:57
|
|
|
Echo Video posted:right, legal contracts that are 60 pages long are the models of clarity Not to be that guy, but legal contracts are often 60 pages long specifically for clarity (explicit is better than implicit). Which, actually, kind of gets to the heart of the argument: do you define clarity as "does exactly what it says it does," or do you define it as, "short and to the point"? nah thanks fucked around with this message at 06:10 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 06:05
|
|
|
Gul Banana posted:we should not be optimising for the authoring ability of beginners who aren't aware of docs or ide mechanisms. In my experience of questionable success, you can optimize for beginners, for mastery, and for extensibility (it being obvious to a library author what the Swifty thing is, and to a consumer how it fits together), all largely by one principle: Minimize exceptions. Every time you have to say "except" or "but" in your language overview, you lose some ground. Every time some tool built to process your stuff needs a special if, an angel loses its wings.
|
|
#
?
Feb 4, 2016 06:07
|
|
|
squidgee posted:Not to be that guy, but legal contracts are 60 pages specifically for clarity (explicit is better than implicit). fair enough, I had more the idea of fine-print-tricks or gigantic ELUAs in mind when I wrote that. there are certainly cases where more words do obscure actual meaning.
|
|
#
?
Feb 4, 2016 06:11
|
|
|
Echo Video posted:fair enough, I had more the idea of fine-print-tricks or gigantic ELUAs in mind when I wrote that. there are certainly cases where more words do obscure actual meaning. In most of those cases, the situation is complex, and the words clearly describe that complexity. False simplification is not doing anyone favours.
|
|
#
?
Feb 4, 2016 06:13
|
|
|
The word you're looking for is "brevity". e: slightly less pithy: the word "clarity" has a meaning. It is orthogonal to brevity. Sometimes, clarity is improved by brevity. Other times it is not. So of course, much like "pro-life" and "pro-choice", we should take the banners of these orthogonal concepts up as though they oppose each other directly. Dessert Rose fucked around with this message at 06:18 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 06:13
|
|
|
Subjunctive posted:In my experience of questionable success, you can optimize for beginners, for mastery, and for extensibility (it being obvious to a library author what the Swifty thing is, and to a consumer how it fits together), all largely by one principle: I agree, but it doesn't sound like that principle helps us make a decision here. "Always repeat type names" and "never repeat type names" would both pass...
|
|
#
?
Feb 4, 2016 06:22
|
|
|
Dessert Rose posted:The word you're looking for is "brevity". You've read too many of my posts to believe that.
|
|
#
?
Feb 4, 2016 06:27
|
|
|
Gul Banana posted:tbh it's just kind of hard to take the 'catastrophe' pov seriously having spent years programming in each of cocoa, java and .net. they're directly comparable stacks Remember that Java's core libraries and even language features were based in significant part on the original NeXT AppKit design by Bill Parkhurst, the NeXT/Sun OpenStep API effort, and Objective-C. Then IFC (which was the basis for the Java 2 work) was specifically designed to mimic the NeXT APIs as well. And then Microsoft's Anders Heljsberg based C# and .NET on Java 1.x, while a certain Bill Parkhurst was one of the people behind the Visual Studio IDE. And the design of the original AppKit is traceable to MacApp, which is in turn traceable to the Lisa Application ToolKit. Both of which were implemented in Object Pascal, which Apple had hired Niklaus Wirth to help design, and which Borland and a certain Anders Heljsberg continued to promote and enhance long after Apple had switched to C++. There are very good historical reasons the frameworks and languages all feel similar. They're related kind of like English, Dutch, and German. There are other languages and frameworks out there that are a bit more different, and not just "research" ones either. (Though many have been consigned to the dustbin of history…)
|
|
#
?
Feb 4, 2016 07:01
|
|
|
If you want to see what NeXT AppKit development was like pre-OpenStep, someone has an online collection of the Nextstep 3.3 documentation which includes such APIs as -[View drawSelf::] and -[View display:::]. Yes, that's two and three colons, respectively.
|
|
#
?
Feb 4, 2016 07:07
|
|
|
eschaton posted:If you want to see what NeXT AppKit development was like pre-OpenStep, someone has an online collection of the Nextstep 3.3 documentation which includes such APIs as -[View drawSelf::] and -[View display:::]. What's the PL design equivalent of the Overton window?
|
|
#
?
Feb 4, 2016 07:44
|
|
|
"20 years behind the state of the art in academia"
|
|
#
?
Feb 4, 2016 08:00
|
|
|
I should really engage at length with the core discussion on principles here, but I'm trying to stay focused to finish a particular engineering task, so it might not happen. I do want to try to establish a few things, though. The first is that we take the open source language design process seriously, for ourselves like everyone else. A language proposal from Apple isn't just a proposal in name; it really is just a proposal, and our proposals can get shot down or modified by community feedback just like any other. There's no formal process for that, and there never will be, because we do know what a heckler's veto is; still, when there's a strong current of opinion pointing in a direction, that's absolutely taken into account. Of course, we do talk internally about proposals before sending them out, which means that they've had a few rounds of refinement. However, that doesn't always mean that everybody is happy with the proposal as drafted, and sometimes the community response can be eye-opening. So, please, engage with us; it is not a waste of time. You do need to understand that we do this all day, every day. For every thread on that's a massive cluster-gently caress on swift-evolution, I assure you that we've had probably at least an order of magnitude more discussion internally, and those internal conversations are much more charged than mailing lists, both emotionally and politically. That's not to say that you should just shut up and let us have "our way"; very few proposals are going to gain perfect consensus even within the core team, and the community absolutely shapes the discussion. But the endless discussion is tiring, and it's hard to engage with every person with perfect deftness and attention, and there may even be other things happening in our work and personal lives besides language design, and we are human. If you show up in a conversation, and your post seems theatrically over-the-top, vitriolic, or in any other way unlikely to lead to a constructive conversation, it is very likely that you will simply be ignored, and you will have just made our lives worse, and we will not thank you for it. So, using the present example, when you call a proposal catastrophically bad and talk as if it's stripping all contextual information from the code and will forever stain your memory of Swift, and we know that the actual proposal does not have that large of a line-by-line impact on actual programs, it does not inspire credibility. With that, on to specifics a bit. Some amount of method renaming in Swift is, I think, inevitable. Geography shapes culture; syntax shapes API design. The Smalltalk style of x foo: y bar: z has its merits but is ultimately not the basic syntax we selected for Swift, for I think good reasons; but regardless of what you might think about it, that decision at least is not being reopened. What we went with was x.foo(bar: y), a syntax that much more closely resembles C/C++/Java/C#-style calls, but with labels. This syntax does not read as naturally as a single sentence as the Smalltalk syntax does, because it separates the method name from the arguments; instead, the method name feels like it ought to identify the operation being performed, and the argument area ought to describe the nature and purpose of the arguments. The key insight here is that some methods simply fit one syntax better than they fit the other. My go-to process here when looking for examples to guide my thinking is to just open the NSWindow documentation. Many of the methods on NSWindow do not read well as sentences, not because they were poorly named but simply because the required arguments don't fit well into a sentence or the prevailing naming conventions. beginCriticalSheet:completionHandler: is a good example of the first: this method has to take a completion handler, but there's no reasonable way to fit that at the end of a sentence; it would end up something like beginCriticalSheet:andCall:whenComplete, with a trailing, argument-less label (which is indeed an idea that wouldn't die when we were considering these core syntax questions). setFrameUsingName: is an example of the second: this is grammatical, to be sure, but it's not a real sentence, because "using" says absolutely nothing; you'd have to spend a lot more words to describe that effectively, maybe setFrameToDefaultRectNamed:. Again, my goal here is not to criticize these names; it's to say that the Smalltalk syntax isn't always doing them any favors just because it's more sentence-like. Even without changing any of the actual words, I think that beginCriticalSheet(_:completionHandler:) and setFrame(usingName:) arguably read better by more clearly separating the operation from its argument. So it has always been clear that some things will look and feel different in Swift from how they do in Objective-C, because some methods simply would not have had exactly the same names if they were written in Swift. One way to remedy that, of course, would be to go through the entire SDK, method by method, and decide how they should be imported into Swift; but even if you got perfect up-take (impossible) and established very strong guidelines that everybody agreed on (impossible), you'd get different maintainers interpreting them differently enough to end up with an extremely non-cohesive environment. So even then, it would be better to try to automate the application of those guidelines. That's certainly possible: the technical aspects aren't difficult, and the exact algorithm isn't really important: the Swift programmer will see the imported API, and if the decision was really that bad, they can change it (by, at worst, wrapping it in their own API). Independent of the actual guidelines being applied, I don't think the idea of automatic application is itself problematic. I should talk more about the actual guidelines being proposed, but I've already run far over the amount of time I wanted to spend posting about this right now, so maybe I'll find some time tomorrow. rjmccall fucked around with this message at 08:09 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 08:04
|
|
|
|
| # ? May 15, 2024 08:57 |
|
|
rjmccall posted:You do need to understand that we do this all day, every day. For every thread on that's a massive cluster-gently caress on swift-evolution, I assure you that we've had probably at least an order of magnitude more discussion internally, and those internal conversations are much more charged than mailing lists, both emotionally and politically. That's not to say that you should just shut up and let us have "our way"; very few proposals are going to gain perfect consensus even within the core team, and the community absolutely shapes the discussion. But the endless discussion is tiring, and it's hard to engage with every person with perfect deftness and attention, and there may even be other things happening in our work and personal lives besides language design, and we are human. If you show up in a conversation, and your post seems theatrically over-the-top, vitriolic, or in any other way unlikely to lead to a constructive conversation, it is very likely that you will simply be ignored, and you will have just made our lives worse, and we will not thank you for it. So, using the present example, when you call a proposal catastrophically bad and talk as if it's stripping all contextual information from the code and will forever stain your memory of Swift, and we know that the actual proposal does not have that large of a line-by-line impact on actual programs, it does not inspire credibility. Doctor w-rw-rw- posted:I hate when people (read: HN users) pile on to (for example) GitHub issues and offer comments without committing to a discussion and end up adding noise instead of useful commentary, so I'm not really willing to participate directly since I'd prefer to be writing code or My 'professional' hat isn't on here, and I knew my reaction was negative enough that I wouldn't want to dip into a setting where good people are doing good jobs – and certainly not where I might represent my views as being anything but my own. The proposal feels super bad, but I don't want to barge into a professional setting with my (very) strong negative reaction. You might be rightfully pissed with me at how over the top I get on an internet forum and stepping on your toes while doing so, but I do appreciate all of the above (plus what Subjunctive mentioned); next time we meet I'm also up to cover drinks. rjmccall posted:So it has always been clear that some things will look and feel different in Swift from how they do in Objective-C, because some methods simply would not have had exactly the same names if they were written in Swift. One way to remedy that, of course, would be to go through the entire SDK, method by method, and decide how they should be imported into Swift; but even if you got perfect up-take (impossible) and established very strong guidelines that everybody agreed on (impossible), you'd get different maintainers interpreting them differently enough to end up with an extremely non-cohesive environment. So even then, it would be better to try to automate the application of those guidelines. That's certainly possible: the technical aspects aren't difficult, and the exact algorithm isn't really important: the Swift programmer will see the imported API, and if the decision was really that bad, they can change it (by, at worst, wrapping it in their own API). Independent of the actual guidelines being applied, I don't think the idea of automatic application is itself problematic. This way, you get to solve the problem for people, and let people either shoot themselves in the foot or aim the gun away from it instead of taking responsibility for developer frustration on account of a very disruptive change. EDIT: so it occurs to me that a user*-defined mapping could have a non-trivial memory requirement to register the mapping, whereas the automatic mapping would be a lot cheaper and could be less constraining on some aspects of implementation. Given that, it seems more clear why any change needs to be comprehensive. I still disagree with a lot, but the "obvious" way to solve it in my head isn't necessarily good. Guess I need to keep writing Swift so I can argue more cogently. * (as in developer of the thing that needs a mapping) Doctor w-rw-rw- fucked around with this message at 10:03 on Feb 4, 2016 |
|
#
?
Feb 4, 2016 09:36
|
|