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 > >