3 ms·
You could have made it better by using protocols for the actions. So the methods for adding routes would ensure that the methods for new and update exists using
by seivan 11y ago
You could have made it better by using protocols for the actions. So the methods for adding routes would ensure that the methods for new and update exists using a where clause checking protocol conformance.
There is potential here, I like a "full" package like "Omakase", granted its built using Swifts strength and a pipeline model like Express.js and/or Rails and its rack middlewares.
- necolt 11y agoSeivan, thanks. Yes, Rails "Omakase" is driving Swifton development. I'm not sure that protocols will help here, because Swifton supports before/after filter. Could you explain more your idea about how protocols could help here to implement actions with filters?
- ihuman 11y agoWhat do you mean by Rails Omakase? All I could find is a blog post by DHH saying that "Rails is Omakase." Is there more to it than that?
- necolt 11y agohttps://news.ycombinator.com/item?id=4973383 https://news.ycombinator.com/item?id=4973383
- ihuman 11y agoI've seen the blog post, I was just wondering if there was more to it than that.
- necolt 11y agoI believe DHH first started to use "Omakase" term in Rails context, so his blog post and discussions afterwards is good place to check. You can alse check original Omakase https://en.wikipedia.org/wiki/Omakase https://en.wikipedia.org/wiki/Omakase .
- steveklabnik 11y agoOthers have given you good links behind the idea; I wrote a blog post about one of the ecosystem effects a while back: http://words.steveklabnik.com/rails-has-two-default-stacks http://words.steveklabnik.com/rails-has-two-default-stacks
- seivan 11y agoSure, here https://gist.github.com/seivan/6b6bb19c899dd46f599e https://gist.github.com/seivan/6b6bb19c899dd46f599e I might fork and do my own version where I try to adhere to Swifts strengths while still staying close to Rails API where I can, e.g same naming scheme and pipeline design as Rails. Rails biggest weakness is Ruby. Leveraging Swifts strengths with protocol extension, where clauses and generics could actually improve on Rails current API. Edit[0]: Added an idea for filter API. Not happy with it, but it's a start. Before/After filters could just be a list of "stuff" (selectors, closures, etc) to be called before any action. It could also use group_dispatch to ensure that filters are called in sequence and only call the method once all filters are done. group_dispatch (think semaphores, but not as "dangerous") :)
- necolt 11y agoSeivan, thanks for your gist. I also tried to make controllers more protocol oriented, but it didn't help much with nice DSL for filters. Let's keep trying, maybe something beautiful will born soon. I would love to see you Swifton fork with your experiments. I think Ruby is both strength and weakness of Rails. From my 10 years experience with large scale and large codebase Rails projects I can say that Ruby dynamism helps in web development. But for sure it comes with really high price tag.
- equalarrow 11y agoRails biggest weakness is Ruby?!?! The only reason Rails came about (so says DHH) is because of Ruby and its expressiveness as a dynamic language. Granted, we're in Swift mode here and it's static typing, protocols, generics, and closures all the way. I'm fine with this (I write in Swift everyday) but Ruby is a great language as well - I love them both. I think there's a place for both static and dynamic typed languages and I'm not going to throw away Ruby just because Swift is more "correct" with typing. Having worked on my own Swift web framework for the past few months, and Rails for years, we're not even close to approaching Rails feature set. Rails has been in active development for over a decade and it's going to take a while for a Swift framework to make some inroads.
- seivan 11y ago