SitePoint Sponsor |
|
User Tag List
Results 1 to 9 of 9
Thread: Two birds, one article
-
Apr 24, 2006, 10:48 #1
- Join Date
- Nov 2004
- Location
- Toronto
- Posts
- 43
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Two birds, one article
Hey there,
There have been a few threads recently that related to two topics:- Dynamic (Duck) Typing
- Premature Optimization
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:
Code:TimeRate rate = new TimeRate(new BigDecimal("100.00"), Duration.minutes(3));
PHP Code:$TimeRate = new TimeRate(100.00, Duration::minutes(3));
PHP Code:public function __construct($quantity, Duration $unit) {
assert("$quantity > 0");
$this->Quantity = $quantity;
$this->Unit = $unit;
} // end constructor
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?later,
Matthew.
-
Apr 24, 2006, 11:12 #2
- Join Date
- Mar 2006
- Posts
- 22
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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:
Code:return (SimpleToken[]) SimpleTokens.ToArray(typeof(SimpleToken));
I wonder if statically typing parameters helps the Zend engine optimize PHP code?, 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.
-
Apr 24, 2006, 12:31 #3
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by silicate
-
Apr 24, 2006, 17:33 #4
- Join Date
- Sep 2005
- Posts
- 122
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by XoloX
-
Apr 24, 2006, 19:14 #5
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Apr 24, 2006, 19:43 #6
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Apr 25, 2006, 01:16 #7
- Join Date
- Apr 2004
- Location
- germany
- Posts
- 4,324
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by silicate
PHP Code:function foo(Bar $bar) {
PHP Code:function foo($bar) {
assert($bar instanceof Bar);
-
Apr 25, 2006, 07:38 #8
- Join Date
- Mar 2006
- Posts
- 22
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by shea
-
Apr 25, 2006, 08:03 #9
- Join Date
- Nov 2004
- Location
- Toronto
- Posts
- 43
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.later,
Matthew.
Bookmarks