Peec wrote:When you declare the datatype you will decrease the chance of getting "logic errors" and "bugs" because you will suddenly know what a variable is, it's purpose and how the variable can be used.
You'll know it's type (string vs integer, vs float). In fact it causes more opportunity for bugs (oops thought it was signed, but took the unsigned value, program crashed - this can't happen in PHP). Either way a logic error is something like sending the wrong value (yet correct type), so how exactly does strict typing help prevent logic errors?? By logic error I mean the programmer made a mistake, such as reversing a conditional accidentally during an attempted refactoring. The only thing I know of that helps reduce those kinds of errors are unit tests, which coincidentally are easier & faster to write in a dynamically typed language (no need to add new signatures).
And as for "its ugly" that doesn't even make sense, having less actual code on the screen is "ugly"? You think the more verbose way of writing the same thing is "prettier"?
Your second suggestion of wrapping primitives in objects contradicts your first suggestion of having strict type checking. If I just want an array of strings why should I have the overhead of having the objects? PHP allows you to create your own wrapper object, and just provides the primitive. Its a language, not a framework... Languages that use objects instead of primitives are at a disadvantage (presumably) as far as system resources go. Also if a language enforced usage of some particular class for all primitives, you'd have problem extending it since most languages are single inheritance. This can be seen in Java for example, where stubbing out these classes for unit testing is impossible, and it creates extra boiler plate "factory" code if you intend to extend the built in class later on down the road. (this is true of any class provided as part of the language)
For example consider something like 5.add(10) == 15, no "new" operator, they're not objects, just primitives with an object oriented like operator. Being able to mixin methods from the global namespace or something. What happens then when two libraries need to define a method called .foo() ? Does the latter defined method replace the one that was defined first? It's much easier for the two libraries to use their own class so there is no collision. This way if you want an object oriented interface, you can have one and there is no base class forced on you, and if you don't want object oriented interfaces on your primitives, you don't need one.
And in your post you say "string object", this confuses me