How is your IDE accomplishing that I wonder without knowing the type.

In most cases the answer is: Who cares?
If I want to know it I move my mouse cursor above “person” and I’ll see a popup-window that tells me what exact type “person” has.

“Explicit typing is writing documentation.”

IMO documenting things I’m not interested in. Why should I care whether it’s a “Person” or a “Nameable” as long as I can call “printName” with it? If I can’t the compiler will tell me why I can’t.

When I see code like

def nameable = new Person();
printName(nameable);

I directly understand what it does.

I know that it fullfills the “contract” needed by “printName” as I wouldn’t be able to compile it otherwise.
If whatever nameable is does not fullfill the contract the compiler will tell me what’s wrong.

In my experience this works perfectly in other languages with type inference so I don’t see why it shouldn’t in Boo (with ‘I never used).

A smart IDE should know about the type, you’re right. But someone reading source outside an IDE, browsing through a repository with FishEye, using diff tools etc. will not benefit from the IDE knowledge. *Doc tools will also be much harder to write, which could lead to less documentation because the tool is not smart enough.

But I’m with you mostly, an IDE should hide or remove parts (existing things like generics, public modifiers come to mind) of code and just show them when you need them. On the other hand, when the IDE hides code and shows annotations, it’s not important anymore for the developer if the code is there or not (in real, in source). If I can hide the type, I do not care if I have added it with auto completion. Auto completion could just add the type for you without any typing just by type inference :-). And then I don’t care if the source has the type or not.

def nameable: Nameable = new Person()

I for one *do* think that type declarations are redundant when they can be inferred. A smart IDE, working in conjunction with an incremental compiler (a la Eclipse), could just decorate the code view with the inferred type of the member you’re looking at, e.g.

[Person] def person = getPerson

i.e. show the type of the member without the developer having to type it down redundantly. WDYT?

And perhaps you’ve got me wrong, I’m not against type inference. I wish Java was more clever with types. But I’m against dropping explicit types. I often see this with dynamic code:

// List of <Order>
def calculate(orders)

or

// Returns List of <Order>
def orders = getOrders()

where people add the type in a comment to document their code.

@Greg: “Your IDE could also tell you the types of things inline.”

Nameable nameable = new Person()

The IDE can’t decide which type I want.

This is just some kind of design by contract, where I have a type contract for my code. The explicit declaration of what my code expects, in this case a Nameable.

def nameable = new Person()

does not declare such a contract for my code. The code following this line has no declared expectations about the nameable variable.

public String createIdentifiier(id);

Could you tell me the type of id?

def getPerson() {
return Factory.getPerson();
}

Could you tell me the return type? I can’t. And the call chain could be much more complex so it would take more and more time to just check the types. And decide for the correct subtype or interface of the return type.

“person is a fairly meaningless variable name. You’re actually duplicating the type in the name, when you probably would be better off picking a better name, or getting rid of the name”

So, what is a better name? Current? I can’t see how

def current = Factory.getPerson()

makes anything more clear.

Peace
-stephan

Having completion doesn’t make the extra code worth having, it just reduces the number of finger presses to make it appear.

“When not working with the code for some time or another developer taking over - then is where the problem rises it’s head.”

The same IDE-using developer is certainly able to glance at the original method to see what types it has, and maybe just hover over the variable declaration to see what type the inference has given it.

“def person = Factory.getPerson()
Is person of class Person? Or perhaps Student or Employee? I’m wading through legacy code and the first thing that gets out is correct naming.”

person is a fairly meaningless variable name. You’re actually duplicating the type in the name, when you probably would be better off picking a better name, or getting rid of the name. Any time you rename a class, even in Java, you can end up with this kind of variable name becoming out of sync (IDEs can help in simple cases).

“remove unneeded (cast)s where I declared the type explicitly”

Where do you need such a cast? I’d guess most of those are misuse or lack of use of generics.

“Nameable nameable = new Person();
printName( nameable );
Can I do this with type inference?”

Yes. There’s no logic that says that type inference must always pick the most concrete type. However, as there’s no difference in functionality in your above code between you using Nameable or Person, it doesn’t matter much which is picked.

About your ArrayList example in particular, ArrayList is an example of bad API, as it exposes a List implementation by name, instead of just providing a method that gives you a List (and the actual implementation would be private/anonymous). In fact, as I’ve never adapted any code from using ArrayList to using some other implementation, I’d go so far as to say for that example, using ArrayList as the variable type isn’t insane.

“Explicit typing is about reducing scope, knowledge and coupling”

Explicit typing increases coupling by name, simply by making you repeat names. IDEs or other language-aware tools can give you everything that explicit typing has, but in a type-inferred environment.

The usual case in inference is that you can override the compiler’s choices if you like, so languages with inference only *allow* you to elide types, they don’t force you to. A step up on the ladder.