Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84821
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
MIME-Version: 1.0
Sender: kobrasrealm@gmail.com
In-Reply-To: <CAB6YZuy7CbdPFNjLXBP83_Cj3qbTchgyw2OAr0RykfuHGJBP_w@mail.gmail.com>
References: <CAPKwhws-o7Z-k9zwDW9qPEMw=vKaNP9YM1yXtWM+wR5qjwBzGQ@mail.gmail.com>
	<CAB6YZuzEy4064OUEc4bLqqUXFGvNYsrcDkKf6OfB-G54s0KeZw@mail.gmail.com>
	<CAPwsocH5ML44it43J=qm=FZPnqun0jSjmWip67tQVUWTuihdVw@mail.gmail.com>
	<CAB6YZuy7CbdPFNjLXBP83_Cj3qbTchgyw2OAr0RykfuHGJBP_w@mail.gmail.com>
Date: Sun, 15 Mar 2015 08:25:07 -0400
Message-ID: <CAPKwhwsTPp9UC3H-Q8gr9LXy9jJe_+W55dwhC7W=FsuK7GVVHw@mail.gmail.com>
To: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Cc: "inter >> PHP internals" <internals@lists.php.net>, Leigh <leight@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b66f473f77e43051152d237
Subject: Re: [PHP-DEV] Re: A plea for unity on scalar types
From: scott@arciszewski.me (Scott Arciszewski)

--047d7b66f473f77e43051152d237
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mar 15, 2015 6:23 AM, "Pavel Kou=C5=99il" <pajousek@gmail.com> wrote:
>
> On Sun, Mar 15, 2015 at 9:56 AM, Leigh <leight@gmail.com> wrote:
> >
> > On 15 March 2015 at 08:42, Pavel Kou=C5=99il <pajousek@gmail.com> wrote=
:
> >>
> >> Sure, per-file is better than ini setting, but better doesn't mean
> >> good (because it is still a pretty bad approach). The ini setting at
> >> least has the option to be turned off in code once everyone realizes
> >> it was a bad idea (register_globals via htaccess, for instance), but
> >> PHP would be stuck with the declare for a long time - this is not an
> >> easily revertable change, once PHP ships with it.
> >
> >
> > The declaration is turned on with code. This is no different to
changing an
> > ini setting with code, except that it can't be configured globally in
> > advance.
> >
> > Existing code is unaffected. I'm not sure where your "not easily
revertible"
> > argument is grounded. It's incredibly easy to add/remove declarations
at the
> > top of a file.
> >
>
> So - are you saying that it would be easy to remove this feature from
> the language once people would realize it's register_globals (and any
> other settings that change how code behaves) all over again?
>
> >> The two groups (people who want strong typing and weak typing) will
> >> not work *together* though. And it will be a nightmare for everyone
> >> working on multiple projects from mulitple clients or so.
> >
> >
> > Pure FUD. Sorry but there is no evidence to back this up.
> >
>
> Well, how can there be evidence when the feature isn't released yet?
> But if you read through the discussions about the Dual Mode RFCs,
> you'll see that I'm definitely not the only userland developer with
> this opinion.
>
> Also, I can't think of any other language (apart from JS) which has
> some settings that change how the code behaves. I'd guess most
> languages don't do this for good reasons, but who knows, can't say for
> sure.
>
> >
> >>
> >> The best approach to have some reasonable
> >> type rules is to progressively "strenghten" the rules (as Zeev's RFC
> >> tried to do so, but he probably did two steps in one RFC and that's
> >> what people dislike about it?).
> >
> >
> > You think the best approach is to progressively and continually break
> > working code between versions? How is this approach acceptable ever?
> >
>
> This of course doesn't mean breaking existing code in every version. I
> doubt there would be more than 2 or 3 changes to the conversion rules
> in foreseeable future with this approach. But I do agree that this
> isn't ideal way to do things, but I'd say it's the right one.
>
> >>
> >> I think that PHP's type system would
> >> get to some "equilibrium" by this - people wanting stronger typing
> >> would tried to introduce it and people wanting weaker one would
> >> balance it and eventually there could be a point on which both sides
> >> could agree on.
> >
> >
> > No, they would never reach agreement.
> >
>
> "Pure FUD. Sorry but there is no evidence to back this up. "
>
> (Sorry, I had to - I really do believe that some consensus would be
> reached after a while, though.)
>
> >> I sincerely hope the Dual Mode RFC doesn't pass. I can't imagine the
> >> RFC being good for the userland developers in the long run.
> >
> >
> > Apologies again, but I think you don't really understand what is being
> > proposed in this RFC. Proponents of strict typing get exactly what they
> > want, they can develop their library or entire project in strict mode i=
f
> > they want, and if someone wants to use this project or library, but
> > themselves want to use weak mode, _nothing breaks_.
> >
>
> Why does everyone reply to the disagreeing opinions with "I think you
> don't understand the RFC"? I've seen this happen multiple times in the
> discussions with Dual Mode RFC, even when the person understood the
> RFC. I am 100% aware that the caller decides the rules, not the callee
> and that there's supposed to be interoperability - and yet, I still
> strongly disagree with it, mostly because it makes managing multiple
> projects (each working with different mode) harder.
>
> I would generally love to have type hints in PHP 7.0 (with any
> reasonable ruleset, be it strongly typed, weakly typed or some middle
> ground, I don't care as long as it's only *one* ruleset), but I would
> rather have none than the Dual Mode one.
>
> Regards
> Pavel Kouril

Interoperability issues? With an optional language feature? Riiiight

--047d7b66f473f77e43051152d237--