|
Kevin Mitnick P.E. posted:the problems start when you need to go someplace that spring boot is not designed for yes fair enough, if you use a framework for something that it's not designed for, it won't work as well but that's a fairly generic argument (<T>) you can use for anything curious to hear what kind of things you've seen people try to shoehorn into a spring boot application then
|
# ? Oct 10, 2018 21:37 |
|
|
# ? Jun 11, 2024 22:38 |
|
Sagacity posted:yes fair enough, if you use a framework for something that it's not designed for, it won't work as well yeah maybe i just don't like framework. "this codebase will never need to do anything beyond the framework's design" feels to me like a strong claim to make but then I've only had one job doing a crud app. and that time i got tasked with integrating an ecommerce framework into the spring boot poc my boss did. it didn't go well
|
# ? Oct 10, 2018 23:01 |
|
c# doesn't have return type covariance If Flower has subclass Rose; and FlowerSeller has subclass RoseSeller; and FlowerSeller::Sell is declared to return Flower; RoseSeller::Sell cannot be declared to return Rose I mean I know this can be worked around somewhat using some annoying CRTP-like generic arguments but seriously "C++ has it" is not a good argument for many specific nibs and nubs of inheritance etc. but this is a good and useful thing that C++ had a loving while ago https://github.com/dotnet/csharplang/issues/49 e: checked and yes, java has this. C#, YOOPLPOS ee: yes, this is (in my experience) the first language-level thing that Java has over C# prisoner of waffles fucked around with this message at 17:00 on Oct 11, 2018 |
# ? Oct 11, 2018 16:57 |
|
isn't the recursive typedef how you work around this in java
|
# ? Oct 11, 2018 17:05 |
|
Enum<E extends Enum<E>>
|
# ? Oct 11, 2018 17:06 |
|
tef posted:isn't the recursive typedef how you work around this in java no not as of tyool 2004 https://blogs.oracle.com/sundararajan/covariant-return-types-in-java
|
# ? Oct 11, 2018 17:12 |
|
iirc Java enums are way better than C#
|
# ? Oct 11, 2018 19:29 |
|
i think the fact that kludging it in when you need it isn't too painful (thanks method hiding) means that it's not gonna show up for awhile, if ever.
|
# ? Oct 11, 2018 19:33 |
|
Janitor Prime posted:iirc Java enums are way better than C# swift enums own bones
|
# ? Oct 11, 2018 21:18 |
|
Janitor Prime posted:iirc Java enums are way better than C# definitely
|
# ? Oct 11, 2018 21:21 |
|
Krankenstyle posted:swift enums own bones
|
# ? Oct 11, 2018 22:51 |
|
swenums
|
# ? Oct 11, 2018 22:55 |
|
where's that flow chart for deciding api response codes i need to respond with a "the thing you asked for with your parameters doesnt exist although this method does " but 404 feels kinda misleading and im wondering if there are more descriptive alternatives
|
# ? Oct 11, 2018 23:18 |
|
it doesn't matter what the gently caress you return because no one can agree on any of it. just pick something and write good documentation.
|
# ? Oct 11, 2018 23:23 |
|
at the very least I'd say a generic 400 is better than 404 maybe 422 Unprocessable Entity? The request was well-formed but was unable to be followed due to semantic errors.
|
# ? Oct 11, 2018 23:34 |
|
The webmachine diagram? https://raw.githubusercontent.com/wiki/webmachine/webmachine/images/http-headers-status-v3.png I don't think there's an error code corresponding to "this collection of objects does exist, but not the object you requested" So just make it up
|
# ? Oct 11, 2018 23:39 |
|
the most treacherous code in any project is anyway code that tries to "handle" an error, so reporting a very accurate error code is just inspiring bad thinking. as likely as anything something is wrong with the process state, and the best bet is to crash pretty hard and spin all state up fresh (i.e. the erlang insight)
|
# ? Oct 11, 2018 23:46 |
|
Bloody posted:where's that flow chart for deciding api response codes i need to respond with a "the thing you asked for with your parameters doesnt exist although this method does " but 404 feels kinda misleading and im wondering if there are more descriptive alternatives I like the flow charts on this page http://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html
|
# ? Oct 11, 2018 23:59 |
|
Cybernetic Vermin posted:the most treacherous code in any project is anyway code that tries to "handle" an error, so reporting a very accurate error code is just inspiring bad thinking. as likely as anything something is wrong with the process state, and the best bet is to crash pretty hard and spin all state up fresh (i.e. the erlang insight) iow all that matters is the first digit of the status code
|
# ? Oct 12, 2018 02:15 |
|
Bloody posted:where's that flow chart for deciding api response codes i need to respond with a "the thing you asked for with your parameters doesnt exist although this method does " but 404 feels kinda misleading and im wondering if there are more descriptive alternatives That would be rather dangerous for many obvious reasons, but you can always provide a body with a 404 that provides the information. A basic spellchecking router could just response with a 301 or 308 though.
|
# ? Oct 12, 2018 02:37 |
|
Fiedler posted:it doesn't matter what the gently caress you return because no one can agree on any of it. just pick something and write good documentation.
|
# ? Oct 12, 2018 03:47 |
|
pokeyman posted:I like the flow charts on this page http://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html Bookmarked, thanks
|
# ? Oct 12, 2018 04:01 |
|
Bloody posted:where's that flow chart for deciding api response codes i need to respond with a "the thing you asked for with your parameters doesnt exist although this method does " but 404 feels kinda misleading and im wondering if there are more descriptive alternatives return 200 and a zipped PDF containing a bitmap rendering of the backtrace for the error be sure to use CCITT Group IV Fax encoding, make the image like 1200 DPI with one bit per CMYK channel, put the image origin at bottom right, and break the image into tiles eschaton fucked around with this message at 05:26 on Oct 12, 2018 |
# ? Oct 12, 2018 05:21 |
|
respond with "GET ~/Documents/mom/shower7.png", maybe the client will get confused and it'll work
|
# ? Oct 12, 2018 05:46 |
|
rjmccall posted:respond with "GET ~/Documents/mom/shower7.png", maybe the client will get confused and it'll work
|
# ? Oct 12, 2018 06:25 |
|
rjmccall posted:respond with "GET ~/Documents/microwavemom/shower7.png", maybe the client will get confused and it'll work
|
# ? Oct 12, 2018 14:40 |
|
Krankenstyle posted:swift enums own bones
|
# ? Oct 13, 2018 14:18 |
|
rust enums, also good. I'm a big fan of the error handling in rust and being able to return enums which have differing content is super useful
|
# ? Oct 13, 2018 14:33 |
|
prisoner of waffles posted:c# doesn't have return type covariance Seller<T> where T : Flower T Sell Done. Right? If you really have to, RoseSeller : Seller<Rose> I bet Java has it because of type erasure. havelock fucked around with this message at 23:58 on Oct 17, 2018 |
# ? Oct 17, 2018 23:54 |
|
java generates two methods
|
# ? Oct 18, 2018 00:19 |
|
I really hate that in Java you can't overload functions in this way:Java code:
|
# ? Oct 18, 2018 05:49 |
|
Kevin Mitnick P.E. posted:java generates two methods type erasure is part of generics and return type covariance doesn't involve type variables to what could get erased code:
If you have a B reference then you can do B tmp = b.getThis(); which will generate a call to B.getThis()LB;. Thus B needs a second method. You can imagine this continuing with a class C extends B that overrides again and ends up with two synthetic methods, and so on. This all works because while Java doesn't allow overloading on return type, the JVM does. Method calls in JVM bytecode include the return type as part of the reference so it's never ambiguous.
|
# ? Oct 18, 2018 14:40 |
|
havelock posted:Seller<T> where T : Flower yes. almost. as you wrote it, Seller<Rose> is not a subclass of Seller<Flower>. To fix that we gotta use a covariant type parameter. code:
code:
code:
I take no pleasure in this as I would love to just be able to say, "C# is uniformly better than java" thank's for you're service
|
# ? Oct 18, 2018 15:47 |
|
jit bull transpile posted:I really hate that in Java you can't overload functions in this way: hmm, is there anything wrong with Java code:
|
# ? Oct 18, 2018 15:51 |
|
prisoner of waffles posted:hmm, is there anything wrong with E.g would a method that either takes a list of strings or a list of urls be possible in java?
|
# ? Oct 18, 2018 16:03 |
|
No because of type erasure. void doTheThing(List<String>) and void doTheThing(List<URL>) both erase to void doTheThing(List). You will get an error at compile time if you put each method on an interface and try to implement both interfaces on a single class.
|
# ? Oct 18, 2018 16:15 |
|
prisoner of waffles posted:
What scenarios would you find this useful in? For consumers of your classes, they are already likely only hanging on to references to your base class, so the fact that the return type is more specialized doesn't help them. The only scenario I can think of is when you're implementing a new derived class, because in that case you aren't dealing with polymorphism, i.e., you're a RoseSeller so you know you sell Roses, vs. everyone else just dealing with Sellers and Flowers. Are there other things I'm missing? I'm sure I've run across one or two over the years but it was never enough to make me feel like the language had a huge omission. As long as you stick to claiming "uniformly better" instead of "strictly more expressive" then I think you're fine.
|
# ? Oct 18, 2018 16:31 |
|
havelock posted:What scenarios would you find this useful in? For consumers of your classes, they are already likely only hanging on to references to your base class, so the fact that the return type is more specialized doesn't help them. The only scenario I can think of is when you're implementing a new derived class, because in that case you aren't dealing with polymorphism, i.e., you're a RoseSeller so you know you sell Roses, vs. everyone else just dealing with Sellers and Flowers. in a java context it lets you have things like code:
sure, you can just not chain methods or w/e, but it’s nice to have the option
|
# ? Oct 18, 2018 17:08 |
|
prisoner of waffles posted:yes. almost. as you wrote it, Seller<Rose> is not a subclass of Seller<Flower>. To fix that we gotta use a covariant type parameter. that really isn't the hard way. if you have coworkers who argue with you over the fact that your generic has an "out" keyword in it then you're not going to get things done the easy way anyways.
|
# ? Oct 19, 2018 05:05 |
|
|
# ? Jun 11, 2024 22:38 |
|
https://github.com/withoutboats/shifgrethor aw yeah
|
# ? Oct 19, 2018 14:47 |