[swift-evolution] Dynamic Class/Struct Definition At Run Time

Wed Oct 12 12:14:33 CDT 2016

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

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