11–20 of 74 posts
Earlier quoted context omitted.
What 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?
https://news.ycombinator.com/item?id=4973383
So many of these now. I wonder which one will eventually become the node of Swift.
Earlier quoted context omitted.
What 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?
https://news.ycombinator.com/item?id=4973383
Seems to me like the real challenge in those framework (excepting performance, of course) will be in the orm component. Having a library that can query a db in a typesafe way is a must. Another will be in the concurrency patterns ( promises ? Coroutines ?, etc). But i get a great hope that they will succeed. Having a strong open source community will help. In fact, i'm so fed up with the sad state of uikit right now,…
I wish Apple had not ditched NeXT's EOF. It would make a fine open source project these days.
Seems to me like the real challenge in those framework (excepting performance, of course) will be in the orm component. Having a library that can query a db in a typesafe way is a must. Another will be in the concurrency patterns ( promises ? Coroutines ?, etc). But i get a great hope that they will succeed. Having a strong open source community will help. In fact, i'm so fed up with the sad state of uikit right now,…
I wish Apple had not ditched NeXT's EOF. It would make a fine open source project these days.
The more i think about it, the more i think golang approach is the right one : the only hard part today is concurrency. As long as swift ( and rust for that matter) hasn't standardized patterns that people would use on the whole stack for concurrent access to ressources,as well as asynchronicity, they won't have made the necessary step to truely advance the state of the art.
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.
Seivan, 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?
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") :)
Earlier quoted context omitted.
I wish Apple had not ditched NeXT's EOF. It would make a fine open source project these days.
WebObjects was open sourced, was it not? (Although I don't know about the objective-c component).
Earlier quoted context omitted.
I wish Apple had not ditched NeXT's EOF. It would make a fine open source project these days.
I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access). The more i think about it, the more i think golang approach is the right one : the only hard part today is concurrency. As long as swift ( and rust for that matter) hasn't standardized patterns that people would use on the whole stack for concurr…
EOF is not Core Data and Core Data is not from the NeXT era.