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 <austinzh...@gmail.com> 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 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>> <mailto:tedvgios...@gmail.com>> wrote:
>> Hi Xiaodi,
>> please read in-line, thank you.
>> 
>>> On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>>> <mailto:tedvgios...@gmail.com>> wrote:
>>> 
>>>> On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi...@gmail.com 
>>>> <mailto:xiaodi...@gmail.com>> 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 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to