[swift-evolution] associated objects

[Ted F.A. van Gaalen]

> What it does is allow developers to extend the language to do things that it doesn't support. 


Hitting boundaries... or so it seems... This is very interesting. 
In spite of its very modern approach, wether we like it or not, Swift is 
still a conventional Hard Coded Statical Programming Language,
 (here further in this text referred to as HCSPL) 
which means that, like in C++ or C# etc. its language 
elements are essentially predefined, "fixed", and that 
it is therefore a daunting task to make the language as 
versatile as possible and to satisfy everyone's requirements, 
We can see that every day in swift-evolution and for that matter 
all other HCSPL (C#, C++, Python, ObjC etc) related forums.

HCSPL are in a sense a traditional compromise to "The Machine” 
and enables us -within the limitations  of our current state of main 
stream technology- to make highly optimised fast running compiled applications. 
That we know is the virtue of hard coded static languages. 
"The Machine" however gets more advanced and faster day by day 
thereby diminishing the need for HCSPL in its course. 

However, (as far as I know) , due to the nature of HCSPL, like Swift, 
there is no (direct and supported and convenient) way supporting 
meta-programming facilities, e.g. to generate define objects (classes), 
and its instances on the fly, that is, at run time. 

In most cases, one can live with this HCSPL "compromise", especially with Swift, 
which is very flexible and offers many convenient ways to solve a wide spectrum 
of programming challenges. However, one could think of many applications like
 in AI where applications can improve and extend themselves, learning to adjust 
and adapt to their environment, thereby altering and tuning its performance, 
like our brains do...naturally. 
In contrast, a HCSPL forces one to match one's problem solving to the language 
elements that are available in the HCSPL. In a sense it's like having a big box 
with Lego bricks, that is predefined discrete elements, which allow one to build things 
with it, however it still remains limited as Lego. 
This is not the case with a dynamic language like Smalltalk.

Since ca 1980 I have a high interest in Smalltalk (and other OOP dynamic
programming languages too). Some would argue that Smalltalk is a 
programming language, but take a closer look, (e.g. with Pharo).
It is just a relatively small set of mainly syntactic rules defining the 
environment wherein the Smalltalk system lives (almost literally) as a 
dynamic object hierarchy, were everything is an object, which as we know 
is a completely different approach compared to HCSPLs.

Before Swift had arrived, my hope was that the successor of Objective C 
would be Smalltalk, or at least Smalltalk  as a breeding environment for 
developing macOS, iOS, tvOS and watchOS applications. In this role it would then
be desirable that the apps thus produced are "closed apps" so to speak, that is that 
the development environment  is not available to the end-user. 
The thought of a e.g. "new Xcode/Smalltalk" being the next Apple development 
environment seemed reasonable, also because ObjectiveC had features 
inspired by Smalltalk. (as all OOP languages have) 
Alas, it didn't happen..but I keep dreaming... 

Perhaps out of context, one then might ask how to interface that 
Xcode/Smalltalk to all those existing libraries (Cocoa UIKit etc.) 
This can be done by letting Smalltalk crawl through all API definitions,
generating its own interface classes dynamically. This sounds ambitious 
but it can be done. Something  a HCSPL like Swift could never do as it is. 

And now we don't have Smalltalk but instead Swift, not bad at all, currently 
I find it the most advanced HCSPL now available.  

However, my verbose text here could be food for thoughts: 

Is it possible to have best of (these completely different) both worlds? 
Would it be possible in Swift to have facilities to generate objects 
dynamically at runtime? and, if desirable, how can such be implemented?


Kind Regards
TedvG

> On Sep 30, 2016, at 9:40 AM, Jay Abbott <jay at abbott.me.uk <mailto:jay at abbott.me.uk>> wrote:

> 

> Robert,

> 

> What it does is allow developers to extend the language to do things that it doesn't support. Associated Objects is just a flexible way to allow developers to do that, and that's how I used it in Objective-C, so that's what I thought of in Swift when I found that "I want to do <x> but the language doesn't support it". Maybe there's a completely different way to achieve the same thing - but I just went with what I know.


"I want to do <x> but the language doesn't support it” is the whole reason for this list!  I want to know what “<x>” is in order to wrap my head around your proposal better. I’m not here to invalidate your work with a slew of criticisms, I’m just trying to understand your proposal by probing you about it.


> So it's difficult to come up with concrete examples of "things a developer might want to do but the language doesn't support" because almost by definition they are unforeseen. I can only enumerate the things I have wanted to do in Obj-C and Swift and how I got around it.

> - Dynamically add properties to a class (obc-c) / implement stored properties (swift).

> - Add per-instance methods at run-time.

> - Perform a function when some other object is deallocated (haven't solved this in Swift yet, but in obj-c associated object deallocation is well-defined so I used that).

> - Other unforeseen things…


Again, these are features and I want motivations behind them.  Why should you be able to dynamically add stored properties and methods to any Swift class?  Why should you be able to observe deallocation if deallocation calls are not guaranteed (remember, Objective-C and Swift do not guarantee -dealloc/deinit calls in any order at any time - please don’t assume an RAII-like model because it will lead to memory leaks and malformed code).

I will say: Perhaps if you’re having trouble motivating the inclusion of this feature, you may want to step back and reevaluate its place in the language and why you wanted to write this library in the first place.  Often times, I find that really helps get the creative juices flowing.  Or, if I can’t come up with anything, it means I go back to step 1 and start over.  Proposals can be as much a learning process for us as it is for you.

> 

> So maybe Associated Objects isn't the answer and I should have stated the problem better, instead of jumping to what I thought the answer might be... the problem I want to solve is this:

> 

> As a developer I want to do <x> but the language doesn't support it... what helpful thing *can* I use right now that allows me to achieve this? I accept the disclaimer by ticking this box:

> [ ] Yes, I understand that I'm not using Swift anymore, but some custom run-time thing that I'm building myself on top of Swift, so if I want type safety I have to implement it, if I want copy-on-write or other optimisations, I have to implement it, and I understand that performance might not be the best too.

> 


So from what I’ve gathered you’ve written a library to do this yourself.  You have a vision for how you want to use this library.  You think that vision is compatible with a language-level change.  From my perspective, your job now is to articulate that vision and motivate it to this list.  I don’t think associated objects and the other dynamic features you mention are fundamentally incompatible with Swift, I just think the design that I’ve seen so far may not be the best way of going about it and I’m voicing my concerns as much.  

> If Swift can provide something to help developers go beyond the abilities the current version, isn't that a good idea?


No one disputes this.  We just want to see your rationale.

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