My suggestion was to introduce type hinting gradually. First of all type hints, would be just that, hints. A suggestion as to the recommended type. If hints are used and the types do not agree, then this is an E_NOTICE. If you are using hints then you are expecting the types to be right. If you don't use hints, then nothing extra. The notice would be present simply because it is an advisary notice. Nothing is enforced. No type conversion would take place, but it would mean you could see which methods/functions are getting values which may need converting. Maybe this could be E_STRICT. By using hints, you are implying strict coding. I could go with that.

The next stage could be to allow automatic conversion based upon the normal type juggling rules OR to use a type conversion table which would use the same PHP functions that would be used in userland to do the conversion manually. In some cases this is just casting, but in other cases the conversion of 'december' to a number (for example) should result in NULL. I do agree (having re-read my own post) that a failed conversion is an E_ERROR (or E_STRICT again). Again, if you are using type hinting and are using automatic conversion, you have to obey the rules. It may be that you could supply your own conversion rules. A potentially useful feature would be to allow for a user defined automatic type conversion table. So, a user could effectively wrap the parameters to their own type and use their own type conversion logic. This does allow for the creation of user defined types (which I suppose are classes ... )

The final stage would be to apply a strict mode and that type hinting is actually type enforcement. If a function or a method says it ways an int, it must have an int. If not, then then this is a fatal error. No automatic conversion.

If this is combined with filtering, I think you should actually have a fewer type conversions. You get the data as a string from a user form. You know that the 3 columns representing a DOB are actually numeric. You use a filter to force them to numeric types. From that point on, why do you need to know that they are strings? You pass the values around as integers. If you pass them to a mktimt() function, they are in the correct type already. This SHOULD mean less type conversions.

WIBNI - a very old acronym for Wouldn't It Be Nice If. MH - the opposite to a WIBNI, a Must Have.

The introduction of type hints for scalars is under discussion. I'm strongly in favour of them. It may be that I don't need them once I start using the standard input filtering (I use my a mechanism described by Marco Tabini in php|Architect - Poka-Yoke).

I think this comes down to a set of choices.

You can do everything yourself. No hints, no automatic filtering, etc.

You can restrict what you want to do. Using enforced typing, using automatic filtering, etc.

I've come from an environment where each method/function is defined by the interface and the types. If I supply the wrong type the code wouldn't compile or worse. If PHP uses type hinting/enforcement, then for all the CURRENT PHP code out there, nothing would change.

Of course all of this can be avoided if you didn't use scalars but had all variables as objects (Eek! It would work - I think - but eek).

On 07/11/06, Richard Lynch <ce...@l-i-e.com> wrote: