Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Be Afraid of Types

lmika.org

Post reply on HN
Print view View original

91–100 of 233 posts

Re: Don't Be Afraid of Types

#91

Post by Viliam1234 »

ido wrote: post #79
nottorp wrote: post #77

Earlier quoted context omitted.

If we're philosophizing here: 1. This (or maybe a less trivial form of this) will bite you in the ass when you end up using other people's unnamed types. Or even when you use your own unnamed types that come from code you haven't touched in three years. 2. That's what interfaces are for in Java. Or at least modern Java.

I’ve first learned Java in introduction to programming in 2001 and that’s what interfaces were for back then already.

Interface are more fundamental to Java than classes.

Sadly, at the beginning, many people came to Java from C/C++, and they did the thing we used to call "writing C/C++ code in Java".

Re: Don't Be Afraid of Types

#92

Post by efficax »

jt2190 wrote: post #87
DeathArrow wrote: post #70

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

> … [I]n OOP land there's the idea that types aren't mere containers for data. Can you elaborate? Types don’t contain data in any way that I understand… Do you mean constrain ?

it’s common to be imprecise and mix up the type and an instantiation of the type, and that’s all that is happening here

Re: Don't Be Afraid of Types

#93

Post by bluGill »

motorest wrote: post #30
noduerme wrote: post #18

Earlier quoted context omitted.

I think Java culture had something to do with the ridiculously verbose names, but even more so the prevalence of Factory and Singleton paradigms in Java created these issues. Maybe because it was the first OO language that a lot of procedural coders came to in the 90s. Those patterns became sort of escape hatches to avoid reasoning about ownership, inheritance and scope. They're still common patterns for emergencies…

> I think Java culture had something to do with the ridiculously verbose names, but even more so the prevalence of Factory and Singleton paradigms in Java created these issues. It sounds like you're confusing things. Factories are a way to instantiate objects of a specific type a certain way. Singletons is just a restriction on how many instances of a type there can be. These are not Java concepts, nor are they relev…

They are not Java concepts, but abusing them by using in contexts where they are a bad answer is something Java tends to take to the limit. (I fight the same abuse in C++, and it always seems that Java "best practices" is where the idea came from)

Re: Don't Be Afraid of Types

#94

Post by MrMcCall »

erikerikson wrote: post #81
MrMcCall wrote: post #71

Earlier quoted context omitted.

But once you get down to the unit data values inside any of those aggregates, you're still dealing with either characters, ints, floats, strings, arrays, and they each have their own individual access patterns and, more importantly, modification functions. You can't add a number to a string, only to another number. If you are dealing with a float, you better be careful how you check it for equality. If it's pure bina…

> You can't add a number to a string Haven't written JavaScript?

I don't care if it "can" be done, the results will be garbage unless you are very, very careful.

And Javascript is garbage no matter how many people use it successfully, as I have done professionally.

Re: Don't Be Afraid of Types

#95

Post by jonasenordin »

ninetyninenine wrote: post #67

In Java you can’t just create a type. You are creating a mini app. Classes in Java hold logic and internal mutating state. I don’t want to create this just because I need a type. Really you want to create a struct or an interface as a type.

Java has interface types.

https://en.wikipedia.org/wiki/Interface_(Java)

Re: Don't Be Afraid of Types

#96

Post by tossandthrow »

nottorp wrote: post #78
tossandthrow wrote: post #38

Earlier quoted context omitted.

This is more a question about architecture. But one thing is certain: When you have that one function that is used 165 times throughout the code base, having a type checker is certainly going to help you when you add in the users middle initial.

> This is more a question about architecture. In an ideal world :) In the real world the customer doesn't know what they want and you can't fully guess what they want or need ahead of time no matter how many diagrams you draw. Incidentally, one of the few good things that came out of the "agile" religion.

You are completely right!

And the exact point I tried to communicate.

When you decide to have loose architectural structures, you might allow just writing these types of functions adhoc.

The further you go in the project, the more your strengthen the architecture, where needed.

Re: Don't Be Afraid of Types

#97

Post by beders »

turdprincess wrote: post #86
DeathArrow wrote: post #70

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

In that setup, how do you write a test which acts against a mock version of your API client (a static function in your proposal?)

yeah, I wouldn't recommend trying to do this with pure Java but you could pass around method handles for that purpose.

You certainly would want to use an `interface` and that means you need an object. It could be an object that has no fields though and receives all data through its methods.

But it does go against the spirit of objects: You want to make use of `this` because you are in the land of nouns.

Re: Don't Be Afraid of Types

#98

Post by teeray »

My favorite is when I come across a set of functions in Go with the same prefix that all take some struct treated as a bag of data. “validateUserRequest”, “processUserRequest”, “initializeUserRequest”, or something like that. You have written a type already, but made it annoying. Write methods for “Validate” and “Process”, then have a factory function “NewUserRequest” (consider whether you actually need it first though).

Re: Don't Be Afraid of Types

#99

Post by MrDarcy »

turdprincess wrote: post #86
DeathArrow wrote: post #70

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

In that setup, how do you write a test which acts against a mock version of your API client (a static function in your proposal?)

In Go at least you simply define an interface and use it as the receiver then inject whatever mock object you want.

The mock itself may simply be a new type defined in your test case.

Re: Don't Be Afraid of Types

#100

Post by jt2190 »

If you ignore the weird rant about OOP (that references an article from 2006… haven’t we all moved on in the last twenty years?), the author’s main thesis lacks context:

> But take it from someone that’s had do deal with codes passing through and returning several values of strings, ints, and bools through a series of function calls: a single struct value is much easier to work with.

This presupposes that the code should be very strict with the data, which may or may not be desirable. For example, in many CRUD apps the client and the database enforce constraints, while the middle tier just needs to martial data between the two, and it’s questionable whether the middle tier should do type enforcement. As always: Challenge your assumptions, try to understand how a “bad” practice might actually be the right approach in certain contexts, etc, etc.

Post reply on HN