No. It is the other way around I'm thinking. Class.forName given a
name as a string gives me the corresponding Class object, which can then
be used to do whatever, like creating objects and so on. Very powerful
stuff reflection is. This is generally rarely used since the compiler
cannot help you in any way (the string is first given at runtime), as
opposed to just "new WhateverObject".

FWIW, PHP has a reflection API as well. http://us3.php.net/reflection

It looks like that is what you do too in your snippet. My argument is
that by doing this, the compiler cannot help you, and your programs get
more brittle which makes it easier to break if you need to do major
maintainance.

By saying "new User()" in Java the compiler knows all about the User
class and can complain if your code is broken.

PHP won't complain until runtime, but the IDE may. I know that Java, C++, C#, heck, even VB developers won't believe this, but even though the PHP compiler won't complain prior to runtime this is very seldom an issue. I have only my own anecdotal experience on it but that experience runs through many different companies (being that I'm in services) and compiler-level issues seldom are problems. If they are, it's usually because someone edited a file manually, in production.

Just to be certain - does the PHP _compiler_ know if you write "$userObj
= new User()" that $userObj is a User and that only operations provided
by the User class is allowed, or is this only checked by the runtime?

PHP is not compiled until runtime and so the type is only checked at that point. But "runtime" is usually the next refresh of the browser during development or the next run of your unit tests and problems are usually detected long before production. Ironically, I probably get just as many Java ClassNotFoundException exceptions as I do invalid classes in PHP when I write code.

One thing I should correct myself on is that while you have static type checking for arrays and objects for function and method parameters, and instanceof checks available at any point, you do not have it for return values. However, even the simplest IDEs have the ability to understand PHPDoc and use it similarly to annotations. Variations from what you document in your code may cause a fatal error in PHP, but if you follow even the most basic of documentation standards, the IDE will help you out. This I can understand as a legitimate criticism from the static-typing crowd and would concede that strongly typed return values have value. But, like the previous examples, the actual impact is much lower than what the static typing crowd would expect.



You can state the type for objects and arrays. You don't have to, but you can and should. I probably write my code in a more structured manner than > a lot of PHP developers, but a good portion of them are really starting to take architecture seriously and building well defined class, interfaces and > such... and actually FOLLOWING a defined architecture. PHP has a bit of a reputation as a fly-by-night language. Some of that is deserved but new > applications are being built much better than even just 2 years ago. So, yes. I'm seeing a lot of new development following proper OO patterns, more or > less.


Ok. So you are basically saying that you PRAY that the previous
programmer did the program nicely :)

To some degree, yes. But I can also say the same thing about Java, having also worked with it for several years (one of the talks I give is on integrating Java and PHP http://www.slideshare.net/SamHennessy/caffeinated-php-zendcon-2009 ). >From my personal experience, variable type is usually down on the issues list in either environment.

Praying is good - makes you think about what is important in life :D

I am as I said genuinely curious about this :)


Excellent! Curiosity kills only cats.

He he. You know http://thedailywtf.com/ ?

I do now.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.