Hi all,
As I learn Swift, I got 2 questions here:
1. Is there any module initialization and deinitialization concept in Swift (v.3)? For example, upon loading a module, I want that module to do something before being utilized (initialization) or after being utilized (deinitialization). If there is, is there any example of how to do that?
2. If within a scope, I'd like to access to an instance or variable out of current scope which having an exact name, is it possible? Consider this code:
var i = 5for i in 1...10 { let i = 10 print(i)}
Is there a way to print the 'i' of the let, and the 'i' of the loop, and the 'i' of the var, from inside of the for loop? I know it's a bad practice, but I'm just curious.
Thank you.
Regards,
–Mr Bee
No, there is no way of referring to them because their names are shadowed by the inner variable. That’s why it’s a bad practice.
—Jens
···
On Dec 19, 2016, at 12:37 AM, Mr Bee via swift-users <swift-users@swift.org> wrote:
Is there a way to print the 'i' of the let, and the 'i' of the loop, and the 'i' of the var, from inside of the for loop? I know it's a bad practice, but I'm just curious.
No.
For initialisation, the standard approach in Swift is to exploit the fact that globals are initialised lazily on first use.
If you’re interested in some of the background to this, there’s lots of interesting points of view on this swift-evolution thread.
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028914.html>
Share and Enjoy
···
On 19 Dec 2016, at 08:37, Mr Bee via swift-users <swift-users@swift.org> wrote:
1. Is there any module initialization and deinitialization concept in Swift (v.3)?
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
Also, AFAIK there is no mechanism in Swift (yet) to load or unload a module at runtime, so a module load occurs when the program starts up, and an unload occurs when the program exits.
So if your module really needs to do something to clean up, it could call the (C standard) function atexit() to install a callback.
—Jens
dlopen works fine, though the only supported ways of getting a callable symbol out of the loaded image are currently to use a C entry point or look up a type defined in the module by name. Unloading Swift modules will likely never be supported, since this would impose a ton of complexity and performance cost on the runtime for little benefit. (Apple's ObjC runtime does not support unloading dylibs after classes inside them have been reified either.)
-Joe
···
On Dec 20, 2016, at 8:54 AM, Jens Alfke via swift-users <swift-users@swift.org> wrote:
Also, AFAIK there is no mechanism in Swift (yet) to load or unload a module at runtime, so a module load occurs when the program starts up, and an unload occurs when the program exits.
Unloading Swift modules will likely never be supported, since this would impose a ton of complexity and performance cost on the runtime for little benefit.
Hmmm… so Swift will only support static linking? I thought Swift is a modern programming language with modern and advance features. Even Pascal/Delphi has had those features since ages ago.
–Mr Bee
Pada Kamis, 22 Desember 2016 1:06, Joe Groff via swift-users <swift-users@swift.org> menulis:
···
On Dec 20, 2016, at 8:54 AM, Jens Alfke via swift-users <swift-users@swift.org> wrote:
Also, AFAIK there is no mechanism in Swift (yet) to load or unload a module at runtime, so a module load occurs when the program starts up, and an unload occurs when the program exits.
dlopen works fine, though the only supported ways of getting a callable symbol out of the loaded image are currently to use a C entry point or look up a type defined in the module by name. Unloading Swift modules will likely never be supported, since this would impose a ton of complexity and performance cost on the runtime for little benefit. (Apple's ObjC runtime does not support unloading dylibs after classes inside them have been reified either.)
-Joe
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Swift supports dynamic linking just fine; like I said, "dlopen" works.
-Joe
···
On Dec 21, 2016, at 7:11 PM, Mr Bee <pak.lebah@yahoo.com> wrote:
> Unloading Swift modules will likely never be supported, since this would impose a ton of complexity and performance cost on the runtime for little benefit.
Hmmm… so Swift will only support static linking? I thought Swift is a modern programming language with modern and advance features. Even Pascal/Delphi has had those features since ages ago.
Sorry for not being clear. My english isn't very good either.
What I meant was static module linking (loading and unloading) for Swift modules. Also with initialization and deinitialization for Swift modules.
It's alright then. I just want to make sure. I'm a Pascal/Delphi programmer and sometimes I rely on such features in my applications. As a new and considered as modern programming language, I thought Swift would provide more advance features than Pascal/Delphi does.
Thank you.
–Mr Bee
Pada Kamis, 22 Desember 2016 10:12, Joe Groff <jgroff@apple.com> menulis:
···
On Dec 21, 2016, at 7:11 PM, Mr Bee <pak.lebah@yahoo.com> wrote:
> Unloading Swift modules will likely never be supported, since this would impose a ton of complexity and performance cost on the runtime for little benefit.
Hmmm… so Swift will only support static linking? I thought Swift is a modern programming language with modern and advance features. Even Pascal/Delphi has had those features since ages ago.
Swift supports dynamic linking just fine; like I said, "dlopen" works.
-Joe
Many of us also depend upon dynamic linking, but the runtime for Swift (and Objective-C) is far more complex than just loading new code.
When loading code, there are things that "just happen" -- such as class extensions -- that need to be unlinked when the dynamic library is unloaded. For one thing if you had objects created while the class extension was available, those objects would have to be "re-written" to not use the class extension any more. If the extension allocated additional memory, that memory would be orphaned.
Dynamic languages are far more complex than static languages like Pascal and Delphi...
···
On Dec 21, 2016, at 7:29 PM, Mr Bee via swift-users <swift-users@swift.org> wrote:
Sorry for not being clear. My english isn't very good either.
What I meant was static module linking (loading and unloading) for Swift modules. Also with initialization and deinitialization for Swift modules.
It's alright then. I just want to make sure. I'm a Pascal/Delphi programmer and sometimes I rely on such features in my applications. As a new and considered as modern programming language, I thought Swift would provide more advance features than Pascal/Delphi does.
Thank you.
–Mr Bee
--
Glenn L. Austin, Computer Wizard and Race Car Driver <><
<http://www.austinsoft.com>
I'd be interested to hear what you need these features for. Delphi was a direct descendent of Turbo Pascal, which came from a platform with extreme memory constraints and a not-very-sophisticated memory, so loading and unloading modules to save memory may have made sense. On a modern platform with virtual memory, loading an executable image does not take up much actual memory, since the majority of pages in most executables are read-only and can be memory-mapped in and out from disk on demand. Even if you unload a module, the dynamic linker should not reuse the address space that module was mapped into when loading other modules for security reasons (an attacker could turn a dangling function pointer in the host process into a JOP vector by remapping new code there). Also for security reasons, a modern application ought to favor an out-of-process extension model to dynamically loading code in-process; there are no problems cleanly spawning and killing a plug-in process.
As for load-time initialization, that is well-known to be a problematic feature in languages that support it, and it is not the only nor the best approach to solving the problems it's applied to—see [swift-evolution] Global init() functions for a discussion of the problems with load-time initializers and alternative features that solve the same problems in a more robust way. Exit-time deinitialization is also problematic, since there's no way in practice to guarantee that cleanups happen before a process dies, so code that relies on them is fundamentally brittle and prone to corrupting user data. It's also at odds with the modern macOS and iOS process model, which expects to be able to terminate UI processes at any point.
-Joe
···
On Dec 21, 2016, at 7:29 PM, Mr Bee <pak.lebah@yahoo.com> wrote:
Sorry for not being clear. My english isn't very good either.
What I meant was static module linking (loading and unloading) for Swift modules. Also with initialization and deinitialization for Swift modules.
It's alright then. I just want to make sure. I'm a Pascal/Delphi programmer and sometimes I rely on such features in my applications. As a new and considered as modern programming language, I thought Swift would provide more advance features than Pascal/Delphi does.