Comment On Barely Missing the Concept

Woah! Did he/she miss the point! OMGLOLWTFBBQ!

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

You know, the funny thing about this comment is that you, too, absolutly missed the real point about what is wrong with the code ;)

Just a hint: The concept is called virtual function...

Coderguy:

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

You know, the funny thing about this comment is that you, too, absolutly missed the real point about what is wrong with the code ;)

Just a hint: The concept is called virtual function...

What's even funnier is that your sarcasm detector seems to be on the fritz again.

Actually had to read that twice to figure out what the developer was trying to do.

Where I come from, we call that going around your elbow to get to your thumb, or schedule in this case.

I'm pretty sure that comment was made in jest. The :) at the end kinda gives it away.

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

switch anyone?


or even using GetType() and using that to cast directly would have worked too.

The even funnier thing about this comment is that you, too, absolutely missed the point of Optimizer's comment.

Just a hint: sarcasm. :)

Coderguy:

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

You know, the funny thing about this comment is that you, too, absolutly missed the real point about what is wrong with the code ;)

Just a hint: The concept is called virtual function...

Someone forgot to parse the sarcasm tag. :)

Don't know api, but i guess he could have just:

nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

or am I missing something.

ParkinT:

Now that really makes me say WTF!
That's like inventing the wheel and trying to roll it SIDEWAYS!!

Oh, you saw that Superbowl commercial too?

Jens:

Don't know api, but i guess he could have just:

nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

or am I missing something.

He could simply have omitted the typecast and done it precisely once instead of an via if-else chain (eg: you are correct)

For those that missed it the first time, let me help you out:

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

Jens:

Don't know api, but i guess he could have just:

nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

or am I missing something.

He was very close to a major breakthrough. Yes, this would have worked--but he first needed to add GetNextScheduledTask to the interface, which would have prevented the code from compiling unless the classes all implemented the method, which would have then made the above code valid.

Seriously, shouldn't people just assume that people who are blatantly explaining the WTF and what they should have done are generally doing it in a sarcastic manner?

Just stop trying to correct people, people.

WhiskeyJack:

For those that missed it the first time, let me help you out:

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

Using If or else If or whatever is completely unnecessary--the programmer is trying to make use of Class Factories--and doing a very bad job at it. He missed one simple point--put the GetNextScheduledTask method in the interface.

It's a Feature:

He was very close to a major breakthrough. Yes, this would have worked--but he first needed to add GetNextScheduledTask to the interface, which would have prevented the code from compiling unless the classes all implemented the method, which would have then made the above code valid.

Either the method should have been in the interface, or at least in a sub-interface (to deal with the possibility of not wanting the method everywhere). Makes me wonder if the original programmer was paid by the line...

Seeing that makes me sad. Poor guy worked so hard to get that far and missed the boat. Hopefully he figured that out on his next project. (Perhaps after all of his co-workers mocked him?).

durnurd:

Seriously, shouldn't people just assume that people who are blatantly explaining the WTF and what they should have done are generally doing it in a sarcastic manner?

Just stop trying to correct people, people.

But someone on the internet is WRONG! And they'll stay that way if I don't correct them. (Thx, xkcd)

DeltaGeek:

ParkinT:

Now that really makes me say WTF!
That's like inventing the wheel and trying to roll it SIDEWAYS!!

Oh, you saw that Superbowl commercial too?

Wheel suck.

(or in this case)
Interface suck.

I suspect that to misuse a class this badly, he probably didn't write the class to begin with.

It was probably written by another, more competent programmer and this guy was given the task of using it.

durnurd:

Just stop trying to correct people, people.

Hey, stop that.

Has this guy not heard of virtual table lookups???

snoofle:

Jens:

Don't know api, but i guess he could have just:

nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

or am I missing something.

He could simply have omitted the typecast and done it precisely once instead of an via if-else chain (eg: you are correct)

All right, I might get blasted for this, but I think you want "(i.e.: you are correct)" instead of the eg. It's a minor annoyance I have ;) EG means "For example" and IE means "In other words"

/Knowing is half the battle

Slightly off topic: I've seen many, many uses of "i.e." (id est = that is) to mean "e.g." (exempli gratia = for example) but I think that's the first time I've seen someone use "e.g." when "i.e." was the correct term.

snoofle:

Jens:

Don't know api, but i guess he could have just:

nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

or am I missing something.

He could simply have omitted the typecast and done it precisely once instead of an via if-else chain (eg: you are correct)

Edit to include quote:
Slightly off topic: I've seen many, many uses of "i.e." (id est = that is) to mean "e.g." (exempli gratia = for example) but I think that's the first time I've seen someone use "e.g." when "i.e." was the correct term.

ParkinT:

Now that really makes me say WTF!
That's like inventing the wheel and trying to roll it SIDEWAYS!!

Or like taking a car driving it in reverse all the time. Now if only he can turn the seat around and put the steering wheel on the other side. Hmmmm....

I think it's good for people to know the difference. In some of the code I maintain, I've sometimes seen i.e. and e.g. used incorrectly in such a way that complicates what the writer was trying to say.

I too often see code like this, why bother define and use interfaces if you going to stick in a static if/else or switch block anyway.

Get rid of the id and a single line solves your issues:

IScheduledTask nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

I'm currently reviewing code and have come across the following so many times:

boolean rtn = false;
if ( <expression> ) {
rtn = true;
}
return rtn;

Review comment:

how about using the following
boolean rtn = <expression>;

and he was so close to having it right! so close....

Poor guy. He was so close.

So, he should have used reflection to find a method with the appropriate name and signature to solve the job?

or simply return <expression>?

It took me a while to figure out what the heck was going on here, because Java implements all methods as virtual functions automatically and I forgot that in some languages you have to actually declare them as such.

As to the WTF: Wow.

You can tell this was written by someone who read the first page of a textbook section, but didn't bother reading the rest of it...

Maybe I'm missing something, but it looks like the typical way people have to code around the limitations of statically typed languages such as Java in order to implement polymorphism.

mathew:

Maybe I'm missing something, but it looks like the typical way people have to code around the limitations of statically typed languages such as Java in order to implement polymorphism.

Hey! Don't diss on statically-typed languages, at least with them 2 + 2 = 4 always, and not "22" as I might get with the typeless languages. Oops!

Heh, reading this code feels like Deja Vu ... I remember watching a similar block of "else if / instanceof" sentences on a fellow student's Java code back in 2004. Thing is, the teacher was lecturing on... polymorphism. Looks like some of them didn't get the idea...

"schedule" is one of those words that cease to make any rational sense after staring at it too long.

David:

Seeing that makes me sad. Poor guy worked so hard to get that far and missed the boat. Hopefully he figured that out on his next project. (Perhaps after all of his co-workers mocked him?).

Might be best. The real version does not work

mathew:

Maybe I'm missing something, but it looks like the typical way people have to code around the limitations of statically typed languages such as Java in order to implement polymorphism.

WTF?
statically typed ... polymorphism

Really, WTF?

Not related.

It's a Feature:

Using If or else If or whatever is completely unnecessary--the programmer is trying to make use of Class Factories--and doing a very bad job at it. He missed one simple point--put the GetNextScheduledTask method in the interface.

Thank you for sharing your radiant wisdom with us lowly denizens of the intertubes, Captain Obvious IV.

mathew:

Maybe I'm missing something, but it looks like the typical way people have to code around the limitations of statically typed languages such as Java in order to implement polymorphism.

You're missing the fact that Java has no limitations that require this sort of idiocy - by using an interface, the implementation could be exactly as short and polymorphous as in any dynamically typed whiz-bang hype language.

And don't bother saying "But with duck typing, the classes don't have to explicitly implement an interface, so it can be used with classes that you have no control over". Instead, answer me this question: how likely is it that classes that were not designed to an explicitly defined common interface would share methods with the same name, signature and purpose?

I guess you need to understand OOP to understand this WTF...

Even reading the comments, I don't get the WTF. :(

Daniel:

I guess you need to understand OOP to understand this WTF...

Even reading the comments, I don't get the WTF. :(

OOP has a concept called polymorphism, which makes it completely irrelevant what kind of schedule it is - since presumably all schedules have the GetNextScheduledTask() method, you can directly call the method on any object of type schedule.

How about someone explain this to those of use who aren't full time coders.

Even reading the comments, I don't get the WTF. :(

http://en.wikipedia.org/wiki/Virtual_functions

Daniel:

I guess you need to understand OOP to understand this WTF...

Even reading the comments, I don't get the WTF. :(

May I?

An interface defines a common set of properties and methods. Any classes that claim to implement those interfaces must implement all properties and methods of the interface.

The assumption here is that all of the distinct types of Schedule (DailySchedule, WeeklySchedule etc.) implement the interface Schedule, and the interface Schedule specifies the GetNextScheduledWhatever method. We can assume the first point because the code sticks the object in a variable of type Schedule. The second we can't assume, but if Schedule doesn't specify GetNextScheduledWhatever when all of it's implememtors do then that's a WTF in itself.

But, if our original assumption is correct, the compiler / runtime knows that every Schedule implements GetNextScheduledWhatever. As a result, the coder can call GetNextScheduledWhatever on any object that is an instance of Schedule, without knowing it's native type (DailySchedule, WeeklySchedule, etc.). The WTF is that apparently the coder didn't know this, so he did a complex type-casting exercise, that was completely unnecessary...

You know, I never realised the concept of Interfaces was so difficult to explain. I think I might actually be feeling pity ofr the coder of this WTF after all... ;^)

Mick Kerrigan:

JP London:

Review comment:

how about using the following
boolean rtn = <expression>;

or simply return <expression>?

What he said, but more so ;^)

I'd also be willing to bet that, in the code JP was reviewing, &ltexpression&gt was quite often along the lines of &lt;bThis == true && bThat == false&gt;. I can't count the number of times I saw that in other people's code when I was doing my MSc. Enough to make an experienced programmer weep...

taylonr:

Coderguy:

Optimizer:

Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

You know, the funny thing about this comment is that you, too, absolutly missed the real point about what is wrong with the code ;)

Just a hint: The concept is called virtual function...

What's even funnier is that your sarcasm detector seems to be on the fritz again.

Oh, a sarcasm detector, that's a REAL useful invention <detectorExplodes />

I've seen code like that:

switch(pObj->GetType())
{
case Type1:
delete (ObjectType1*) pObj;
break;
case Type2:
delete (ObjectType2*) pObj;
break;
case Type3:
delete (ObjectType3*) pObj;
break;
case Type4:
delete (ObjectType4*) pObj;
break;
}

Apparently, a concept of virtual destructor has escaped the designers.
This code might be running in your laptop, controlling your soft modem.