Two birds, one article

[silicate]

Hey there,

There have been a few threads recently that related to two topics:

1. Dynamic (Duck) Typing
2. Premature Optimization

I read an interview of Bjarne Stroustrup this morning where he talks about "Abstraction and Efficiency" in programming.

I agree with his points about both dynamic and statically typed languages, and was pleased to note that in PHP we can choose which method we want to use. I was porting some java code to PHP yesterday and was so glad that in my unit tests the code changed from this:

TimeRate rate = new TimeRate(new BigDecimal("100.00"), Duration.minutes(3));

to this:

$TimeRate = new TimeRate(100.00, Duration::minutes(3)); 

The PHP version seems so much more readable without the clutter of typing. That being said, this is the PHP5 constructor for TimeRate where I use static typing to clearly state that the second parameter must be an instance of a Duration:

public function __construct($quantity, Duration $unit) {
    assert("$quantity > 0");
    $this->Quantity = $quantity;
    $this->Unit = $unit;
 } // end constructor 

Look at the code again while imagining that the Duration type is not specified. That could be a constructor for just about anything. I believe that more insight into the purpose of the entire class is garnered by adding the type hint to the constructor. The assertion on the $quantity is another tool for making the purpose of $quantity more clear. You know that it is supposed to be a postive numeric value.

The second part about premature optimization is certainly true for the C++ compiler, I wonder if statically typing parameters helps the Zend engine optimize PHP code?

[XoloX]

Think I'm in the same split as you are (?): I like static typing because of the unambiguity, but at times it feels like a burden. Example: I'm writing an editor in C# atm, and sometimes it seems overkill:

return (SimpleToken[]) SimpleTokens.ToArray(typeof(SimpleToken));

I wonder if statically typing parameters helps the Zend engine optimize PHP code?

I'd rather think it makes things slower , but then, I've never worked with the C PHP sources. Also, I think there's not to much room for optimization in your average PHP environment since most requests take about 0.01 second (or less). It would be more appropriate in a FastCGI or Opcode-cached environment.

[Selkirk]

The second part about premature optimization is certainly true for the C++ compiler, I wonder if statically typing parameters helps the Zend engine optimize PHP code?

It doesn't.

[shea]

return (SimpleToken[]) SimpleTokens.ToArray(typeof(SimpleToken));

The .NET 2 environment has Generics which simplify this task.

[McGruff]

Silicate: did you also want to discuss type hinting? I'd suggest a simple rule (not just for type hints): if the unit test passes without it you don't need it and therefore should leave it out. The class which instantiates Duration is responsible for creating an object of the correct type and its own unit test could verify that it does so, if that's an issue at all.

When I have to start working with php5 I can see myself writing a script which strips all hints from code. Documentation is something you always regret. One day you might discover that you don't really want to be dependent on a Duration class at all - just the interface (or a part of it).

I'd personally be more concerned with trying to write unit tests which provide clear "documentation" ie going more for lots of little test methods which make specific points rather than large, less focussed ones.

[kyberfabrikken]

I wouldn't say that I disagree with you McGruff, but I don't think it's just that simple. If you rely on tests as your only documentation, yes, but self-explaining code is an important type of documentation as well. If I'm using a third party library, it can be really helpful to get a runtime-error when I accidentially call a method with the wrong type. I will not only know there was an error, but I'll also get a hint at what I should have done. Typing helps to raise the error earlier and thus closer to the source, which tends to make debugging easier.

[stereofrog]

The second part about premature optimization is certainly true for the C++ compiler, I wonder if statically typing parameters helps the Zend engine optimize PHP code?

Typehints are checked at runtime with an extra function call. That is,

function foo(Bar $bar) { 

is equivalent to

function foo($bar) {
   assert($bar instanceof Bar); 

[XoloX]

The .NET 2 environment has Generics which simplify this task.

Thanks. Haven't played much with 2.0 since I installed it this week. But I've started going through the new features, amongst which Generics

[silicate]

Hey there,

@McGruff:

I am fully a completely a convert to TDD, and try my best to test all assumptions about input and expections about output from a method that I am testing. I do find that well-written tests provide a good source of documentation, especially on my current toy project where I am porting some Java to PHP. The java source has JUnit tests with it, so by porting the tests to PHP first I am ensuring that I meet the specs of the original in full.

That being said, I am also a huge fan of auto-documenting with phpdoc. I think the perfect example is that when I want to see what expectation tests are available in SimpleTest, I don't open up the tests and look through all of the cases for the tests on the expectation methods. I open up the API docs in my browser and click on stuff... When I click on the method source link to see the implementation I am taken to the source, not the tests.

I guess I find the difference is basically that tests are good documentation for developers of the package, and the self-documenting source is for users of the package.