Tag Info

Hot answers tagged

92

The method violates the Liskov substitution principle. If a method accepts a parameter of type Object, I should expect that any object I pass to the method will work. What it sounds like is that only certain subclasses of Object are allowed. The only way to know which types are allowed is to know the details of the method. In other words, the method is ...


90

From a practical point of view I see these problems: A bloat of possible run type errors -- unless a lot of dynamic type checking which could be avoided with the Java included strong type checker. A lot of unnecessary casts Difficulty understanding what a method does by its signature From a theoretical point of view I see these problems: A lack of ...


81

It's sort of a myth that programmers don't have to worry about types in dynamically typed languages. In dynamically typed languages: You still have to know if you're working with an array, an integer, a string, a hash table, a function reference, a dictionary, an object, or whatever. If it's an object, you have to know what class it belongs to. ...


80

As the types get stronger, they can help you more — if you use them correctly instead of fighting them. Design your types to reflect your problem space and logic errors are more likely to become compile-time type mismatches instead of runtime crashes or nonsense results.


79

Type systems prevent errors Type systems eliminates illegal programs. Consider the following Python code. a = 'foo' b = True c = a / b In Python, this program fails; it throws an exception. In a language like Java, C#, Haskell, whatever, this isn't even a legal program. You entirely avoid these errors because they simply aren't possible in the set of ...


54

Disclaimer: I am a type-lover ;) Your question is difficult to answer: What are those trade-offs ? I'll take an extreme example: Haskell, it is statically typed. Perhaps one of the most strongly typed languages that exist, in fact. However, Haskell supports Generic Programming, it the sense that you write methods that work with any type conforming to a ...


50

I'd consider the following direct implications: Readability I guess working with him is not exactly the most pleasant experience in the world. You never know what the type is going to be in the end or what happens to the parameters. I doubt you appreciate wasting your time with that. Type Signature In Java everything is an Object. So what does that ...


36

Because of the XML Schema Definition (XSD). With XML, you can have an additional file which describes the schema. It indicates, for example, that the element /a/b is an array and contains from 1 to 10 elements, or that the element /a/c is an integer. You can find an example of an XSD here. Validation of a given XML file through an XSD is supported by many ...


31

The problem with this kind of discussion is simply that the terms "weak typing" and "strong typing" are undefined, unlike for example the terms "static typing", "dynamic typing", "explicit typing", "implicit typing", "duck typing", "structural typing" or "nominal typing". Heck, even the terms "manifest typing" and "latent typing", which are still open areas ...


24

Yes, definitely. Functions/methods that take too many arguments is a code smell, and indicates at least one of the following: The function/method is doing too many things at once The function/method requires access to that many things because it's asking, not telling or violating some OO design law The arguments are actually closely related If the last ...


22

It takes away the type checking that the compiler does and can lead to more runtime exceptions when the object is cast to the concrete type. Thus, the end-user will see the unhandled exception, unless the invalid casts are all caught and properly handled.


22

Personally, I find that type safety helps me develop faster in my current job. The compiler does a lot of the sanity checking for me almost as I type, allowing me to focus more on the business logic that I'm implementing. Bottom line for me is that although I lose some flexibility, I gain some time that would otherwise be spent tracking down type issues.


22

No, you should not feel uncomfortable using auto. Just use it in situations where the type is obvious, or where no one is going to care about it A classic example (IMO) of where auto is handy: std::vector<sometype> vec ... ... //some code ... ... for(auto iter = vec.begin(); iter != vec.end(); ++iter) { //something here } Nobody really cares ...


20

I like both statically-typed and dynamically-typed languages. The two biggest advantages of type safety to me are: 1) You can often pretty much deduce what a function does purely from its type signature (this is particularly true in functional languages like Haskell). 2) When you do significant refactor, the compiler automatically tells you everything you ...


20

XML can be type safe, since it it possible with XSD schemas to declare the data type of elements. A document validated against a XSD schema is guaranteed to conform to the expected types. But a XML format is not required to have a schema, so a document is not automatically type safe just by being XML. There actually exist a schema language for JSON also, so ...


19

Remember there are two major concepts that are commonly confused: Dynamic typing A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type. The ...


19

These are phantom type parameters, that is, parameters of a parameterised type that are used not for their representation, but to separate different “spaces” of types with the same representation. And speaking of spaces, that’s a useful application of phantom types: template<typename Space> struct Point { double x, y; }; struct WorldSpace; struct ...


17

To expand on @KarlBielefeldt's answer, here's a full example of a Vector with a strongly typed number of elements. Hold on to your hat... {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} ...


16

A type system helps you avoid simple coding errors, or rather allows the compiler catch those errors for you. For example, in JavaScript and Python, the following problem will often only be caught at runtime - and depending on testing quality/rarity of the condition may actually make it to production: if (someRareCondition) a = 1 else a = {1, 2, ...


15

I agree with the other responses that this is generally bad practice. There is one specific case where I find passing an Object may be superior: when you are eventually dealing with Strings, e.g. if you are creating XML or JSON. In that case, instead of something like: public void addAttribute(String s) { //... add s to the XML } I prefer: public ...


14

Reality itself is typed. You can't add lengths to weights. And while you can add feets to meters (both are units of lengths), you should scale at least one of the two. Failing to do so can crash your Mars mission, quite literally. In a typesafe system, adding two lengths expressed in different units would have been either an error or would have caused an ...


12

When you're maintaining code where every function takes an array blob of data written by someone who didn't believe in documentation, you'll know why.


11

Figuring out all subclasses of a class is called Class Hierarchy Analysis, and doing static CHA in a language with dynamic code loading is equivalent to solving the Halting Problem. Plus, one of the goals of Scala is separate compilation and deployment of independent modules, so the compiler simply cannot know whether or not a class is subclassed in another ...


10

That's called dependent typing. Once you know the name, you can find more information on it than you ever could hope to want. There's also an interesting haskell-like language called Idris that uses them natively. Its author has done a few really good presentations on the topic that you can find on youtube.


9

So first of all, what actually is safety? protection against data corruption, or > hackers, or system malfunctions, etc? Type safety is a property of a program brought by a sound type system and informed by a respective type checker (usually performed by a compiler). In very few words, a type safe program can be defined as one that, when executed, is ...


8

There are two issues at play here: Issue #1: C is a statically typed language; all type information is determined at compile time. No type information is stored with any object in memory such that its type and size can be determined at run time1. If you examine the memory at any particular address while the program is running, all you'll see is a sludge ...


7

Is type safety worth the hit to speed of development and flexibility? So really this comes down to what you are doing. If you are programming say, the backup systems for airplanes, type safety is probably the way to go. Dynamic language vs Static language programming are really two different animals. They both require a fundamentally different ...


7

Type safety is not a black-or-white type-safe or not. It's more of a spectrum and some languages can be more type safe than others (and vice versa). However, I think what you're thinking of with C# vs. Javascript is likely static typing (where type-checking happens at compile-time) vs. dynamic typing (where type-checking happens at run-time) -- certainly, ...


7

Because at the moment when printf is called and does its job, the compiler is no longer there to tell it what to do. The function doesn't get any information except what's in its parameters, and the vararg parameters don't have any type, so printf would have no clue how to print any if them if it didn't get explicit instructions via the format string. The ...



Only top voted, non community-wiki answers of a minimum length are eligible