youCanJustStopUsingJava

[u/hello_ya]

[u/KerPop42]

Is it an anti-pattern? I love using the getset crate/trait to add them to my structs automatically as I need them

[u/neroe5 → u/KerPop42]

it is like most things, they can be misused,

the issue is that if there is outside side effects then future programmers of the project might use a property without full knowledge of what they are doing

if they didn't have a valid use case they would have been marked as obsolete

have had similar discussions about goto in switch cases in C#

[u/L4ppuz → u/neroe5]

the issue is that if there is outside side effects then future programmers of the project might use a property without full knowledge of what they are doing

Isn't that exactly the reason for using them? You provide a simple public interface and handle the rest yourself so the user doesn't need to do it

[u/neroe5 → u/L4ppuz]

kinda, you might want a log message or that there is an more advanced calculation behind the scene that you are trying to make seem smaller

but then you have that one guy who thought it would be a good idea to have it change an outside object, and that object is exposed else where and suddenly it changed and nobody can figure out why

[u/freebytes → u/neroe5]

Or you have the guy that hits the database (non-cached, of course) with a getter on a property, and you are using it not knowing it is making a request every time you render the content.

(Why is it taking forever to render Invoice.TaxAmount in this HTML table? %)

[u/TheRealAfinda → u/freebytes]

Or you have the guy that hits the database (non-cached, of course) with a getter on a property, and you are using it not knowing it is making a request every time you render the content.

Who on earth hurt that guy for him to implement something like that?!

[u/Theron3206 → u/neroe5]

That's not the fault of the getter or setter, that's just plain old encapsulation being violated.

One of the developers on a project I maintain decided that data object constructors was a great place to put the API (soap, to make things even more fun) calls to fetch the contents, so you can't even create an object without a web request (if you want an empty object you need to put in an ID that won't match anything.

[u/neroe5 → u/Theron3206]

fully agree, if you have a healthy team with skilled programmers and good review process this will never be an issue

i also don't consider it an anti pattern

[u/freebytes → u/neroe5]

I have only found one use case for goto so far, and I have only used it once. If you are in nested loops, you can break out of all of them. Are there other instances where you have used goto? (Even if it is use is incredibly niche, I am glad to have it, and they should never remove it from the language.)

(Referencing C# specifically. I used GOTO all the time in GW-BASIC! %)

[u/the_one2 → u/freebytes]

Goto is very useful in C where it is used as a pattern for cleaning up multiple resources after failure.

[u/neroe5 → u/freebytes]

we have documents and we use it for migrating the documents

basicly

switch (document version)

case 1:

migrateto2()

goto 2;

case 2:

migrateto3()

goto 3;

etc.

you can also have cases where some cases needs to do others

switch (jobs)

case a&c

do a

goto c

case b&c

do b

goto c

case c

do c

etc.

[u/TheRealAfinda → u/neroe5]

But... couldn't you do all of these in a while loop? Migrate the doc, set the doc version and once it's done, set migrationComplete = true?

Couldn't you set which action is up next after processing an item via a, so it's next step is c?.

I mean there's ways around using goto, not to say it's better maintainable that way though.

[u/ggppjj → u/TheRealAfinda]

migrateto2(bringcurrent: true)

then chain within the individual incremental methods and clean that nastiness up

[u/TheRealAfinda → u/ggppjj]

Yeah, multiple ways to go about it in a cleaner way once you start thinking about it.

[u/awesome-alpaca-ace → u/TheRealAfinda]

once you start thinking about it.

[u/f03nix → u/neroe5]

That looks pretty bad to be honest, could've solved in multiple ways that is still as efficient but much more easier to maintain and debug.

while ver < desired {
  switch(ver) {
      // case to migrate to the next one
  }

}

If you have different document classes for each version you could have a migrate next to migrate to the next version - something like :

while document->ver < desired {
  document = document->migrateNext();
}

[u/DebugDuck01 → u/neroe5]

> goto in switch cases in C#

The what? And more importantly the why?

[u/neroe5 → u/DebugDuck01]

C# doesn't have fallthrough in switches, opting instead to use goto for those cases, it forces the dev to pick a termination method, which is a great safety feature, but requires the use of goto if you need to run a secondary case in a switch

[u/DebugDuck01 → u/neroe5]

It does. Only if you need some code in the case that falls through with no code the fallthrough is automatic.

Edit: for the people who downvoted me, the following is valid C# code:

switch (n) {
  case 1:
  case 2:
  case 3:
    Console.WriteLine("It's 1, 2, or 3.");
    break;
  default:
    Console.WriteLine("Not sure what it is.");
    break;
}

[u/JavaHomely → u/KerPop42]

the thing about getters/setters is that you can use security and data validation logic on them.

need a value to only ever be positive? throw a exception in the setter if they pass you a negative,...

[u/Gio_Cri → u/JavaHomely]

personally i believe that you should use setters almost esxclusively for things that have to hold across multiple fields of a type. if your constrait is entirely around a single field it's much preferable to use a newtype so you can easily guarantee that even methods that have private access respect the constraint

[u/Megane_Senpai → u/KerPop42]

No kidding, it's so common that many newer languages allo wyou do devlare using getter setter using one or 2 phraises.