I'm building a URL router in which I'd like to pass a controller and a method. I don't want to instantiate all the controllers up front and pass the methods in as closures, nor do I want old controller instances still kept around. If there's a better way, I'm definitely open to any suggestions. I'm still learning the "Swift" way to do things.
*Matthew Davies* Junior Developer, GeoStrategies <http://geostrategies.com> Director of Photography, OffBlock Films <http://offblockfilms.com> 209-225-3246 <209-225.3246> | 209-202-3284 | [email protected] | daviesgeek.com <http://facebook.com/daviesgeek> <http://us.linkedin.com/in/daviesgeek> <http://twitter.com/daviesgeek> <http://daviesgeek.com/feed.xml> <http://github.com/daviesgeek> On Thu, Dec 10, 2015 at 10:47 AM, Dan Stenmark <[email protected]> wrote: > NSSelectorFromString() is still available in Swift, and you should be able > to use the result of that in performSelector, though I’m hesitant to > support this approach as it flies in the face of the safety Swift tries to > enforce. I’m curious about your use case here; are you trying to create > some kind of dynamic proxy for a remote object ala NSXPCConnection? > > Dan > > On Dec 10, 2015, at 10:33 AM, Matthew Davies via swift-users < > [email protected]> wrote: > > Ooh okay. I think that should work for my purposes. Thanks. > > Somewhat related to this, how would I then call a method dynamically on an > instance of the class, after instantiating it? > > --- > class Graph { > func call(method: String) { > // Something goes here > } > > func redraw() -> String { > return "Redraws" > } > } > > let inst = Graph() > inst.call("redraw") > --- > > > *Matthew Davies* > Junior Developer, GeoStrategies <http://geostrategies.com/> > Director of Photography, OffBlock Films <http://offblockfilms.com/> > 209-225-3246 <209-225.3246> | 209-202-3284 | [email protected] | > daviesgeek.com > <http://facebook.com/daviesgeek> <http://us.linkedin.com/in/daviesgeek> > <http://twitter.com/daviesgeek> <http://daviesgeek.com/feed.xml> > <http://github.com/daviesgeek> > > > On Thu, Dec 10, 2015 at 10:18 AM, Daniel Dunbar <[email protected]> > wrote: > >> Note that you can define a protocol which will allow your framework to >> instantiate the type, and to call methods on instances of that type. If you >> can structure your code in this fashion, it can be very elegant in that it >> doesn't require factory functions and it is type safe. >> >> For example: >> -- >> struct GraphableDescription { } >> >> protocol Graphable { >> /// Construct a graphable item from a description. >> init(description: GraphableDescription) >> >> func graph() >> } >> >> // Example framework method. >> func graphItem(description: GraphableDescription, graphable: >> Graphable.Type) { >> // Instantiate the graphable. >> let item = graphable.init(description: description) >> >> // Graph it. >> item.graph() >> } >> >> // Example Graphable client. >> struct Circle: Graphable { >> init(description: GraphableDescription) { } >> >> func graph() { } >> } >> >> // Example framework client. >> func foo() { >> graphItem(GraphableDescription(), graphable: Circle.self) >> } >> -- >> >> - Daniel >> >> On Dec 10, 2015, at 9:59 AM, Matthew Davies via swift-users < >> [email protected]> wrote: >> >> I don't really like the idea of a factory function, but unfortunately >> that might be the only way to do it :( However, due to my specific use >> case, I don't think a factory function will work. I'm working on a >> framework that will need to both instantiate the class from a string (or >> class type) *and* call methods dynamically on it. Which, I'm not sure I >> can do in the build tools that are provided in the open source package. >> Foundation hasn't been fully implemented and is missing a lot of the >> methods that would allow this to work. >> >> @Jens thanks for that blog post. I'll have to make sure I check back to >> see what his solution is for it. >> >> >> >> >> *Matthew Davies* >> Junior Developer, GeoStrategies <http://geostrategies.com/> >> Director of Photography, OffBlock Films <http://offblockfilms.com/> >> 209-225-3246 <209-225.3246> | 209-202-3284 | [email protected] | >> daviesgeek.com >> <http://facebook.com/daviesgeek> <http://us.linkedin.com/in/daviesgeek> >> <http://twitter.com/daviesgeek> <http://daviesgeek.com/feed.xml> >> <http://github.com/daviesgeek> >> >> >> On Thu, Dec 10, 2015 at 9:30 AM, Jan Neumüller <[email protected]> >> wrote: >> >>> Please no factory madness in Swift. This stuff is bad enough in Java - >>> don’t infect Swift with it. >>> >>> Jan >>> >>> On 10.12.2015, at 18:23, Jens Alfke via swift-users < >>> [email protected]> wrote: >>> >>> >>> On Dec 10, 2015, at 7:26 AM, Harlan Haskins via swift-users < >>> [email protected]> wrote: >>> >>> IIRC this isn’t possible because there’s no Runtime to query for >>> classnames (it’s inherently unsafe anyway). >>> >>> >>> It’s not unsafe if you specify a base class/protocol that the loaded >>> class must conform to. >>> >>> You might want to look into a better way of doing that you’re trying to >>> do. >>> >>> >>> I disagree with “a better way” — “a workaround” is how I’d rephrase it. >>> This kind of dynamism is often the best tool for the job, and a lot of >>> Cocoa developers are frustrated by its absence in Swift. For example, >>> there’s a series of blog posts from earlier this year by the highly >>> respected Brent Simmons [NetNewsWire, MarsEdit, Glassboard, etc., currently >>> at Omni]: >>> http://inessential.com/swiftdiary >>> http://inessential.com/2015/07/20/swift_diary_1_class_or_struct_from_str >>> >>> The workaround I’d suggest is a factory function that contains a switch >>> statement that matches class names and returns newly initialized instances. >>> >>> —Jens >>> _______________________________________________ >>> swift-users mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-users >>> >>> >>> >>> _______________________________________________ >>> swift-users mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-users >>> >>> >> _______________________________________________ >> swift-users mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-users >> >> >> > _______________________________________________ > swift-users mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-users > > >
_______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
