In the past, I’ve seen issues with these sorts of module initialization functions:
- They promote a high degree of coupling between a module and its dependencies. Given an example of a test framework, you’ll see tests which support a single implementation of a test runner, with a globally registered/unorganized bundle of tests. - Without an initialization order, you can be pretty limited in your ability to depend on other parts of the system. This leads your startup routine to be rather static. - Likewise, you may want code to be run at some point other than initialization time, or you may depend on other components being initialized first. You might be able to depend on the startup routines of modules you depend on being initialized by nature of the system being a DAG, but peer modules may or may not run before you - Finally, these systems often wind up depending on global state, which is generally a design anti-pattern. You typically want to supply the dependencies to a module (the D in SOLID) I would prefer a more generalized version of @NSApplicationMain / @UIApplicationMain that supported possibly multiple implementers of a user protocol. Then, implementations of the protocol could be called when desired, with appropriate state, based on the logic of the framework defining said protocol. -DW > On Nov 19, 2016, at 11: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. > > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
