Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GlyphGryph]

Nooo. Nadaka, tell ME about the third way! What is the third way! What is it!

And I always forget the first way is an option in some languages. I can't imagine it would end well in most situations though.

And hey! C++ has duck typing now, right?

[Nadaka]

Nooo. Nadaka, tell ME about the third way! What is the third way! What is it!

And I always forget the first way is an option in some languages. I can't imagine it would end well in most situations though.

And hey! C++ has duck typing now, right?

The third way is called reflection. And I have already said too much.

[Vactor]

Have all your objects inherit the same class, something like "gameObject"  using something like this loosened the lid on how idiot proof your code is though, as you could potentially pass an inappropriate object without the compiler noticing, so make sure you use something to guard against that.

[Levi]

And hey! C++ has duck typing now, right?

It does?  That is pretty awesome, I prefer duck typing to inheritance most of the time.

[Nadaka]

I am not familiar with that phrase: "duck typing"?

[lordnincompoop]

And hey! C++ has duck typing now, right?

It does?  That is pretty awesome, I prefer duck typing to inheritance most of the time.

It doesn't have duck typing in the language itself. There's apparently a way to do it via Boost, though.

I am not familiar with that phrase: "duck typing"?

Quack quack.

[Levi]

I am not familiar with that phrase: "duck typing"?

"If it walks like a duck and talks like a duck, it must be a duck".

Basically its about the object's class not being as important as the actual methods it provides.

So with inheritance, you might see something like:

Code: [Select]

Class Automobile:
  def drive():
Class Car << Automobile
Class Truck << Automobile

With duck typing, you would just be happy enough that both objects provide the same method.

Code: [Select]

Class Car:
  def drive():
Class Truck:
  def drive():

list = [Truck.new, Car.new]
for each obj in list:
  obj.drive

This also can remove the problem of multiple inheritance, because as long as I provide the right methods to each object, it'll be happy pretending to be whatever you want.

The downside (to some) is that its a bit more dangerous and easier to mess up, because you don't have quite as strict interfaces keeping you honest.

[GlyphGryph]

Huh, I heard the new C++ 11 had something that could do ducktyping. Not everything was ducktyped, but that it was an option. Did I hear wrong?

"If it walks like a duck and talks like a duck, it must be a duck".

Note quite. It's more "If it walks like a duck and talks like a duck, treat it like a duck" Heh.

[Nadaka]

Yea, I do it all the time in javascript. That is horrible from a code maintenance POV and very strongly recommend against it, almost as much as you shouldn't use reflection.

[Levi]

Yea, I do it all the time in javascript. That is horrible from a code maintenance POV and very strongly recommend against it, almost as much as you shouldn't use reflection.

I love messy programming, so I like using both.   

[GlyphGryph]

Nadaka, what exactly are you recommending against, there?

[Nadaka]

Nadaka, what exactly are you recommending against, there?

Duck Typing. In javascript it is a necessity because of the nature of its inheritance model and universally dynamic objects. In a language with a solid class based inheritance model (like c#, c++ or java) it makes it difficult to know what kind of object you are dealing with. And enables occasional errors where the type of object you have is not the type that you expect and your code blows up. Using it means that you get an error at run time instead of compile time when you pass in an object lacking the features you need.

Its only real place is in tiny snippets of code you will never have to modify or maintain.

[Willfor]

But... reflection is the most fun thing I have ever found in programming. D: The easiest way to completely screw yourself over, yes, but damn fun in my opinion...

[GlyphGryph]

Well, admittedly, it might be a bad idea for those languages, because they weren't built with it in mind. But that's not because duck typing is horrible from a code maintenance POV, it's because you're trying to fight the language instead of using it the way it was intended.

For languages like Python, Lisp and Ruby, duck typing doesn't cause any of the above problems. And having looked it up just now, it SEEMS pretty reliable in C# (though I haven't used it myself there).

If anything, I've found it makes my code more portable, more easily maintained, easier to read, easier to change, and easier to work with overall. If you just want to limit your criticisms to say it makes things more difficult in Java or C++, sure, maybe I'll give you that. But you're original comment was a lot more sweeping.

And enables occasional errors where the type of object you have is not the type that you expect and your code blows up

If you're using it properly, this should be impossible.

Using it means that you get an error at run time instead of compile time when you pass in an object lacking the features you need.

And it also means you get to ignore a bunch of busywork that would create "errors" only in the technical sense that the language doesn't allow them, rather than because it won't actually work.

[LoSboccacc]

But... reflection is the most fun thing I have ever found in programming. D: The easiest way to completely screw yourself over, yes, but damn fun in my opinion...

next level: messing stuff around with bytecode injection!