Hello Austin I haven’t read that from Chris - Must have overlooked it due to the shear volume on swift-evolution.
Note that as you can see, I have apologised to Xiaodi for being a bit too direct, such as perceived in your culture perhaps. The Chinese characters should mean “respectful”” btw. Apart from my perhaps fierce reaction, I am not aware of doing something wrong. and I still find this topic very important. >> 4. read this on Swift.org <http://swift.org/>: >> "Proposing New Features" >> >> "New features or directions for the Swift language can come from anyone with >> a good idea." >> >> "Open discussion and iteration over the ideas in a public forum is essential >> to reaching the best possible solutions." >> >> also >> >> "Everyone is welcome to propose, discuss, and review ideas to improve the >> Swift language and standard library on the swift-evolution mailing list >> <https://swift.org/community/#swift-evolution>.” > Kind Regards TedvG > On 12 Oct 2016, at 19:00, Austin Zheng <[email protected]> wrote: > > This is utterly ridiculous. Chris Lattner and the other core team members > posted repeatedly at the beginning of the Swift 3.x/4 development cycle > asking us expressly to keep the discussion focused on a number of specific > topics. Not only have you repeatedly ignored that request, now you are being > condescending and rude to a community member who has put in tremendous effort > over the last few months trying to make swift-evolution a better place. > Please consider whether or not disregarding the core team's wishes in this > matter is really the best way to show respect for the community and the > project. > > Best regards, > Austin > > On Wed, Oct 12, 2016 at 9:54 AM, Ted F.A. van Gaalen via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Dear Xiaoid > I still don’t agree with you, there should be some flexibility, things should > live > and also, if we adhere to this list you refer to on Github, than no new > topics would be discussable... > I am sorry if I wrote a bit harsh to you. > Kind Regards > 尊敬的 > > Ted > >> On 12 Oct 2016, at 18:41, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Xiaodi, >> please read in-line, thank you. >> >>> On 12 Oct 2016, at 15:58, Xiaodi Wu <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On 11 Oct 2016, at 23:04, Xiaodi Wu <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Reflection is likely to be tackled in Swift 5, no? >>> >>> I'd think you don’t need reflection that much, because defining >>> dynamic classes (and other entities) are solely incremental compiler >>> tasks, for which it can use previously compiled meta reference >>> information (xref symbols etc). >>> >>> Imho in that perspective it is more or less independent >>> of reflection. Reflection is as far as I can see is more intended to offer >>> meta information at the programming level.? >>> >>>> So realistically, this could be on track for Swift 6 or 7. >>> >>> As already written, there is no timeframe/deadline for this idea, it is >>> just an idea, >>> not a proposal (yet). >>> >>>> Let's postpone discussion until then. >>> >>> Feel free to do so, but why postponing having ideas and discussing them? >>> >>> The core team has requested that discussions be focused on the priorities >>> identified for the current phase of Swift 4. There's a sound rationale for >>> this request. Per Chris: "The community benefits from keeping focus on a >>> limited number of topics, because if there is too much going on, no one can >>> follow and keep track of it all. It is important for the core team to be >>> involved in key discussions up front. In the Swift 3 cycle, it was >>> problematic that many folks had no time to follow the threads until after >>> the review period completed.” >> >> You are pulling the above out of context hereunder: >>> >>> I'm sure many people have ideas about dynamic facilities in Swift, as do we >>> all about other ideas, and many have been trying to be respectful of this >>> new proposed process. I think we can all agree that maximum participation >>> and the best solutions are most likely when everyone stays on the same page >>> with regard to the process by which we go about these discussions. No need >>> to postpone having ideas about Swift or talking about them with your >>> friends and colleagues, but let's respect the core team's urging to >>> postpone discussing them on this particular list for the reasons identified >>> above. >>> >> >> 1. You are not a member of the core team, far from it, sorry. >> Don’t think for them, they can do that quite well themselves. and thus: >> >> I'm not trying to speak for the core team; sorry if I'm giving off that >> impression. >> >> 2. If the core team would have problems with me bringing forward this >> topic, >> they might/will inform me that this is undesired, in that case I’ll >> stop writing about it. >> >> As a member of the community, I'm voicing *my* concern that this is not an >> opportune time to discuss this topic. It's up to all participants, not just >> the core team, to try to make sure that the evolution process works >> effectively. So far, in the context of other threads, other community >> members have also been active in pointing out when topics stray too far from >> the suggested areas of focus. I think this is good practice and I'm trying >> to contribute to that effort. >> >> 3. My current subject is an extension spin-off from the topic “associated >> objects”, wherein >> “extending the language" is discussed. Meta Programming and Adding >> Dynamic Features to Swift >> are currently strongly in focus and is surely one of the most important >> things to bring to Swift in the near future! >> >> I'm sorry, but this is not true. The list of focus topics for this phase of >> Swift is on the swift-evolution GitHub project readme, and this is not one >> of them. >> >> 4. read this on Swift.org <http://swift.org/>: >> "Proposing New Features" >> >> "New features or directions for the Swift language can come from anyone with >> a good idea." >> >> "Open discussion and iteration over the ideas in a public forum is essential >> to reaching the best possible solutions." >> >> also >> >> "Everyone is welcome to propose, discuss, and review ideas to improve the >> Swift language and standard library on the swift-evolution mailing list >> <https://swift.org/community/#swift-evolution>.” >> >> >> >> 5. If a certain topic is not interesting for you personally then simply >> ignore it and don’t react. >> >> That is not what I'm saying. I'm very interested in this topic. However, I'm >> concerned that neither I nor others with intense interest can contribute >> meaningfully at this phase, because the suggested focus for the moment is >> not on this topic. I would not want to ignore the topic at all. >> >> 6. Well meant advice: be a little less lofty, >> >> >> Kind Regards >> TedvG >> >> >>> In this case for instance, thinking about dynamic facilities, will >>> presumably >>> also influence thinking about reflection and vice versa. >>> Thinking “wider” and “further” broadens the horizon of course. >>> For example. what about a compiler/interpreter self improving based on >>> artificial intelligence? is this 2016? >>> So one can (should) do both: that is think in small steps, like discussing >>> “just” language elements and at the same time have an eye (or two) for the >>> broader picture. If one concentrates too much on the direct path in front, >>> one might >>> not see other paths or what lays further ahead, which limits progress. >>> >>> ———————————————— >>> Let me write a small cartoon here, just intended as a little bit of humour >>> just to illustrate this: >>> >>> A few thousand years ago, two very nice beings ( just returned from >>> attending a >>> very primitive and awkward election debate, still shivering), looking at a >>> pair >>> of fairly round stone slabs with a hole in the centre. >>> >>> “What’s this ?, Why round? why the holes? Nice job, but what is it? Is it >>> art?” >>> >>> “Errrrhmm, well.. I might call it ‘Wheelz', not sure yet, you can use two >>> of more of them >>> underneath or aside of things you’d like to move around more easily… >>> with less friction, which was a hell of a drag anyway." >>> >>> The other guy walks around it, apparently deeply thinking about it. >>> after some silence he says: >>> “Aha… hmm.. well.. Oh, i see, yeah, yep, that’s kinda cool.. might be >>> useful. >>> But let’’s postpone discussing it until ball-bearings have been invented. “ >>> ———————————————— >>> >>> hmmm, I really have too much time… :o) >>> >>> Kind Regards >>> Ted >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> On Tue, Oct 11, 2016 at 15:59 David Sweeris via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> Hello Ted, >>>>> First of all, this topic belongs to reflection, which is specifically >>>>> stated to be out of scope of Swift 4 Phase 1. So all considerations are >>>>> purely theoretical for now. >>>>> That said, I also thought about this problem. The best I could imagine is >>>>> something along the following lines: >>>>> >>>>> var builder = StructBuilder(name: "Person") >>>>> builder.addProperty(name: "name", type: String.self) >>>>> builder.addProperty(name: "age", type: Int.self) >>>>> builder.addComputedProperty(name: "description", getter: { (this: Any) -> >>>>> String in ... }) >>>>> builder.addComformance(CustomStringConvertible.self) >>>>> let type: Any.Type = builder.build() >>>>> Obviously, to interact with such dynamic types and their objects, we need >>>>> the whole working reflection system that we don’t have right now. >>>>> >>>> >>>> I *think* that's only true for non-generic code, and types that aren't >>>> subclasses... I think... >>>> >>>> Anyway, I'm starting to wonder if some code I'm trying to write might be >>>> impossible without either this feature, or some/all of the stuff from the >>>> generics manifesto. So put me down as, in principle, a strong +1 (pending >>>> details of the proposal when it actually gets written for Swift 10). >>>> >>>> - Dave Sweeris >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
