2 ms·
You could make it shorter by using something like sinatra[1]. Here is my pseudo-sinatra code. get "/list_student_ids" do STUDENTS.key_set end delete
by jeltz 15y ago
You could make it shorter by using something like sinatra[1]. Here is my pseudo-sinatra code.
get "/list_student_ids" do
STUDENTS.key_set
end
delete "/delete_student/:uid" do
STUDENTS.remove(params[:uid]) or raise WebApplicationException, Response::Status::NOT_FOUND
true
end
1. http://www.sinatrarb.com/ http://www.sinatrarb.com/
- nupark2 15y agoYour savings here are mainly from removing types. That's another matter entirely.
- jeltz 15y agoI would say they are mainly from removing the need for decorators due to there being a nice lambda function/block syntax. So we can define methods like "get" and "delete" which does the job of the decorators, creating something kind of like a mini-DSL. Some savings through the removal of types, sure, but that is not what I personally see as most import here.
- masklinn 15y ago1. Thing's most of those types provide no value in being spelled out like that. The ones on the methods have documentary advantages, but that's about it, the rest is magical invocations to make a stupid compiler happy. 2. There's also a gain from the framework being able to map things to each other without being told explicitly. `@PathParam("uid")` for instance, it's only there because the framework has no way to match the parameter name `uid` to the URL-extracted parameter `uid`. Likewise with HTTP methods being part of the routing instead of a separate annotation, in part. 3. Java's APIs and type system, such as implicit nulls and not being able to use arbitrary types in boolean contexts