On Thu, Jan 15, 2015 at 4:25 PM, Pavel Kouřil <pajou...@gmail.com> wrote:

> On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano <j.boggi...@seld.be>
> wrote:
> >
> > Reading the thread at this point shows so much confusion, it seems half
> the
> > people reading the spec misunderstood that the declare() line affects
> > function calls only and not the API/implementation level.
> >
> > As much I think it was a smart idea and workaround, it is perhaps too
> clever
> > for its own good if nobody gets it.
> >
> > Anyway, as v0.2 appears to be v0.1 + declare(), why not keep those two
> > options separated in the vote?
> >
> > a) should be add weak typing
> > b) should we also add declare() for to get strict typing at call-site.
> >
> > If *a* passes it would be a great stepping stone towards adding *b* later
> > perhaps, or tweaking internal coercion rules to improve the behavior of
> the
> > weak types, having scalars in return hints (since return hints seem
> likely
> > to pass), etc.
> >
> > If *b* passes as well great we have a complete picture and every team can
> > have declare() Y/N in their own coding guidelines based on preference.
> >
>
> Yeah, while the confusion is definitely still there, I would
> personally argue that definitely some people who oppose the declare()
> get that it's only for calls in the file - and still don't find it
> clever.
>
> The potential issues with this are pretty real, to be honest. Simple
> things like moving a method from one class to another (let's say to
> parent or descendant) and getting to another typing context may cause
> unpredictable behavior if the user forgets to have declare() in both
> files.
>

This alone is a very big argument against it imho. Next argument
would be using different libraries in one file and wanting one of them
to be strict the other not.

I get the idea following something like "use strict;" approaches of
Perl/Javascript,
however AFAIK they only affect the file itself, not calls from the file to
another one.

>
>
> Pavel Kouril
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to