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

[Chris Lattner via swift-evolution]

> On Oct 13, 2016, at 12:03 PM, Ted F.A. van Gaalen  
> wrote:
> 
> Hello Chris,
> 
> Thank you for updating me,
> read this and other related info again thoroughly
> and will act accordingly.
> In the mean time I will work dynamically on dynamics :o)
> Currently I suspend my topic. 
> and  bring this back again much later but
> then tagged with [out of scope] If this is appropriate,
> 
> Have I understood this correctly, 
> Is that OK?

Yep,

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

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

[Ted F.A. van Gaalen via swift-evolution]

Hello Chris,

Thank you for updating me,
read this and other related info again thoroughly
and will act accordingly.
In the mean time I will work dynamically on dynamics :o)
Currently I suspend my topic. 
and  bring this back again much later but
then tagged with [out of scope] If this is appropriate,

Have I understood this correctly, 
Is that OK?

Ted


> On 13 Oct 2016, at 07:58, Chris Lattner  wrote:
> 
> 
>> On Oct 12, 2016, at 10:14 AM, Ted F.A. van Gaalen via swift-evolution 
>>  wrote:
>> 
>> Hello Austin
>> I haven’t read that from Chris - Must have overlooked it due to the shear 
>> volume on swift-evolution.
> 
> Completely understandable, I’m sure you’re not the only one who has missed 
> this. 
> 
> That said, FWIW, the goals for Swift 4 and the current planning stage are 
> spelled out in the front-page of the swift-evolution repo:
> https://github.com/apple/swift-evolution
> 
> As others’ have said, we are trying to approach the Swift 4 cycle based on 
> what we learned from Swift 2.2 and Swift 3.  
> 
> Thanks for understanding, 
> 
> -Chris
> 

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

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

[Chris Lattner via swift-evolution]

> On Oct 12, 2016, at 10:14 AM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hello Austin
> I haven’t read that from Chris - Must have overlooked it due to the shear 
> volume on swift-evolution.

Completely understandable, I’m sure you’re not the only one who has missed 
this. 

That said, FWIW, the goals for Swift 4 and the current planning stage are 
spelled out in the front-page of the swift-evolution repo:
https://github.com/apple/swift-evolution

As others’ have said, we are trying to approach the Swift 4 cycle based on what 
we learned from Swift 2.2 and Swift 3.  

Thanks for understanding, 

-Chris

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

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

[Ted F.A. van Gaalen via swift-evolution]

Hi David, thanks for your explanation, most things are understandable. 

However, I am challenged by all this to study this subject more in detail
and come back with it later at a more convenient time. 

After all those years, now I have time for this to go in-depth, wait and see.

Met vriendelijke groeten
TedvG



> On 12 Oct 2016, at 23:38, David Hart  wrote:
> 
> Hi Ted,
> 
> My replies inline:
> 
>> On 12 Oct 2016, at 22:37, Ted F.A. van Gaalen > > wrote:
>> 
>> Hi David,
>> 
>> Thanks for your reply., OK, I think I understand. 
>> 
>> It then is a capacity problem, right?
> 
> Mainly. We lived through a few months where there was very little focus, and 
> everybody brought up all kind of ideas. It was great, but it was also very 
> chaotic. Many proposals were accepted, but the implementation for them was a 
> rush and a few couldn’t make it in the final release of Swift 3.
> 
> I think the decision of focusing releases is to improve the evolution process 
> by trying to make sure we set the right priorities and to make them 
> attainable. For example, if we do not focus on ABI stability, Swift 4 will 
> not be able to set the ABI in stone, which would disappoint many many people.
> 
>> In effect, it means restricting people from bringing perhaps very valuable 
>> (not necessarily my contributions) 
>> and essential ideas forward, which could play a crucial role improving Swift.
> 
> Not necessarily restrict. But politely ask them to keep a hold of those ideas 
> until a more appropriate phase of Swift’s development allows those kind of 
> proposals.
> 
>> I think this is a very negative aspect. surely bouncing creative people away,
>> dropping their efforts and interest here altogether. 
> 
> We try to be as kind and positive as possible as not to bounce create ideas 
> away. But I think it is also important that we explain the priorities of the 
> evolution process through time so Swift can move forward.
> 
>> The question then remains, where / when / how can one bring topics 
>> that are taking a longer stretch and are not bound to a certain release of 
>> Swift,
>> seemingly “outside” of this restriction under attention?
> 
> It all depends on the focus at the time. For example, the swift evolution 
> README states that phase 2 of Swift 4 will allow new features to be discussed 
> and implemented:
> 
> Stage 2 will commence once the implementation work on the Stage 1 features is 
> cresting, and can contain a few other large and small features. We expect 
> that stage 2 will commence some time in Spring 2017.
> 
>> if swift evolution is (currently? ) not open for new ideas/topics:
>> I thought that was the primary purpose of Swift evolution?
> 
> The purpose of Swift evolution as I understand it is to bring ideas, 
> proposals and discuss them to push Swift forward in line with the project 
> priorities at the time. You can, for example, bring new features and topics 
> forward now, but they need to concern ABI stability. For example, we are 
> looking at the remaining Generics features which will allow the Standard 
> Library to take its final form.
> 
> David.
> 
>> Kind Regards
>> Ted
>> 
>> 
>>> On 12 Oct 2016, at 21:48, David Hart >> > wrote:
>>> 
>>> Hello Ted,
>>> 
>>> Please try to understand. As Xiaodi and others have said a few times, it 
>>> has nothing to do with the topic being important or interesting. The 
>>> current phase of Swift 4’s development does not allow any extensive 
>>> discussion or review on topics which do not impact ABI stability:
>>> 
>>> Stage 1 focuses on the essentials required for source and ABI stability. 
>>> Features that don't fundamentally change the ABI of existing language 
>>> features or imply an ABI-breaking change to the standard library will not 
>>> be considered in this stage.
>>> 
 On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Apart from my perhaps fierce reaction, I am not aware of doing something 
 wrong.
 and I still find this topic very important. 
>>> 
>>> David.
>> 
> 

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

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

[David Sweeris via swift-evolution]

> On Oct 12, 2016, at 5:25 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hi Xiaodi,
> 
> thanks for you reply, yes, I am aware from most things you write here,
> and also that what I wrote about dynamic facilities is probably not unique,
> as there are so many people involved and interested etc. 
> 
> then you wrote
>> … Swift 3, but the truth is that there will never be a release based on 
>> Swift 3 that additionally has dynamic facilities.  
> 
> You wanna make a bet? I see that as a challenge to work this out in detail 
> much further, because I am convinced that
> these dynamic features in one form or another can be implemented successfully 
> and add great value to Swift !
> I come back with it much later when there is time, capacity and interest.

I think Xiaodi was talking about an *official* Swift 3.x release. Meaning that 
Swift will be at least at version 4 before any of these features might be 
adopted into mainstream Swift.

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

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

[Ted F.A. van Gaalen via swift-evolution]

Hi Xiaodi,

thanks for you reply, yes, I am aware from most things you write here,
and also that what I wrote about dynamic facilities is probably not unique,
as there are so many people involved and interested etc. 

then you wrote
> … Swift 3, but the truth is that there will never be a release based on Swift 
> 3 that additionally has dynamic facilities.  

You wanna make a bet? I see that as a challenge to work this out in detail much 
further, because I am convinced that
these dynamic features in one form or another can be implemented successfully 
and add great value to Swift !
I come back with it much later when there is time, capacity and interest.

Oh, btw I still do believe in magic. Since 1950.

TedvG

  



> On 12 Oct 2016, at 23:45, Xiaodi Wu  wrote:
> 
> On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Hi David,
> 
> Thanks for your reply., OK, I think I understand. 
> 
> It then is a capacity problem, right?
> 
> In effect, it means restricting people from bringing perhaps very valuable 
> (not necessarily my contributions) 
> and essential ideas forward, which could play a crucial role improving Swift.
> 
> I think this is a very negative aspect. surely bouncing creative people away,
> dropping their efforts and interest here altogether. 
> 
> The question then remains, where / when / how can one bring topics 
> that are taking a longer stretch and are not bound to a certain release of 
> Swift,
> seemingly “outside” of this restriction under attention?
> 
> if swift evolution is (currently? ) not open for new ideas/topics:
> I thought that was the primary purpose of Swift evolution?
> 
> Kind Regards
> Ted
> 
> [Edit: David just wrote a very nice reply, but since I'm mostly done with 
> this email, I'll send it along anyway as a companion response.]
> 
> I think this is worth a reply, if only because I think we've touched on the 
> underlying issues somewhat obliquely in the past.
> 
> It's enormously interesting to talk about important questions of language 
> design here on the list: that's why we're here. And it's been magical to see 
> that an idea written here, pitched convincingly, comes into being in the next 
> version of a programming language.
> 
> Except it's not magic. Dozens if not hundreds of people spend time thinking 
> about and debating concrete implementation details, then a group of people 
> painstakingly implements the result. During the Swift 3 time frame, the 
> illusion of magic fell apart because even some excellently pitched ideas, 
> carefully thought out, never became reality. This results in a huge loss of 
> time and effort. Everything that didn't make it into Swift 3 needs to be 
> re-evaluated to some extent because features are not designed in a vacuum and 
> must fit in with the rest of the language. The best solution for a problem 
> that we could design after the Swift 2 release would look very different from 
> the best solution that we can design now.
> 
> The point is, since nothing is really magic, we have to make a concession to 
> the reality that ideas too far from identified priorities are much less 
> likely to become part of the next release. It may be fun and creative to 
> think about how, hypothetically, one would design dynamic facilities to 
> support Swift 3, but the truth is that there will never be a release based on 
> Swift 3 that additionally has dynamic facilities. It is simply not a 
> productive use of anyone's creativity, time, or effort to imagine how that 
> might look; we're better off channeling everyone's energy towards making the 
> real, actual upcoming release of Swift even better.
> 
>> On 12 Oct 2016, at 21:48, David Hart > > wrote:
>> 
>> Hello Ted,
>> 
>> Please try to understand. As Xiaodi and others have said a few times, it has 
>> nothing to do with the topic being important or interesting. The current 
>> phase of Swift 4’s development does not allow any extensive discussion or 
>> review on topics which do not impact ABI stability:
>> 
>> Stage 1 focuses on the essentials required for source and ABI stability. 
>> Features that don't fundamentally change the ABI of existing language 
>> features or imply an ABI-breaking change to the standard library will not be 
>> considered in this stage.
>> 
>>> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Apart from my perhaps fierce reaction, I am not aware of doing something 
>>> wrong.
>>> and I still find this topic very important. 
>> 
>> David.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
sw

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi David,
>
> Thanks for your reply., OK, I think I understand.
>
> It then is a capacity problem, right?
>
> In effect, it means restricting people from bringing perhaps very valuable
> (not necessarily my contributions)
> and essential ideas forward, which could play a crucial role improving
> Swift.
>
> I think this is a very negative aspect. surely bouncing creative people
> away,
> dropping their efforts and interest here altogether.
>
> The question then remains, where / when / how can one bring topics
> that are taking a longer stretch and are not bound to a certain release of
> Swift,
> seemingly “outside” of this restriction under attention?
>
> if swift evolution is (currently? ) not open for new ideas/topics:
> I thought that was the primary purpose of Swift evolution?
>
> Kind Regards
> Ted
>

[Edit: David just wrote a very nice reply, but since I'm mostly done with
this email, I'll send it along anyway as a companion response.]

I think this is worth a reply, if only because I think we've touched on the
underlying issues somewhat obliquely in the past.

It's enormously interesting to talk about important questions of language
design here on the list: that's why we're here. And it's been magical to
see that an idea written here, pitched convincingly, comes into being in
the next version of a programming language.

Except it's not magic. Dozens if not hundreds of people spend time thinking
about and debating concrete implementation details, then a group of people
painstakingly implements the result. During the Swift 3 time frame, the
illusion of magic fell apart because even some excellently pitched ideas,
carefully thought out, never became reality. This results in a huge loss of
time and effort. Everything that didn't make it into Swift 3 needs to be
re-evaluated to some extent because features are not designed in a vacuum
and must fit in with the rest of the language. The best solution for a
problem that we could design after the Swift 2 release would look very
different from the best solution that we can design now.

The point is, since nothing is really magic, we have to make a concession
to the reality that ideas too far from identified priorities are much less
likely to become part of the next release. It may be fun and creative to
think about how, hypothetically, one would design dynamic facilities to
support Swift 3, but the truth is that there will never be a release based
on Swift 3 that additionally has dynamic facilities. It is simply not a
productive use of anyone's creativity, time, or effort to imagine how that
might look; we're better off channeling everyone's energy towards making
the real, actual upcoming release of Swift even better.

On 12 Oct 2016, at 21:48, David Hart  wrote:
>
> Hello Ted,
>
> Please try to understand. As Xiaodi and others have said a few times, it
> has nothing to do with the topic being important or interesting. The
> current phase of Swift 4’s development does not allow any extensive
> discussion or review on topics which do not impact ABI stability:
>
> *Stage 1 focuses on the essentials required for source and ABI stability.
> Features that don't fundamentally change the ABI of existing language
> features or imply an ABI-breaking change to the standard library will not
> be considered in this stage.*
>
> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Apart from my perhaps fierce reaction, I am not aware of doing something
> wrong.
> and I still find this topic very important.
>
>
> David.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

Hi Ted,

My replies inline:

> On 12 Oct 2016, at 22:37, Ted F.A. van Gaalen  wrote:
> 
> Hi David,
> 
> Thanks for your reply., OK, I think I understand. 
> 
> It then is a capacity problem, right?

Mainly. We lived through a few months where there was very little focus, and 
everybody brought up all kind of ideas. It was great, but it was also very 
chaotic. Many proposals were accepted, but the implementation for them was a 
rush and a few couldn’t make it in the final release of Swift 3.

I think the decision of focusing releases is to improve the evolution process 
by trying to make sure we set the right priorities and to make them attainable. 
For example, if we do not focus on ABI stability, Swift 4 will not be able to 
set the ABI in stone, which would disappoint many many people.

> In effect, it means restricting people from bringing perhaps very valuable 
> (not necessarily my contributions) 
> and essential ideas forward, which could play a crucial role improving Swift.

Not necessarily restrict. But politely ask them to keep a hold of those ideas 
until a more appropriate phase of Swift’s development allows those kind of 
proposals.

> I think this is a very negative aspect. surely bouncing creative people away,
> dropping their efforts and interest here altogether. 

We try to be as kind and positive as possible as not to bounce create ideas 
away. But I think it is also important that we explain the priorities of the 
evolution process through time so Swift can move forward.

> The question then remains, where / when / how can one bring topics 
> that are taking a longer stretch and are not bound to a certain release of 
> Swift,
> seemingly “outside” of this restriction under attention?

It all depends on the focus at the time. For example, the swift evolution 
README states that phase 2 of Swift 4 will allow new features to be discussed 
and implemented:

Stage 2 will commence once the implementation work on the Stage 1 features is 
cresting, and can contain a few other large and small features. We expect that 
stage 2 will commence some time in Spring 2017.

> if swift evolution is (currently? ) not open for new ideas/topics:
> I thought that was the primary purpose of Swift evolution?

The purpose of Swift evolution as I understand it is to bring ideas, proposals 
and discuss them to push Swift forward in line with the project priorities at 
the time. You can, for example, bring new features and topics forward now, but 
they need to concern ABI stability. For example, we are looking at the 
remaining Generics features which will allow the Standard Library to take its 
final form.

David.

> Kind Regards
> Ted
> 
> 
>> On 12 Oct 2016, at 21:48, David Hart > > wrote:
>> 
>> Hello Ted,
>> 
>> Please try to understand. As Xiaodi and others have said a few times, it has 
>> nothing to do with the topic being important or interesting. The current 
>> phase of Swift 4’s development does not allow any extensive discussion or 
>> review on topics which do not impact ABI stability:
>> 
>> Stage 1 focuses on the essentials required for source and ABI stability. 
>> Features that don't fundamentally change the ABI of existing language 
>> features or imply an ABI-breaking change to the standard library will not be 
>> considered in this stage.
>> 
>>> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Apart from my perhaps fierce reaction, I am not aware of doing something 
>>> wrong.
>>> and I still find this topic very important. 
>> 
>> David.
> 

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

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

[Ted F.A. van Gaalen via swift-evolution]

Hi David,

Thanks for your reply., OK, I think I understand. 

It then is a capacity problem, right?

In effect, it means restricting people from bringing perhaps very valuable 
(not necessarily my contributions) 
and essential ideas forward, which could play a crucial role improving Swift.

I think this is a very negative aspect. surely bouncing creative people away,
dropping their efforts and interest here altogether. 

The question then remains, where / when / how can one bring topics 
that are taking a longer stretch and are not bound to a certain release of 
Swift,
seemingly “outside” of this restriction under attention?

if swift evolution is (currently? ) not open for new ideas/topics:
I thought that was the primary purpose of Swift evolution?

Kind Regards
Ted


> On 12 Oct 2016, at 21:48, David Hart  wrote:
> 
> Hello Ted,
> 
> Please try to understand. As Xiaodi and others have said a few times, it has 
> nothing to do with the topic being important or interesting. The current 
> phase of Swift 4’s development does not allow any extensive discussion or 
> review on topics which do not impact ABI stability:
> 
> Stage 1 focuses on the essentials required for source and ABI stability. 
> Features that don't fundamentally change the ABI of existing language 
> features or imply an ABI-breaking change to the standard library will not be 
> considered in this stage.
> 
>> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Apart from my perhaps fierce reaction, I am not aware of doing something 
>> wrong.
>> and I still find this topic very important. 
> 
> David.

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

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

[David Hart via swift-evolution]

Hello Ted,

Please try to understand. As Xiaodi and others have said a few times, it has 
nothing to do with the topic being important or interesting. The current phase 
of Swift 4’s development does not allow any extensive discussion or review on 
topics which do not impact ABI stability:

Stage 1 focuses on the essentials required for source and ABI stability. 
Features that don't fundamentally change the ABI of existing language features 
or imply an ABI-breaking change to the standard library will not be considered 
in this stage.

> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Apart from my perhaps fierce reaction, I am not aware of doing something 
> wrong.
> and I still find this topic very important. 

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

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

[Ted F.A. van Gaalen via swift-evolution]

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 : 
>> "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 
>> .” 

> 

Kind Regards
TedvG 

> On 12 Oct 2016, at 19:00, Austin Zheng  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 
> 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 > > wrote:
>> 
>> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen > > wrote:
>> Hi Xiaodi,
>> please read in-line, thank you.
>> 
>>> On 12 Oct 2016, at 15:58, Xiaodi Wu >> > wrote:
>>> 
>>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen >> > wrote:
>>> 
 On 11 Oct 2016, at 23:04, Xiaodi Wu >>> > 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

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

[Austin Zheng via swift-evolution]

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> 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  wrote:
>
> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <
> tedvgios...@gmail.com> wrote:
>
>> Hi Xiaodi,
>> please read in-line, thank you.
>>
>> On 12 Oct 2016, at 15:58, Xiaodi Wu  wrote:
>>
>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <
>> tedvgios...@gmail.com> wrote:
>>
>>>
>>> On 11 Oct 2016, at 23:04, Xiaodi Wu  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 :
>> "Proposing N

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

[Ted F.A. van Gaalen via swift-evolution]

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  wrote:
> 
> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen  > wrote:
> Hi Xiaodi,
> please read in-line, thank you.
> 
>> On 12 Oct 2016, at 15:58, Xiaodi Wu > > wrote:
>> 
>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen > > wrote:
>> 
>>> On 11 Oct 2016, at 23:04, Xiaodi Wu >> > 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 : 
> "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 
> .” 
> 
> 
> 
> 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 

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen  wrote:

> Hi Xiaodi,
> please read in-line, thank you.
>
> On 12 Oct 2016, at 15:58, Xiaodi Wu  wrote:
>
> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <
> tedvgios...@gmail.com> wrote:
>
>>
>> On 11 Oct 2016, at 23:04, Xiaodi Wu  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:
> "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
> .”
>
>
>
> 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 intellige

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

[Ted F.A. van Gaalen via swift-evolution]

Hi Xiaodi,
please read in-line, thank you.

> On 12 Oct 2016, at 15:58, Xiaodi Wu  wrote:
> 
> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen  > wrote:
> 
>> On 11 Oct 2016, at 23:04, Xiaodi Wu > > 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: 

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. 

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!

4. read this on 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 
.” 



5. If a certain topic is not interesting for you personally then simply ignore 
it and don’t react.

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?”
> 
> “Ehmm, 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

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen 
wrote:

>
> On 11 Oct 2016, at 23:04, Xiaodi Wu  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."

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.

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?”
>
> “Ehmm, 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> wrote:
>
>>
>> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution <
>> 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
>> ge

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

[Ted F.A. van Gaalen via swift-evolution]

> On 11 Oct 2016, at 23:04, Xiaodi Wu  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? 
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?”

“Ehmm, 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 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution 
> 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 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

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

[Ted F.A. van Gaalen via swift-evolution]

Hi Jeremy
> On 12 Oct 2016, at 10:52, Jeremy Pereira  
> wrote:
> 
> 
>> On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution 
>>  wrote:
>> 
>> 
>> While Swift is mainly a statically typed language, recompilation or 
>> additional 
>> compilation and somehow link it al together is obviously necessary at run 
>> time, 
>> each time a dynamic structure is defined. 
>> Because of this, it will most probably have performance drawbacks 
>> at run time
> 
> Not the least of which would be the need to install a Swift compiler 
> toolchain on the target Mac - or iOS device.
Yes that is true. Or at least a smaller more specialized  part of it that can 
do dynamic additions/plug-in…
TedvG



 
 

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

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

[Jeremy Pereira via swift-evolution]

> On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> 
> While Swift is mainly a statically typed language, recompilation or 
> additional 
> compilation and somehow link it al together is obviously necessary at run 
> time, 
> each time a dynamic structure is defined. 
> Because of this, it will most probably have performance drawbacks 
> at run time

Not the least of which would be the need to install a Swift compiler toolchain 
on the target Mac - or iOS device.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Reflection is likely to be tackled in Swift 5, no? So realistically, this
could be on track for Swift 6 or 7. Let's postpone discussion until then.


On Tue, Oct 11, 2016 at 15:59 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution <
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution 
>  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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted F.A. van Gaalen via swift-evolution]

thank you, Goffredo, Anton, see inline
TedvG
> On 11 Oct 2016, at 21:10, Goffredo Marocchi  wrote:
> 
> I quite like your builder pattern way of adding properties and methods :).
> 
> Sent from my iPhone
> 
> On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution 
> 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.
>> 
The idea is not intended to be in a deadline/timeframe
could be Swift 7 for that :o) 
>> ..  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 don’t know how much reflection is needed in this context.
-Adding dynamic classes can be solved with incremental? recompiling 
based on previously generated compiler reference metadata, 
already present. (note that in debug mode there already is a lot of “reflection”
available)
 - static entities defined at the initial compilation
 - and cumulative for dynamic entities when additionaly compiled at run time.
As soon as a dynamically defined or redefined class (or struct) is compiled
it is then regarded as a static type, transparent to the application thus which 
instances 
cannot be dynamically altered, because they are “tied” to the class definition.
Instance creation is then the same as with statically defined classes

(but all this  is a bit simplified of course, and I don’t know much about 
compilers.
Maybe similar to Smalltalk where methods/classes are precompiled separately)

@ Chris: As a Compiler Pro could you say more about this and about the whole 
idea, Chris? 

Thanks
TedvG




>> Dynamic Class/Struct Definition At Run Time 
>> 
>> At the time of this writing, 11 October 2016, it is not possible to define 
>> arbitrary 
>> classes, structs and maybe other entities dynamically at run time in Swift. 
>> I have some idea about it, expressed in this message.
>> 
>> Creating class and other types dynamically should be as simple and as easy 
>> to understand 
>> as possible, preferably with nearly the same style and syntax as the 
>> "regular" declarations,
>>  leaving things like "Meta""Type" T.Self etc. as transparent as possible. 
>> That should in this context be "under the hood", as it is also the case 
>> when defining static classes. 
>> 
>> I have constructed the following (hypothetical) example code,
>>  which serves as just a "thinking model", so to speak.
>> 
>> // In this example we dynamically create and use 
>> // an example class named "Monolith"
>> // First, we declare an "empty dynamic class"
>> // (a slot) at compile time, that is later defined at run time.
>>
>> dynamic class Monolith // defined later just this line.
>> 
>> // Use a constructor that accepts 
>> // a string which contains a class definition, 
>> // exactly like one would define a class in Swift statically. 
>> // with the exception that name of the class is not specified. 
>> // It is replaced by placeholder, an underscore, because 
>> // the class name itself is inferred when declaring it. 
>> // Specifying the class name will throw an error.
>> 
>> var classDefStr = 
>> "class _ :SCNNode, AnInterface, AnotherInterface "+
>> "{var l = 9.0; var h = 4.0; var  w = 1.0; " +
>> "var color = UIColor.blue;"+ 
>> "func volume() -> Double { return l * w * h} “ +
>> aStringWithAdditionalComponentDefinitions + "}"
>> 
>> // Of course, this class definition string can also be assembled
>> // completely programatically, read from a file or database, etc. 
>> 
>> func defMonolithClass()
>> {
>> do  // try to define a class, NOT an instance.
>> {
>> try Monolith = 
>> Meta.defineClass(withString: classDefStr)
>> }
>> catch Meta.classDefinitionError
>> {
>> // handle a possible class dynamic compilation errors
>> // e.g. syntax errors. symbols not found etc.  
>> }
>> catch Meta.classCreationConflict
>> {
>> // class cannot be redefined 
>> // when instances of Monolith still exist.
>> // This restriction is probably necessary.
>> // Also, static classes defined at compile time
>> // canno

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

[Goffredo Marocchi via swift-evolution]

I quite like your builder pattern way of adding properties and methods :).

Sent from my iPhone

> On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution 
>  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.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Anton Zhilin via swift-evolution]

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.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution