Because it's object-oriented, right?

[zelmak]

How often have you had to put up with this kind of crap?

public boolean reinstateData(Object data) {
  boolean rtn = false;
  if (data instanceof Foo) {
    rtn = reinstateFooData((Foo) data);
  } else if (data instanceof Bar) {
    rtn = reinstateBarData((Bar) data);
  } else if (data instanceof Baz) {
    rtn = reinstateBazData((Baz) data);
  } else {
    rtn = reinstateFileNotFound(data);
  }
  return rtn;
}

The user of this class doesn't have to care what objects (see? object-oriented) it needs to reinstate, just toss it over here! Because it's scary to know what data type/class/object type I'm working with ... I don't want to have to know what type it is, so I'll wrap it!

YOU'VE ALREADY WRITTEN THE BLOODY TYPE-SPECIFIC METHODS, JUST USE THE DAMNED THINGS!

[Ben L.]

Here's the great thing about strongly-typed languages: You can delete that function and then fix the zero or one places it's called from in the code. Then pretend it never happened. You must never speak of this.

[morbiuswilters]

@Ben L. said:

Here's the great thing about strongly-typed languages: You can delete that function and then fix the zero or one places it's called from in the code. Then pretend it never happened. You must never speak of this.

Well, assuming there aren't other libraries and/or applications floating around out there that expect this function to exist. You really don't seem to understand much about how real software development works, dude.

[henke37]

I don't see the problem here. The language might resolve the callee by the declared type of the argument, not the actual type.

[Chame1eon]

@morbiuswilters said:

Well, assuming there aren't other libraries and/or applications floating around out there that expect this function to exist. You really don't seem to understand much about how real software development works, dude.

 

How likely is it that something like this becomes impossible to remove?

[Ben L.]

What are the chances something will call this function from a point in the code where the type isn't already known?

[morbiuswilters]

@Ben L. said:

What are the chances something will call this function from a point in the code where the type isn't already known?

No, I'm saying: in a real-world situation you may not have the ability to fix everywhere this is called. I'm not justifying the original code; I see no reason for it to exist. All I'm saying is "Just delete that function and the compiler will tell you where to fix it" is an incredibly unrealistic view of how software engineering works.

For all you know, this is part of some published API. There could be hundreds of different instances of object code floating around out there that you don't have control over. You can't just delete it and "never speak of it again" unless you want to lose your job.

Or, shit, maybe it's only used in a single place. A place you can change. But that code is jealously guarded by Smelly Joe, who angrily rants and raves when anyone touches his code. And if you say "Hey, Smelly Joe, can you change this function call so it casts to the actual type and resolves to the appropriate function?" he's gonna go rand and rave and tell everyone you're being dumb.

And since everyone knows Smelly Joe, they know he's full of shit and that your request is technically correct, reasonable and in the best interests of the company. They also know that Smelly Joe is paid $300k /year to maintain some very obscure systems, and that if somebody asks him to change his code he will stomp down the hallways, bellowing his displeasure. Then he will call a meeting with the CEO and tearfully threaten to quit. And the CEO, realizing that you aren't a psychotic basket case who's going to quit if you don't get your way--and that Smelly Joe is the only person who understand the Incredibly Obscure System Written By Smell Joe which the company is utterly dependent on for continued survival and which breaks at least twice a week and must be carefully nursed back to health to by Smelly Joe himself--will appease Smelly Joe. (Basically true story!)

Oh shit. I just re-read your comment and I think you meant something else. I think you meant "What is the likelihood that any object code will be linked against the Object overload and not one of the more-specific overloads?" Is that right?

I'm still gonna leave my first reply, because I think it contains some good points. Also, I like the story of Smelly Joe. But to answer the query that I think you queried: who the fuck knows? Are you saying people dumb enough to write this code didn't write a bunch of shit where they cast everything to Object? This is TDWTF: you should know by now that the only limitation to people's stupidity is their incredibly stupid imaginations which, despite being incredibly stupid, are terrifyingly creative.

[morbiuswilters]

@Chame1eon said:

@morbiuswilters said:

Well, assuming there aren't other libraries and/or applications floating around out there that expect this function to exist. You really don't seem to understand much about how real software development works, dude.

 

How likely is it that something like this becomes impossible to remove?

Read my story about Smelly Joe directly above. Short answer: I don't know. Sometimes you can't get rid of stuff like this; you just learn to live with it. Maybe your only recourse is writing some killer documentation for this function which makes smart people question not only the reason for this function's existence, but their entire choice of career.

[morbiuswilters]

@henke37 said:

I don't see the problem here. The language might resolve the callee by the declared type of the argument, not the actual type.

This is Java and that's what Java does. But it's still bad code: why should anything be calling this as an Object? At the very least, it should be using proper polymorphism and have an interface which Foo, Bar and Baz all implement. Then you wouldn't need four versions of the same function.

[Severity_One]

@zelmak said:

How often have you had to put up with this kind of crap?

You can do the same with exceptions. We've had a developer who simply was too lazy to use any other exception than java.lang.Exception. (He was also too lazy to use Subversion. Guess who's maintaining his code these days. Wheee!)

The result is that you end up with instanceof in an exception handler, or parsing the detail message (since he was also too lazy to return null if an object was not found, and instead threw java.lang.Exception).

So how often exactly, I don't know. But more often than I care to remember.

 

[morbiuswilters]

@Severity One said:

since he was also too lazy to return null if an object was not found, and instead threw java.lang.Exception

return null; is less work than throw new Exception("blah blah blah blah");. So arguably, he wasn't lazy, just incredibly dumb.

[error]

Confession: I've written something similar for JSON serialization. I did have to handle Object as the main use-case was anonymous types, but I check to see if it's a primitive and handle those cases first. Yes, I realize I am TRWTF for not using a library for this.
Edit: my motivation was I wanted to camelCase JSON when the property was PascalCase, so I specify serialization names with attributes. Yes, this is a dumb reason.

[morbiuswilters]

@joe.edwards said:

Confession: I've written something similar for JSON serialization. I did have to handle Object as the main use-case was anonymous types, but I check to see if it's a primitive and handle those cases first. Yes, I realize I am TRWTF for not using a library for this.
Edit: my motivation was I wanted to camelCase JSON when the property was PascalCase, so I specify serialization names with attributes. Yes, this is a dumb reason.

Ten "Hail Dijkstras" and five "Our Turings".

[boomzilla]

@morbiuswilters said:

@Severity One said:

since he was also too lazy to return null if an object was not found, and instead threw java.lang.Exception

return null; is less work than throw new Exception("blah blah blah blah");. So arguably, he wasn't lazy, just incredibly dumb.

Possibly, except that callers didn't have to know what to do when they got a null. Of course, if the object should exist, then maybe an exception is the right thing. Shit. Too much ambiguity here. Let's talk about something easy, like Israel.

[eViLegion]

@boomzilla said:

Let's talk about something easy, like Israel.

I'll start. They deserve all the angry muslims being angry and showering them with rockets and bombs, right? And if you disagree with me, you must be made out of pure Hitler. Yeah.

[Severity_One]

@morbiuswilters said:

@Severity One said:

since he was also too lazy to return null if an object was not found, and instead threw java.lang.Exception

return null; is less work than throw new Exception("blah blah blah blah");. So arguably, he wasn't lazy, just incredibly dumb.

Actually, the guy is very smart, and did some pretty interesting things in libraries. But only with things that interested him, and actual work wasn't one of them.Arguably, you can return an error message in an exception, explaining perhaps why he chose that.

One particular library I'm thinking about accessed a database that had
absolutely no constraints, whether integrity constraints or check
constraints. Let's call it unfamiliarity with SQL.

He was also fond of static structures, because -you guessed it- they're less work to use. That they create a whole of of other issues, well, tough. I'm still trying to eradicate static structures from our code... because we've also had developers who grouped methods based on neatness, in other words how nicely they looked next to one another, and got around the inevitable mess of dependencies by using statics.

 I think I'll stop now; I find it difficult to talk about these issues.

[zelmak]

@Severity One said:

Arguably, you can return an error message in an exception, explaining perhaps why he chose that.

public class ValueException extends Exception {
  private final Object theValue;

  public ValueException() {
    this(null);
  }

  public ValueException(Object aValue) {
    super();
    theValue = aValue;
  }
}

public class DAO { 
  private final Connection conn;
  public DAO(Connection conn) {
    if (conn == null) {
      throw new IllegalArgumentException("JDBC Connection cannot be null!");
    }
    this.conn = conn;
  }

  private void getValues(String tableName) throws ValueException {
    List<Object> stuff = new LinkedList<>();
    String query = "select * from " + tableName;
    PreparedStatement pstmt = null;
    try {
      pstmt = conn.prepareStatement(query);
      ResultSet rset = null;
      try {
        rset = pstmt.executeQuery();
        while(rset.next()) {
          stuff.add(rset.getObject(1));
        }
      } catch (SQLException e) {
         // do nothing
      } finally {
        closeQuietly(rset);
      }
    } catch (SQLException e) {
       // do nothing
    } finally {
       closeQuietly(pstmt);
    }
    throw new ValueException(stuff);
  }
}

[morbiuswilters]

@eViLegion said:

pure Hitler

Pure Hitler does make a hell of a solvent. I've got some in my utility shed--great for getting out gum that's stuck in carpet.

[MiffTheFox]

@morbiuswilters said:

@eViLegion said:

pure Hitler

Pure Hitler does make a hell of a solvent. I've got some in my utility shed--great for getting out gum that's stuck in carpet.

If you dilute Pure Hitler, does that make a Final Solution?

[Guest]

@MiffTheFox said:

@morbiuswilters said:

@eViLegion said:

pure Hitler

Pure Hitler does make a hell of a solvent. I've got some in my utility shed--great for getting out gum that's stuck in carpet.

If you dilute Pure Hitler, does that make a Final Solution?

 

[drurowin]

@MiffTheFox said:

@morbiuswilters said:

@eViLegion said:

pure Hitler

Pure Hitler does make a hell of a solvent. I've got some in my utility shed--great for getting out gum that's stuck in carpet.

If you dilute Pure Hitler, does that make a Final Solution?

There's a carpet cleaning company in Joplin, MO called "Final Solution Services".  I wonder if anyone's ever called and asked them if they're able to clean out inferior races from Germany.

 

[realmerlyn]

Sadly, in a workshop, I saw Guido van Rossum doing precisely this... testing the class of an object, then calling a distinct method based on that. This completely made me turn away from Python. How could I trust Python to do the right thing, when the creator of Python DOES NOT UNDERSTAND OO PROGRAMMING.

[morbiuswilters]

@MiffTheFox said:

@morbiuswilters said:

@eViLegion said:

pure Hitler

Pure Hitler does make a hell of a solvent. I've got some in my utility shed--great for getting out gum that's stuck in carpet.

If you dilute Pure Hitler, does that make a Final Solution?

<3

[Ronald]

@realmerlyn said:

Sadly, in a workshop, I saw Guido van Rossum doing precisely this... testing the class of an object, then calling a distinct method based on that. This completely made me turn away from Python. How could I trust Python to do the right thing, when the creator of Python DOES NOT UNDERSTAND OO PROGRAMMING.

Another reason that Python cannot be trusted is that Guido van Rossum is the kind of person who wears his glasses too close to the eyes. That's the worse kind of people, those you can find in a war room at 4am making bad decisions while they rub the sore bridge of their nose.

[Severity_One]

@realmerlyn said:

Sadly, in a workshop, I saw Guido van Rossum doing precisely this... testing the class of an object, then calling a distinct method based on that.

Actually, I'm doing something very similar in my code. SImilar, but not the same.

This is a library that scans an interface with getter methods, and returns an object that extends BaseProperty. There is an IntProperty, StringProperty, QNameProperty, and even an EnumProperty. Then there's an InvocationHandler that returns the value of the property, read from a properties file. If you invoke a method on the interface, the InvocationHandler kicks in and returns the value of the property, stored in a Map.

 I don't think that there's an elegant work-around with polymorphism, because I'm using Class objects that come directly from the return type of a method and have nothing to do with instances of objects, or with primitives.

[morbiuswilters]

@Ronald said:

@realmerlyn said:

Sadly, in a workshop, I saw Guido van Rossum doing precisely this... testing the class of an object, then calling a distinct method based on that. This completely made me turn away from Python. How could I trust Python to do the right thing, when the creator of Python DOES NOT UNDERSTAND OO PROGRAMMING.

Another reason that Python cannot be trusted is that Guido van Rossum is the kind of person who wears his glasses too close to the eyes. That's the worse kind of people, those you can find in a war room at 4am making bad decisions while they rub the sore bridge of their nose.

His name is "Guido". That's all I needed to know.