Re: RE: Optional scalar type hinting

Stanislav Malyshev schreef: >> In a way this is true, but I look at it this way. Some languages are >> strictly typed, some are dynamically typed. PHP can have the best of >> both worlds by having optional strict typing where desired, as well as > > I do not believe trying to both eat cake and leave it intact would do us > well. Mixing strict and non-strict code would be a nightmare. possibly like the nightmare that namespaces will give us in there current form? I mention it because use of typehinting seems alot more voluntary and less intrusive (when one encounters it in 3rd party code) than namespaces will be. > Absence of > static type control (necessary for interpreted language) would make > strictly typed code less, and not more stable. Add performance penalty > from type checking and effort would be required from PHP newcomers to > understand two code models instead of one - and you get the worst of newcomers? or newbies? the level of entry is being raised in all sorts of areas whether you like it or not as a by product of making php more suitable to enterprise level development. it's merely a case of not being able to please everyone all of the time (or of not having your cake and eating it) > both worlds, not the best. why do we then have typehinting for objects? and more recently arrays? I also seem to remember (forgive me if Im mistaken) that you we're a proponent for the increases in strictness surrounding various things related to OO. that feels rather hypocritical at some level. > >> Strict typing allows very little room for type conversion. This is >> optionally hinting the desired type of a function parameter. > > That's not what I am hearing here on the list. you implied in another post that php should have some kind of structured direction. how about a language spec and a formal functionality proprosal/acceptance mechanism? (preferably one that didn't allow major changes like the inclusion of namespaces into a minor release)