The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Given this set of classes and interfaces, later you can add a new class to a completely different family of classes and still pass instances of the new class to makeItTalk(). For example, imagine you add a new CuckooClock class to an already existing Clock family:

And that doesn't sound like a good reason to waste your one shot at inheritance. I recently did a grep over my source files to see how often I actually use the extends keyword and the only two scenarios that involved that keyword were when I was required to use it because of a third-party or when doing "interface <foo> extends <bar>"

And what on the earth is "qanimal"?

They're really cute and furry

gjones example is the best. Never write more code than needed to get it to work.

I'm firmly in the cut the clutter camp and public, private and protected don't really do anything useful either. Unless the code really needs to know something about itself hints etc just make it harder to read. That doesn't happen often.

Unless the code really needs to know something about itself hints etc just make it harder to read. That doesn't happen often.

It makes it easier to change the interface. If a method is declared private or protected, it's fairly easy to rename the method, because you have a limited number of places to look for. With a public method, you could potentially break any part of your application.

On the same note, I've found myself using typehints more recently - And as a consequence of that, interfaces (Since typehinting to a class is a hard coupling). Maybe it's just a phase I'm going through.

On the same note, I've found myself using typehints more recently - And as a consequence of that, interfaces (Since typehinting to a class is a hard coupling). Maybe it's just a phase I'm going through.

I also feel more comfortable using type hinting, though it's probably my preference of strongly typed languages.

I just can't bear having a parameter that I plan to call a method on, and having no ensurance that that method actually exists in that object. For example if Talkative is explicitly hinted in the parameter of makeItTalk(), I can be sure that talk() exists. Otherwise any old object could be passed and I couldn't be sure if it implemented that method.

As for the way to implement this in PHP, it'd be the same as in Java I guess. Whether I would have a separate talkative interface depends if other things besides animals need to talk. Also whether I would have an animal class at all depends if I really ever care if it's an animal, or just ever want to know if it can talk or not.

If both the above are true then yes, I would have a Talkative interface implemented by an animal abstract class. That's maximum flexibility; but you need to be careful not to take that too far. It'd be pretty absurd to have a Walker interface for animals too, for example.

I just can't bear having a parameter that I plan to call a method on, and having no ensurance that that method actually exists in that object. For example if Talkative is explicitly hinted in the parameter of makeItTalk(), I can be sure that talk() exists. Otherwise any old object could be passed and I couldn't be sure if it implemented that method.

But of course you could!

What happens when you pass as a type-hinted parameter an object that doesn't comply with the type? You get a runtime error.

What happens if you call a method of an object which doesn't have that method? You get a runtime error.

My point is that the sense of security you get from type hinting is a false one, and that (at least in PHP) it doesn't add any benefits you don't have with duck typing.

I'd agree that you don't need insurance against calling a method which doesn't exist: just don't pass the wrong kinds of objects. If you did, you'd soon know all about it even without a hint.

Hints do one of two things: provide documentation or define metadata for introspection. The only time they are really essential is for the latter. Phemto, for example, uses type hints to fill dependencies.

If the aim is to write simple, elegant code it's very important not to make things more complicated than they need to be. Everything has to justify its place anything that isn't essential should be stripped away.

Did you think at the time, your design will be more flexible because of this? Or do you precieve your design is more flexible Kyber?

I don't think typehints makes the code more flexible. Perhaps even the opposite. The value, it's adding is clarity. When you write very composite code, where there are multiple objects working together to produce a result, it can be hard to follow, where each part plugs into. By using typehints, it becomes obvious how the puzzle should be assembled. There are other ways to accomplish this, but since there is language level support for typehints, it seems more appropriate to use, than a userland solution. This of course is the same argument, McGruff makes about dependency injection containers, but I think it applies to manual assembly as well as automatic.

> but since there is language level support for typehints, it seems more appropriate to
> use, than a userland solution.

This is how I looked at it when PHP5 was first launched; I didn't just want to develop with PHP but I wanted to support it as well. Since then though, I've grown accustomed to using type hints in near 99&#37; of my scripts.

There are a few places where I don't use type hints, although it's not common, for example here,

It makes sense not to put a type hint here for the $logger since there may be an occasion where I need to pass in something that would break the interface... But in saying that my framework is pretty much structurally sound, so it's more uncommon for me to do something like this, rather than be it more common (not to use type hints).

As to flexibility, I still think the flexibility is still there provided the underlying structure has been well thought out, using type hints.

What happens when you pass as a type-hinted parameter an object that doesn't comply with the type? You get a runtime error.

What happens if you call a method of an object which doesn't have that method? You get a runtime error.

My point is that the sense of security you get from type hinting is a false one, and that (at least in PHP) it doesn't add any benefits you don't have with duck typing.

It depends on what you do with the object, though. If you pass it to a constructor and keep it in an instance variable, you won't get the error until later. So my rule of thumb is that type hints are somewhat more useful in constructors than in other methods. I also find that the more recently added type hinting for arrays is more useful than object type hints.

I don't use object type hints much. I did for a while, but found that they made refactoring harder even though I tried to use them sensibly.