For URL routing, I would currently suggest generating code at compile time. Someday you might be able to replace this with a macro-based DSL, but for now, I don't see a better option.
On the bright side, this does mean you'll have actual machine code doing your routing, which might be faster than a more dynamic system. Sent from my iPad > On Dec 10, 2015, at 12:22 PM, Matthew Davies via swift-users > <[email protected]> wrote: > > 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 > Director of Photography, OffBlock Films > 209-225-3246 | 209-202-3284 | [email protected] | daviesgeek.com > > > >> 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 >>> Director of Photography, OffBlock Films >>> 209-225-3246 | 209-202-3284 | [email protected] | daviesgeek.com >>> >>> >>> >>>> 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 >>>>> Director of Photography, OffBlock Films >>>>> 209-225-3246 | 209-202-3284 | [email protected] | daviesgeek.com >>>>> >>>>> >>>>> >>>>>> 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
_______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
