[swift-evolution] associated objects

[Ted F.A. van Gaalen]

Hi Chris
I am a bit slow to respond, please read inline, thanks.
> On 1 Oct 2016, at 01:47, Chris Lattner <clattner at apple.com> wrote:
> 
> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:

>> Is it possible to have best of (these completely different) both worlds? 
> 

> Yes, of course it is.  

> Your email spends a lot of words
Does it? 

> trying to form a false dichotomy.
Well, sorry, thank you. but No, I don’t think so: 
I am merely describing the advantages and 
disadvantages of static programming languages. 
It doesn’t mean it should be one or the other, just observing.
Just thinking about the future in years, not in weeks. 
Even so, I still like Swift.

> Swift can definitely have both awesome dynamic features while still having performance, predictability and safety.
Yes, I take it that it is possible to implement these. 
Currently it is not possible to do meta programming in Swift, that is, create 
arbitrary functions, properties and new classes
during run time. hypothetical along the lines as if it were so:

    // Warning! hypothetical as yet not compilable coding follows:

    let Monolith: Class?
    
    var classdefstring = "parentclass: SpaceObject;" +
            "var l = 9.0; var h = 4.0; var  w = 1.0; " +
            "var color = " + defaultMonolithColorStr   +
            ";func volume() -> Double { return l * w * h} “ +
            aStringWithAdditionalComponentDefinitions

    func defMonolithClass()
    {
        do  // try to define a class, NOT an instance.
        {
            try Monolith = Meta.defineClass(classdefstring)
        }
        catch Meta.classDefinitionError
        {
            // handle a possible class definition error
            // e.g. syntax errors. symbols not found etc.  
        }
        catch Meta.creationConflict
        {
            // class cannot be defined or redefined when instances of Monolith exist.
            // necessary?
        }

        do  // dynamically add components to the Monolith
        {
            try Meta.addPropertyTo( Monolith,"mass",    3.4)
            try Meta.addPropertyTo( Monolith,"physics", PhysicsBody)
            try Meta.addFunctionTo( Monolith, someFunctionDefinitionString)
        }
        catch Meta.ClassExtenderError
        {
            // handle the error
        }
        catch Meta.creationConflict
        {
            // class definition cannot be altered when instances of Monolith exist.
            // necessary? 
        }
    }
    
    defMonolithClass()
    
    // Make an instance of the dynamically generated class
    public let mn = Monolith() 
    
    let vol = mn.volume
    
    // One can remove after usage, normally ARC should take care of that.
    // unless one would wish to reinstate/redefine Monolith again.
    mn = nil       // remove instance

    Monolith = nil  // should throw an error when instances of Monolith are still around.

    defMonolithClass()  // again, possibly with other definition strings 

    // Of course ARC should remove dynamic class defs automagically when no longer
    // needed. 
    
There could be overloads of defining classes etc. using other methods than string wise declaration.. 
Of course, Meta… for defining structs and other components could be made in a similar fashion.
I’d guess  that it might be very hard and complicated to implement meta creation similar to the above? 
Probably needed the app to interact many times with a compiler present on the target OS/device? - 
thereby making small pluggable “bricks”  
Just brainstorming here: I know nearly nothing of compiler construction.

> 
>> Would it be possible in Swift to have facilities to generate objects 
>> dynamically at runtime? and, if desirable, how can such be implemented?
> 
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection <https://github.com/Zewo/Reflection>
Very complex code (to me, hard to read) . As far as I can see, it’s a clever hack but vulnerable because 
depending completely on the underlying memory occupation and layout of an existing class definition?  
Totally new classes/structs etc. cannot be defined with it?
(like in the above hypothetical class def example)

> 
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have bandwidth to reevaluate this area from first principles, I’m sure we can make improvements on it.
Yeah, I guess it can be done, that would be great!
> 
> I will grant you that Smalltalk is a beautiful language in its simplicity, but for that simplicity it makes many tradeoffs that we’re not willing to make.  
The only tradeoffs I can think of so far are:

  - Run time speed. in spite of precompiled methods etc Smalltalk is not so fast as compiled statical 
programming language executables. However, the VMs are getting much better/ faster 
these days. Dedicated hardware (processors) would really help too.

 - Total freedom, but to me personally this is not a tradeoff at all…

 - what else?  

> We are willing to make the internal implementation of Swift complex if that means that we get a beautiful model for programmers -
> one that preserves the virtues of safety-by-default,
Safety by default? to some extend, yes. However, my experience with many programming 
languages is, that it almost doesn’t matter how much effort is given
to make a PL save. I am still traumatised by many [some words removed here]  
source code through all the years I had to work with 
(of course only others are writing baaaaaaad code, naturally, I myself am perfect :o) 

> predictability, performance, and joy-to-develop-in.
Yes, I enjoy working with Swift very much as well, thank you (and others) for creating this language.
> 
> The meme of “Swift can never (or will never) support dynamic features” is tired, and also wildly inaccurate.
That was a bit overcharged from me. I had that impression, being not too broadly informed in this meta stuff. 
Met vriendelijke groeten, kind regards, one of your colleagues/friends from another time :o) 
TedvG


> 
> -Chris
> 

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