> On Nov 19, 2016, at 10:07 AM, Alan Cabrera via swift-evolution
> <[email protected]> wrote:
>> On Nov 19, 2016, at 9:27 AM, Jean-Daniel <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> Le 19 nov. 2016 à 15:58, Alan Cabrera via swift-evolution
>>> <[email protected] <mailto:[email protected]>> a écrit :
>>>
>>> I’m not sure if this was proposed or not; or even if this is a Swift-ly way
>>> of doing things. It would be pretty handy to be able to declare init()
>>> functions in my module to register handlers. It’s a common pattern in
>>> enterprise software.
>>>
>>> Currently, I have to generate a lot of boilerplate code to emulate the
>>> behavior. I think it would be cleaner to have these global init()
>>> functions.
>>>
>>
>> I’d rather like a swift attribute equivalent to :
>> __attribute__((constructor))
>>
>> It will not force me to call my initializer init, and moreover it will let
>> me declare multiple functions so I would be able to register multiples
>> handlers from a single module without having to group all the register call
>> into a single init() function.
>>
>
> I’m not quite following what “__attribute__((constructor))” means; it looks
> like an LLVM implementation bit. Do you mean defining a new Swift
> declaration attribute named “constructor”? If so, I really like that idea.
> I think that the specific attribute name “constructor” may be a bit confusing
> though, since it’s not really constructing anything specific. Maybe
> “startup” would be a more descriptive attribute name?
>
> @startup
> func registerHandlers() {
> }
>
> The attribute would also help the compiler and IDEs prevent direct calling of
> the startup functions, thus reinforcing/focusing the startup functions’ role
> as global startup functions. Maybe global teardown functions would be
> helpful as well.
>
> I’m going to try goofing around with the idea on my fork.
Some sort of reflective discovery would be better, I think. Eager global
initialization is superficially attractive — what could be simpler than just
running some code at program launch? — but as a program scales up and gains
library dependencies, it very quickly runs into problems. What if an
initializer depends on another already having been run? What if an initializer
needs to be sensitive to the arguments or environment? What if an initializer
need to spawn a thread? What if an initializer needs to do I/O? What if an
initializer fails? Global initialization also has a lot of the same
engineering drawbacks as global state, in that once you've introduced a
dependency on it, it's extremely hard to root that out because entire APIs get
built around the assumption that there's no need for an explicit
initialization/configuration/whatever step. And it's also quite bad for launch
performance — perhaps not important for a server, but important for pretty much
every other kind of program — since every subsystem eagerly initializes itself
whether it's going to be used or not, and that initialization generally has
terrible locality.
John.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
