Dynamic Class/Struct Definition At Run Time


(Ted van Gaalen) #1

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
            // cannot be redefined
        }

        // After successfully declaring our dynamic class,
        // we can now add more features to it, like
        // properties and dynamic extensions. (It is not
        // possible of course to add statically defined extensions
        // and protocols to a non-existing dynamic class at compile time.
        // neither is it possible to do this at run time.)
        
        do
        {
            try Meta.addPropertyTo(Monolith,"mass", 3.4)
            try Meta.addPropertyTo(Monolith,"physics", PhysicsBody)
            try Meta.addExtensionTo(Monolith, someExtensionDefStr)
        }
        catch Meta.classExtenderError
        {
            // handle the error
        }
        catch Meta.classCreationConflict
        {
            // class definition cannot be altered
            // when instances of Monolith (still) exist.
            // This restriction seems to be necessary.
            // Also, static classes defined at compile time
            // cannot be extended dynamically.
        }
    }
    
    ...

    defMonolithClass()
    
    // After having dynamically declared the example class,
    // we can produce instances of it, like with any
    // other class. It throws an error
    // when the dynamic class has not been defined.

    public let monolith = Monolith()
    
    let vol = monolith.volume
    
    monolith = nil // remove instance(s), pre ARC when we wish to
                    // redefine it.

    defMonolithClass() // redefine it, possibly with other definition parameters as in the first definition in this example.

Some examples for additional functionality

let Bird: DynamicClass?

Bird = Meta.defineClass(withString: classDefStr)

Bird = Meta.defineClass(superClass: StaticClass | DynamicClass,
                        interfaces: [Protocol],
                  definitionString: classItemsDefStr)

Bird = Meta.defineCopyOfClass(class: StaticClass| DynamicClass,
                              append: classItemsDefString)

Meta.addpropertyTo(Monolith,
                   name:"mass",initializeWith: 3.4, type: Float)

Meta.addPropertyTo(Monolith,
                name "Person",initializeWith: someValue, type: Inferred)

Meta.addConstantPropertyTo(Monolith,
                name "cow",initializeWithString: aString,
                type: FourLeggedAnimal)

In principle, variants of this could be used to define structs as well.

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, but there are applications where that is acceptable.
Also, there many applications where dynamic entities are not needed,
and therefore relying only on statically defined objects, which run as fast as usual.

I haven't thought (yet) very much about possible side effects and conflicts.
One of the restrictions probably is that one cannot or should not, alter the
class definition (hierarchy) as long as instances of it exist.
  
How to implement this and can it be done? I know almost nothing about
compiler design and construction I assume that it is very complicated,
but if it can be done it would be great, making Swift even more powerful
than it already is.

Interesting?
Of course, there might be better ways to do this, it's just a (my) start of thinking.
Highly appreciate in feedback about this.

This currently is not in a time frame or meant as base for a proposal,

Kind Regards
Tedvg


(Anton Zhilin) #2

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.


(Jeremy Pereira) #3

Not the least of which would be the need to install a Swift compiler toolchain on the target Mac - or iOS device.

···

On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> 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


(David Sweeris) #4

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

···

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.


(Xiaodi Wu) #5

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


(Goffredo Marocchi) #6

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 <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.

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


(Ted van Gaalen) #7

Hi Jeremy

···

On 12 Oct 2016, at 10:52, Jeremy Pereira <jeremy.j.pereira@googlemail.com> wrote:

On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> 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


(Ted van Gaalen) #8

thank you, Goffredo, Anton, see inline
TedvG

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

Sent from my iPhone

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

···

On 11 Oct 2016, at 21:10, Goffredo Marocchi <panajev@gmail.com> wrote:
On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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
            // cannot be redefined
        }

        // After successfully declaring our dynamic class,
        // we can now add more features to it, like
        // properties and dynamic extensions. (It is not
        // possible of course to add statically defined extensions
        // and protocols to a non-existing dynamic class at compile time.
        // neither is it possible to do this at run time.)
        
        do
        {
            try Meta.addPropertyTo(Monolith,"mass", 3.4)
            try Meta.addPropertyTo(Monolith,"physics", PhysicsBody)
            try Meta.addExtensionTo(Monolith, someExtensionDefStr)
        }
        catch Meta.classExtenderError
        {
            // handle the error
        }
        catch Meta.classCreationConflict
        {
            // class definition cannot be altered
            // when instances of Monolith (still) exist.
            // This restriction seems to be necessary.
            // Also, static classes defined at compile time
            // cannot be extended dynamically.
        }
    }
    
    ...

    defMonolithClass()
    
    // After having dynamically declared the example class,
    // we can produce instances of it, like with any
    // other class. It throws an error
    // when the dynamic class has not been defined.

    public let monolith = Monolith()
    
    let vol = monolith.volume
    
    monolith = nil // remove instance(s), pre ARC when we wish to
                    // redefine it.

    defMonolithClass() // redefine it, possibly with other definition parameters as in the first definition in this example.

Some examples for additional functionality

let Bird: DynamicClass?

Bird = Meta.defineClass(withString: classDefStr)

Bird = Meta.defineClass(superClass: StaticClass | DynamicClass,
                        interfaces: [Protocol],
                  definitionString: classItemsDefStr)

Bird = Meta.defineCopyOfClass(class: StaticClass| DynamicClass,
                              append: classItemsDefString)

Meta.addpropertyTo(Monolith,
                   name:"mass",initializeWith: 3.4, type: Float)

Meta.addPropertyTo(Monolith,
                name "Person",initializeWith: someValue, type: Inferred)

Meta.addConstantPropertyTo(Monolith,
                name "cow",initializeWithString: aString,
                type: FourLeggedAnimal)

In principle, variants of this could be used to define structs as well.

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, but there are applications where that is acceptable.
Also, there many applications where dynamic entities are not needed,
and therefore relying only on statically defined objects, which run as fast as usual.

I haven't thought (yet) very much about possible side effects and conflicts.
One of the restrictions probably is that one cannot or should not, alter the
class definition (hierarchy) as long as instances of it exist.
  
How to implement this and can it be done? I know almost nothing about
compiler design and construction I assume that it is very complicated,
but if it can be done it would be great, making Swift even more powerful
than it already is.

Interesting?
Of course, there might be better ways to do this, it's just a (my) start of thinking.
Highly appreciate in feedback about this.

This currently is not in a time frame or meant as base for a proposal,

Kind Regards
Tedvg


(Ted van Gaalen) #9

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.

···

On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

————————————————
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


(Xiaodi Wu) #10

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

···

On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
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> 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


(Ted van Gaalen) #11

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

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 <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.

6. Well meant advice: be a little less lofty,

Kind Regards
TedvG

···

On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:

On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

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


(Xiaodi Wu) #12

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

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
<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.

···

On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com > wrote:

On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen < > tedvgiosdev@gmail.com> wrote:

On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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> 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


(Ted van Gaalen) #13

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@gmail.com> wrote:

On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:
Hi Xiaodi,
please read in-line, thank you.

On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:

On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@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


(Austin Zheng) #14

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 <xiaodi.wu@gmail.com> wrote:

On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen < > tedvgiosdev@gmail.com> wrote:

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

On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen < >> tedvgiosdev@gmail.com> wrote:

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


(Ted van Gaalen) #15

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@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.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:
Hi Xiaodi,
please read in-line, thank you.

On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:

On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@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

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


(David Hart) #16

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.


(Chris Lattner) #17

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:

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

···

On Oct 12, 2016, at 10:14 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

Hello Austin
I haven’t read that from Chris - Must have overlooked it due to the shear volume on swift-evolution.


(Ted van Gaalen) #18

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 <david@hartbit.com> 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 <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.


(Ted van Gaalen) #19

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 <clattner@apple.com> wrote:

On Oct 12, 2016, at 10:14 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> 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


(Xiaodi Wu) #20

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

On 12 Oct 2016, at 21:48, David Hart <david@hartbit.com> 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