Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34352
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <477D503E.1040701@iamjochem.com>
Date: Thu, 03 Jan 2008 22:14:38 +0100
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Sam Barrow <sam@sambarrow.com>, internals@lists.php.net
References: <200801031903.01980.tomi@cumulo.fi>	 <1199380881.15292.11.camel@sbarrow-desktop>	 <20080103172813.GQ7861@mint.phcomp.co.uk> <477D2B40.9010302@fischer.name>	 <477D2CDB.3000005@zend.com>	 <alpine.DEB.0.98.0801032022110.4763@kossu.ez.no>	 <477D452A.9090906@zend.com> <1199392531.15292.64.camel@sbarrow-desktop> <477D4ACF.3030006@zend.com>
In-Reply-To: <477D4ACF.3030006@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RE: Optional scalar type hinting
From: jochem@iamjochem.com (Jochem Maas)

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)