terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

VikingofRock: Aug 24, 2008

Are there any plotting libraries as good as matplotlib in languages besides Python?

# ? Jun 23, 2015 06:44

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 04:41

MononcQc: May 29, 2007

comedyblissoption posted:

you say that static typing is generally better but not to the point it's the most dominating factor in any software project

and most people would agree that there are other factors that are way more important since you just have to simply look around for blindingly obvious examples of this

but uh that still doesn't really answer why you would choose dynamic typing over static typing if you had a choice

Yeah the thing is that I don't really give much of a poo poo.

If you're designing a cluster, then cloud Haskell is a bad idea because it's undeployable. Pick something with shittier types. If you're working on any specific task, check the language, its libraries, and properties. It's possible a static type system would have marginal benefits. I'm parsing logs for a quick one-off? I'm not gonna complain that Awk mixes integers and strings together.

Here's a fun one for you: Go has a not-very-good type system, but no generics. Python has no type system, but support generics and mixed-types containers out of the box. The answer might be "use neither", but yeah.

Then you got languages like Racket that allow you to write typed modules and interacting with untyped ones (or type the whole thing). This kind of stuff is what I tend to prefer. Wherever types are a tool that makes sense to use, you can. Whenever you feel they're slowing you down, you can stop using them.

# ? Jun 23, 2015 12:22

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

this thread should be more terrigble

i use java 1.3 cos im stuck on an old jvm that was made for embedded then discontinued and i compile it myself along with a linux 2.6 kernel lmao

# ? Jun 23, 2015 12:53

bobbilljim: May 29, 2013; this christmas feels like the very first christmas to me

the people at zeroturnaround are spamming me abotu jrebel and its really tempting to send them a diatribe about how they cant possibly unfuck my deployment

# ? Jun 23, 2015 12:54

Bloody: Mar 3, 2013

VikingofRock posted:

Are there any plotting libraries as good as matplotlib in languages besides Python?

lol nope

# ? Jun 23, 2015 14:18

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

MononcQc posted:

Wherever types are a tool that makes sense to use, you can. Whenever you feel they're slowing you down, you can stop using them.

this

# ? Jun 23, 2015 15:31

Shaggar: Apr 26, 2006

MononcQc posted:

They're a single function with many clauses. Think of them as functions that contain a switch in their declaration.
Right, it's an example. Consider any of these:

toggle(on) -> off;
toggle(off) -> on. <== pretty much the same as 'not' with booleans

to_format(xml, Data) -> "<mydata>...</mydata>";
to_format(json, Data) -> "...";
to_format(pdf, Data) -> call(...).

or whatever else could look like a declarative dispatch. As I said, there's other ways to do it and work around not being able to do that, but it's nice when you can.

Think of it as being able to track or properly represent different return types or values (especially if you support range types) based on the value of an Enum. Some time systems will artificially restrict you there, others will be powerful enough to do it. It's really a minor point, again, but it's a thing type systems do.

single functions with many clauses are unmaintainable and bad design. they force you to change code any time someone adds new entities and make for a longer function that gives everyone more of a chance to gently caress it up.

plus you aren't even right about the parameters. What we do irl is we have format(data,formatter) where formatter is a class that follows an interface for formatting data. the logic for turning data into json is stored in JSONFormatter and for data into xml is in XMLFormatter, etc... this way format() is maintained separately and is also reusable for any extensions.

this is basically how mvc does object formatting and adding your own formatter is as simple as writing it and adding it to the formatter chain. you don't have to go edit some gigantic format function to add your new format.

Plus it becomes reusable across any projects and you can share it with someone who might have their own additional formatters and everyone gets only what they need in their chain and only has to maintain their custom formatters instead of the entire format function.

Someone who is only working on their own toy project might not have a problem with a gigantic format function, but anyone who works irl with other people is going to immediately hate the idea because it has massive drawbacks. plus the supposed problems of the static type system don't actually exist.

# ? Jun 23, 2015 15:43

MononcQc: May 29, 2007

Shaggar posted:

single functions with many clauses are unmaintainable and bad design. they force you to change code any time someone adds new entities and make for a longer function that gives everyone more of a chance to gently caress it up.

They're one of the alternatives to a factoryfactory, or to a naming scheme. Take the easy example of an HTTP handler. You can go:

handle_get(...)
handle_post(...)
handle_put(...)

or you can have

Handler.FromGetFactory(...)
Handler.FromPostFactory(...)
Handler.FromPutFactory(...)

or you can have:

handle(get, ...)
handle(post, ...)
handle(put, ...)

The difference is that in a declarative language with pattern matching (Erlang, F#, Haskell, Prolog, whatever else), you can do sub-clauses:

handle(get, logged_out) -> 403
handle(get, logged_in) -> 200

or if you prefer a thing that returns states and dispatch:

handle(get, logged_out) -> return login_handler
handle(get, logged_in) -> return page_handler

or whatever else.

Arguing against that type of function is more or less arguing against switch/case statements because they are pretty much just that. You're trying too hard to think of the pattern in Java, I think, and not enough with the eye of other languages with different paradigms.

Shaggar posted:

plus you aren't even right about the parameters. What we do irl is we have format(data,formatter) where formatter is a class that follows an interface for formatting data. the logic for turning data into json is stored in JSONFormatter and for data into xml is in XMLFormatter, etc... this way format() is maintained separately and is also reusable for any extensions.

And how do you pick the formatter? A switch, maybe? A factory? The multi-function stuff is one form of dispatch table, but you can turn the following:

dispatch(xml) -> xml_formatter();
dispatch(json) -> json_formatter();
dispatch(pdf) -> pdf_formatter();
dispatch(_) -> throw(unsupported)

into an interface that follows whatever signature, so that you get the xml.formatter function, json.formatter function, pdf.formatter function. In the end, somewhere in your code (or config files), stands a validation mechanism that has a list of the valid formats and a translation mechanism to their implementation. If it's in some config files, think of your config as code; that dispatch function is configuration as code.

The multi-head thing right here is a very explicit one that doesn't have to be tied to anything. Oh yeah you need to update it (as you would for some config), but if you don't mention the formatter there, it's probably at a given callsite and it's more implicit. It's not the only way and you can work around it.

I admitted this 40 times already. It's not like I've never seen an alternative.

My argument here was not even about that. My point was that some type systems will flat out forbid the kind of code that lets you do that pattern. End of argument. It's not whether they should or shouldn't or if it's a good idea, or if Shaggar agrees. It's that literally, powerful type systems (much better than Java's) cannot properly deal with this kind of code (despite being correct) because they cannot prove its soundness under their current axioms, and they will reject it.

MononcQc fucked around with this message at 16:03 on Jun 23, 2015

# ? Jun 23, 2015 16:00

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Well yeah. It's literally impossible to have a type system that, in a bounded amount of time, decides whether running a program will result in failing a type-check.

Consider the following code:

code:


int test(function f) {
  f()
  return "fail"
}

Determining whether the program actually type-fails in practice is dependent on whether the function you pass into it terminates.

The best you can do is sort programs into "won't fail", " will fail" and "undecided".

# ? Jun 23, 2015 17:14

MononcQc: May 29, 2007

Jabor posted:

Well yeah. It's literally impossible to have a type system that, in a bounded amount of time, decides whether running a program will result in failing a type-check.

Consider the following code:
code:
int test(function f) {
  f()
  return "fail"
}
Determining whether the program actually type-fails in practice is dependent on whether the function you pass into it terminates.

The best you can do is sort programs into "won't fail", " will fail" and "undecided".

There's more than this there. Hindley Milner is a way to type check. You got the bare rear end type annotations, union types, recursive types, linear types, success typings, dependent types, varying degrees of type inferences, varying degrees of polymorphism, and so on are all variations/features or different ways to do thing. They're going to have different gotchas and implementation details.

Bundling them all in 'type checked' is pretty reductive compared to what they can or can't express.

Then you have different forms of static analysis not related to types: race condition detectors and linters for example.

# ? Jun 23, 2015 17:29

Shaggar: Apr 26, 2006

MononcQc posted:

They're one of the alternatives to a factoryfactory, or to a naming scheme. Take the easy example of an HTTP handler. You can go:

handle_get(...)
handle_post(...)
handle_put(...)

or you can have

Handler.FromGetFactory(...)
Handler.FromPostFactory(...)
Handler.FromPutFactory(...)

or you can have:

handle(get, ...)
handle(post, ...)
handle(put, ...)

The difference is that in a declarative language with pattern matching (Erlang, F#, Haskell, Prolog, whatever else), you can do sub-clauses:

handle(get, logged_out) -> 403
handle(get, logged_in) -> 200

or if you prefer a thing that returns states and dispatch:

handle(get, logged_out) -> return login_handler
handle(get, logged_in) -> return page_handler

or whatever else.

Arguing against that type of function is more or less arguing against switch/case statements because they are pretty much just that. You're trying too hard to think of the pattern in Java, I think, and not enough with the eye of other languages with different paradigms.

And how do you pick the formatter? A switch, maybe? A factory? The multi-function stuff is one form of dispatch table, but you can turn the following:

dispatch(xml) -> xml_formatter();
dispatch(json) -> json_formatter();
dispatch(pdf) -> pdf_formatter();
dispatch(_) -> throw(unsupported)

into an interface that follows whatever signature, so that you get the xml.formatter function, json.formatter function, pdf.formatter function. In the end, somewhere in your code (or config files), stands a validation mechanism that has a list of the valid formats and a translation mechanism to their implementation. If it's in some config files, think of your config as code; that dispatch function is configuration as code.

The multi-head thing right here is a very explicit one that doesn't have to be tied to anything. Oh yeah you need to update it (as you would for some config), but if you don't mention the formatter there, it's probably at a given callsite and it's more implicit. It's not the only way and you can work around it.

I admitted this 40 times already. It's not like I've never seen an alternative.

My argument here was not even about that. My point was that some type systems will flat out forbid the kind of code that lets you do that pattern. End of argument. It's not whether they should or shouldn't or if it's a good idea, or if Shaggar agrees. It's that literally, powerful type systems (much better than Java's) cannot properly deal with this kind of code (despite being correct) because they cannot prove its soundness under their current axioms, and they will reject it.

in mvc you don't have get and post methods, you have controller methods that take inputs and return actions that are then processed by the runtime. the controller methods are get by default but can be annotated with other methods ex:

C# code:


public ActionResult Index()
{
	return View(); //Returns the Index view of this controller with no model
}

//this is a get w/ id as a parameter. returns a blog post w/ that id from the db.
public ActionResult Post(int id)
{
	Post post = db.getPost(id);
	return View(post); //returns the Post view with the post object as model.
}

//This is a post w/ the post as a parameter used for editing a post
[HttpPost]
public ActionResult Post(Post p)
{
	if(ModelState.IsValid)
	{
		db.save(post);
		return view("Index"); // Send them back to the index or w/e else you want to do after they edit.
	}
	return View(p); // Theres something wrong w/ the model (validation error or something) so send them back to the post view w/ the post object (updated automatically w/ validation problems)

}

The controller is picked based on routing and the routing is also customizable. Its really a great framework.

wrt which formatter is picked, the formatters also explain which formats they produce and consume. When they are registered with the framework they are also chained in order so if you have multiple application/json handlers the first one is used. These formatters are used for both serialization and deserialization and the mimetypes requested by the client are used when picking.

so in webapi, for example, if someone sends you a request with no accept header the first formatter is picked. if they do specify an accept mime type, the first formatter that handles that mimetype is picked. if they specify an unknown mime type then they get a 415 or something like that.

in this way your controller, your actions, your models, your views, and your formatters are all separate code, yet they are integrated w/ each other very very easily because the framework is designed for human use. The type system is what allows it all to happen since no one has to worry about if their versions of a controller will work with the routing framework. They cant use something that doesn't inherit from the base controller so its not a problem.

w/out the type system you'd be in a nightmare world of duck typing and runtime errors.

# ? Jun 23, 2015 17:33

MononcQc: May 29, 2007

Shaggar posted:

The type system is what allows it all to happen since no one has to worry about if their versions of a controller will work with the routing framework. They cant use something that doesn't inherit from the base controller so its not a problem.

w/out the type system you'd be in a nightmare world of duck typing and runtime errors.

Not necessarily. So part of the specific thing there is that this OO pattern ties up your hierarchy and implementation along with your types. It would be possible for a check on the hierarchy of your classes to tell you the class or module you pass in implements the right functions/methods with the right numbers of arguments, but without checking that the types they use are already valid, for example. That way you'd get a compile-time check that's not related to types; it's not as complete, but it can totally be compatible with a dynamic language that has some lovely half-assed interface or protocol (clojure-style) support.

There's a lot of stuff you argue is great that isn't necessarily related to your type system, but to additional compiler or IDE checks and support, and that are not exclusive to statically typed languages. Having a static type system you can tie in usually helps, but isn't necessary.

To give you an example, Erlang is a dynamic language that can do partial interface checks at compile time (and optional typing on top allows better type analysis before runtime) whereas Go is a statically-typed language with duck typing that won't even be as strict.

# ? Jun 23, 2015 18:02

Shaggar: Apr 26, 2006

I get what you're saying, you could potentially have a controller-like object that has View and Redirect and all the other plumbing related methods that the Controller class provides and it would effectively have the same signature, however in this case all of those methods and plumbing are the stuff that deals with interaction w/ the pipeline. its a load of code and there are a handful of scenarios where you'd want to change it. by forcing you to inherit from the abstract controller class MVC requires you to make a very explicit decision to alter the core of the controller class rather than forcing you to try to implement it yourself.

so its maybe not a good example of somewhere you'd actually want to do dynamic typing. tbh i cant really think of one outside of that example you had of message classes when deploying different versions of an application. but in that case I'd probably be serializing the messages and if they are different messages they should be different types or if the new type is a superset of the old type it should be compatible with the old messages. So im either deserializing the old stuff into a new, superset class or im deserializing the old stuff into the old class and adapting it to the new class. even in the dynamic world you would need that adapter if the message has changed enough to make it incompatible.

most of my time in dynamic languages has been spent in javascript so when i think dynamic i think of all the library bugs where someone forgot to check that the variable existed and that it has a parameter and that the parameter is a function before trying to use it.

# ? Jun 23, 2015 18:30

Notorious b.s.d.: Jan 25, 2003; by Reene

bobbilljim posted:

this thread should be more terrigble

i use java 1.3 cos im stuck on an old jvm that was made for embedded then discontinued and i compile it myself along with a linux 2.6 kernel lmao

what jvm is that ?

# ? Jun 23, 2015 18:38

Shaggar: Apr 26, 2006

microsofts jvm maybe?

# ? Jun 23, 2015 18:54

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

Shaggar posted:

microsofts jvm maybe?

on linux??

# ? Jun 23, 2015 18:57

MononcQc: May 29, 2007

Shaggar posted:

most of my time in dynamic languages has been spent in javascript so when i think dynamic i think of all the library bugs where someone forgot to check that the variable existed and that it has a parameter and that the parameter is a function before trying to use it.

Yeah, that's the bona fide terrible dynamic. I mean Racket has a statically typed sublanguage for specific modules requiring the safety, Erlang has an optional type checker that does type inference (but prefers no false positive to no false negative), Prolog is able to metaprogram itself a type checker in 30 lines of code, many schemes, strongtalk, dylan, common lisp and so on have gradual typing (type annotation for speed and poo poo), clojure offers a typed variant, and so on.

There's a lot more stuff out there outside of har har I gently caress all your data the way javascript and PHP do it, and some models saner than others. They sadly just don't really make it to mainstream much.

# ? Jun 23, 2015 18:57

Shaggar: Apr 26, 2006

I think what it comes down to is we static typing fans have spent our time in the mines dealing with the absolute worst of the worst in dynamic languages so when someone suggests "well you can have it optionally be static!" our immediate reaction is that our horrible coworkers will disable all the static checks they can. its the same reason operator overloading is bad. there are theoretical benefits but mostly it will just be abused.

# ? Jun 23, 2015 19:10

Soricidus: Oct 21, 2010; freedom-hating statist shill

that's the real problem isn't it? all the "good" dynamically typed languages, with reasonable semantics and decent tooling and optional types and stuff, are niche things; in the mainstream you have bad things like js and python and php.

static typing has the same problem - all the good powerful type systems are in niche languages - but the mainstream stuff like java and c# is less bad because the tools available are better at concealing their weaknesses, such as verbosity.

so in an ideal world I'd probably be advocating for something with optional typing, but in this reality I'll favor static typing because of the realistic options right now, it's the lesser evil.

# ? Jun 23, 2015 19:11

jony neuemonic: Nov 13, 2009

Shaggar posted:

I think what it comes down to is we static typing fans have spent our time in the mines dealing with the absolute worst of the worst in dynamic languages so when someone suggests "well you can have it optionally be static!" our immediate reaction is that our horrible coworkers will disable all the static checks they can. its the same reason operator overloading is bad. there are theoretical benefits but mostly it will just be abused.

i'm being paid to write php so, same.

# ? Jun 23, 2015 19:12

Shaggar: Apr 26, 2006

Soricidus posted:

that's the real problem isn't it? all the "good" dynamically typed languages, with reasonable semantics and decent tooling and optional types and stuff, are niche things; in the mainstream you have bad things like js and python and php.

static typing has the same problem - all the good powerful type systems are in niche languages - but the mainstream stuff like java and c# is less bad because the tools available are better at concealing their weaknesses, such as verbosity.

so in an ideal world I'd probably be advocating for something with optional typing, but in this reality I'll favor static typing because of the realistic options right now, it's the lesser evil.

verbosity is not a weakness.

# ? Jun 23, 2015 19:12

brap: Aug 23, 2004; Grimey Drawer

carmack says "if the compiler allows it, it will make it into your codebase"
this is a good reason to have your build system use -werror

# ? Jun 23, 2015 19:17

ryde: Sep 9, 2011; God I love young girls

sorry to break into the static vs dynamic debate, but I'm trying to improve conciseness in my codebase and turn-around for changes. this is a Java codebase. a problem I'm having is having to work around libraries that expect things to be beans.

I usually like to structure my objects such that they are unmodifiable:

code:


  class MyObject {
     private final String oneParam;
     private final Collection<String> twoParam;
    
     public MyObject(String oneParam, Collection<String> twoParam) {
         this.oneParam = oneParam;
         this.twoParam = new ArrayList<>(twoParam);
     }
   
     public String getOneParam() {
         return oneParam;
     }

     public Collection<String> getTwoParam() {
        return Collections.unmodifiableCollection(twoParam);
     }
  }

This makes a lot of the business logic pretty easy to reason about, but the problem is that a lot of Java libraries freak the gently caress out about this because of no default constructor and no setters omg. primarily, I am so goddamn tired of writing custom serialization logic for Jackson and DynamoDB. I think the typical approach is to have DTOs for the former and DAOs for the latter, but that's hardly reducing boilerplate. do I really just need to remove the stick from my rear end and submit to Java "best practices" or is there an obvious improvement I'm missing.

# ? Jun 23, 2015 19:17

MononcQc: May 29, 2007

fidel sarcastro posted:

i'm being paid to write php so, same.

"hm register globals are disabled"

php:

<?
foreach (array('_GET', '_POST', '_COOKIE', '_SERVER') as $_SG) {
    foreach ($$_SG as $_SGK => $_SGV) {
        $$_SGK = $_SGV;
    }
}
?>

# ? Jun 23, 2015 19:50

VikingofRock: Aug 24, 2008

Shaggar posted:

its the same reason operator overloading is bad. there are theoretical benefits but mostly it will just be abused.

Do people really abuse operator overloading that much? I don't know that I've ever seen any particularly egregious examples, unless you count C++ streams overloading the bit shift operators as egregious (I don't).

# ? Jun 23, 2015 20:35

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

JewKiller 3000 posted:

i'm interested to hear MononcQc's opinion here, because i haven't heard a single argument in favor of dynamic typing over static that doesn't boil down to "i don't understand static typing". but as an erlang expert i think he might have something actually useful to say (maybe related to hot code loading?)

it's all good and well to dismiss arguments for dynamic typing by saying "your complaint is just because you are used to weak static type systems!" but it's not very practical.

a static type system is just a language feature. not all language features are compatible or easy to implement side-by-side. so even if there is in theory a static type system capable of typing your language, it may be prohibitively complex to write or execute, because language features aren't free.

for example, if python were designed to be statically typed from the beginning, i don't think it would be a stretch to say it would still be missing a lot of cool features it has now, like coroutines. or, if it did have them, they would look so different as to infringe on python's other goals (e.g. readability/simplicity).

# ? Jun 23, 2015 20:59

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

also gently caress the yospos hivemind, python rules

# ? Jun 23, 2015 20:59

Valeyard: Mar 30, 2012; Grimey Drawer

Pie Colony posted:

also gently caress the yospos hivemind, python rules

# ? Jun 23, 2015 21:07

gonadic io: Feb 16, 2011; >>=

Pie Colony posted:

also gently caress the yospos hivemind, python rules

i have never ever said that python is bad. i have said that i'd never choose to program in it over f# or haskell or something but that's true about many languages.

i may have made fun of guido's decisions a bit too, but i would much rather python exists than it not exist.

# ? Jun 23, 2015 21:21

leftist heap: Feb 28, 2013; Fun Shoe

i have said that python is bad and it is and i stand by it

# ? Jun 23, 2015 21:26

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

if python didn't exist, i would rather kill myself than write my scripts in bash

# ? Jun 23, 2015 21:38

AWWNAW: Dec 30, 2008

wish I could find someone to pay me to write F#

alas I am forced to write lovely blog posts about it in my spare time

# ? Jun 23, 2015 21:53

Valeyard: Mar 30, 2012; Grimey Drawer

Pie Colony posted:

if python didn't exist, i would rather kill myself than write my scripts in bash

this was my internship last year

# ? Jun 23, 2015 21:56

Soricidus: Oct 21, 2010; freedom-hating statist shill

AWWNAW posted:

alas I am forced to write lovely blog posts about it in my spare time

now i'm picturing don syme standing behind you with a gun

# ? Jun 23, 2015 21:58

jony neuemonic: Nov 13, 2009

MononcQc posted:

"hm register globals are disabled"

php:

<?
foreach (array('_GET', '_POST', '_COOKIE', '_SERVER') as $_SG) {
    foreach ($$_SG as $_SGK => $_SGV) {
        $$_SGK = $_SGV;
    }
}
?>

it's not quite that bad, but some parts of it come alarmingly close.

# ? Jun 23, 2015 21:59

Shaggar: Apr 26, 2006

VikingofRock posted:

Do people really abuse operator overloading that much? I don't know that I've ever seen any particularly egregious examples, unless you count C++ streams overloading the bit shift operators as egregious (I don't).

i haven't used a language that allows it in forever so i haven't had to find out.

ryde posted:

sorry to break into the static vs dynamic debate, but I'm trying to improve conciseness in my codebase and turn-around for changes. this is a Java codebase. a problem I'm having is having to work around libraries that expect things to be beans.

I usually like to structure my objects such that they are unmodifiable:
code:
  class MyObject {
     private final String oneParam;
     private final Collection<String> twoParam;
    
     public MyObject(String oneParam, Collection<String> twoParam) {
         this.oneParam = oneParam;
         this.twoParam = new ArrayList<>(twoParam);
     }
   
     public String getOneParam() {
         return oneParam;
     }

     public Collection<String> getTwoParam() {
        return Collections.unmodifiableCollection(twoParam);
     }
  }
This makes a lot of the business logic pretty easy to reason about, but the problem is that a lot of Java libraries freak the gently caress out about this because of no default constructor and no setters omg. primarily, I am so goddamn tired of writing custom serialization logic for Jackson and DynamoDB. I think the typical approach is to have DTOs for the former and DAOs for the latter, but that's hardly reducing boilerplate. do I really just need to remove the stick from my rear end and submit to Java "best practices" or is there an obvious improvement I'm missing.

im not sure on the design of Jackson but there might be a way for you to provide an alternative for whatever reflection its doing to find the properties on your pojos. by default its just gonna look for {get/set}{PropertyName} and that's how most of these things work. However, there may be a way for you to implement a replacement for that system that looks for a constructor with matching parameters names. Alternatively there may be a set of annotations you can provide to tell Jackson "please use my constructor to instantiate me" or something like that. idk. i haven't used java for this kind of thing in a while now

# ? Jun 23, 2015 22:17

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Pie Colony posted:

if python didn't exist, i would rather kill myself than write my scripts in bash

Why does everyone forget Perl

it's much better than bash

# ? Jun 23, 2015 23:21

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

crystal is seeming extremely sick

# ? Jun 23, 2015 23:21

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Shaggar posted:

i haven't used a language that allows it in forever so i haven't had to find out.

im not sure on the design of Jackson but there might be a way for you to provide an alternative for whatever reflection its doing to find the properties on your pojos. by default its just gonna look for {get/set}{PropertyName} and that's how most of these things work. However, there may be a way for you to implement a replacement for that system that looks for a constructor with matching parameters names. Alternatively there may be a set of annotations you can provide to tell Jackson "please use my constructor to instantiate me" or something like that. idk. i haven't used java for this kind of thing in a while now

c# has operator overloading homeboy

# ? Jun 23, 2015 23:26

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 04:41

Arcsech: Aug 5, 2008

AWWNAW posted:

wish I could find someone to pay me to write F#

alas I am forced to write lovely blog posts about it in my spare time

same

# ? Jun 23, 2015 23:39

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »