On Sun, Jul 13, 2014 at 12:18 PM, Alain Williams <a...@phcomp.co.uk> wrote:
> On Sun, Jul 13, 2014 at 09:16:33AM +0100, Lester Caine wrote:
> > On 13/07/14 06:22, Stas Malyshev wrote:
> > > It is very direct specification of
> > > either strict parameter typing or coercive parameter typing. I don't
> > > think using confusing terminology helps anything here. I think it was a
> > > mistake to introduce this term from the start and we should stop
> > > propagating it.
> >
> > It does come across as as an attempt to hide the 'strict parameter
> > typing' which is something that is very much less attractive. If I
> > wanted that then I'd simply switch back to C/C++ direct which is perhaps
> > where we are now heading anyway with the increasing use of pre-compiled
> > application code?
> >
> > One of the reasons I persist with PHP is the fact that many of my users
> > can adjust the odd PHP file correcting sequence or modifying text
> > without having to learn the intricacies of formal programming. It's
> > adding all these complex layers that is taking PHP away from it's more
> > novice friendly base ... If you want a formal programming language then
> > just use one?
>
> I don't see the current PHP type juggling as 'formal programming'. It makes
> things easy but can also lead to bugs where unexpected values (& so types)
> end
> up being inappropriately used.
>
> This RFC does not mandate the use of type hinting so your users can still
> get
> away with quick/sloppy programming. That does not change.
>
> However: it does allow others to gain extra assurance that their programs
> are
> not dealing with bad values (& so types) if they wish to. I can see that
> the
> first areas where this will be used will be in objects/libraries that
> others
> use. It will be good to use type hinting to bring out bugs where a bad
> value has
> slipped by validation. The users of such libraries would not need to make
> changes as a result of this.
>
> I can see that it will also allow run time optimisation. If a value is
> known to
> contain an integer then code like ''$a == $b'' could be an integer
> comparison
> rather than having to first determine what the types might be and then end
> up
> doing integer compare.
>
>
> So: I strongly support this RFC.
>
>
> I would also like to suggest an addition. That is the ability to declare
> local
> variables to functions maybe using the using the keyword 'var'. So you
> would go:
>
> function foo(int $a)
> {
> var $b; // $b has no type hinting
> var float $c; // $c is a float
> string $d; // alternative to the syntax used for $c (see below)
> }
>
> I would like, eventually, PHP to have a mode where use of an undeclared
> variable
> would lead to an error being raised. A model for this is perl's ''use
> strict''.
> The way that this could be done in PHP is that if a variable is declared
> with
> 'var' then strict mode is switched on for the function. This would
> provide a
> distinction between the above declarations for $c and $d ($c switches on
> strict
> mode, $d does not).
>
> This would be OPTIONAL - ie if you do not want it then do not use 'var'
> and it
> will not impinge; if you use it then you get the extra checking that it
> brings.
>
> Should I raise an RFC for this ?
>
>
I think it would be better to reuse declare() instead of reusing var.
What error level would it emit though?
I anything below E_RECOVERABLE_ERROR, then it doesn't do anything, but
prints a line to the error log(and or displays it), which we already do,
because using an undefined variable will emit an E_NOTICE
I think it is a good thing if we make it easier to spot programming errors
and bail out early instead of trying to guess the developer's intention,
but I don't think that adding more fatal errors or
E_RECOVERABLE_ERRORs(which will be fatal if there is no userland error
handler defined which explicitly allows to continue the execution).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
