Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101659
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.41 as permitted sender)
To: Michael Morris <tendoaki@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAEUnE0d+rHG-Rvjt7QAN6x6L+BP5Yb_cz8sGuOFDOkx-kCehkA@mail.gmail.com>
 <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com>
 <CAH0Uv3H_DEPZ5HmaKGe08_DMrzndBz7ofJTUgeb4f66zeaj1EA@mail.gmail.com>
 <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com>
 <bb4579ba-2e09-4199-a871-be4428a1ee2d@lsces.co.uk>
 <ee3d2ffc-a72c-78f3-281b-dd029c706105@gmail.com>
 <CAEUnE0eShfm4kZck=2gBef6cgU6DdrKggtotUK+Jyk6uPYOYFg@mail.gmail.com>
 <CACXBjugZrXXORVsaFhJzRO_WEiUXnVEHBBuHZysPUGRN6Ls7nw@mail.gmail.com>
 <CAEUnE0ce2HRfsKOy_=NSnrENUnGpB4m-C=cMQFV93MgbaMguOQ@mail.gmail.com>
 <CAHWSxWQHtPZdnfA5P4da4ETpQzFTGB_sKDT73vtM15tbNjYi_A@mail.gmail.com>
 <CACXBjuibgJfRCvp6rpuqZj8BoF9Cdwhmu4oxxqw908NZy4h49w@mail.gmail.com>
 <CAEUnE0cH1ZnCwpYW4njdgM2B6uJsrzQ3AbRtcy2H_-85xX9urw@mail.gmail.com>
Message-ID: <8ce8f4d4-8240-4d0b-dde7-5ba6e0d78ff4@gmail.com>
Date: Mon, 22 Jan 2018 13:11:59 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:58.0)
 Gecko/20100101 Thunderbird/58.0
MIME-Version: 1.0
In-Reply-To: <CAEUnE0cH1ZnCwpYW4njdgM2B6uJsrzQ3AbRtcy2H_-85xX9urw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I want to see strict typing as an option, not a requirement.

You seem to be under impression that this somehow makes things easier.
It does not. To explain: let's say you design a strictly typed language,
like Java. The compiler knows which variable is of which type at every
point, and if it's not clear for some reason, it errors out. You can
build a compiler on top of those assumptions.
Now let's say you design a loosely typed language, like Javascript. The
compiler knows variables have no types, only values have it, and builds
on top of that (as in, it doesn't need to implement type tracking for
variables).
Now, you come in and say - let's make the compiler have *both*
assumptions - that sometimes it's strict and sometimes it's not.
Sometimes you need to track variable types and sometimes you don't.
Sometimes you have type information and can rely on it, and sometimes
you don't and have to type-juggle.
Do you really think this just made things *easier*? To implement both
Java and Javascript inside the same compiler, with radically different
types of assumption? If you have desire to answer "yes", then a) please
believe me it is not true b) please try to implement a couple of
compilers and see how easy it is.

Having two options is not even twice as harder as having one. It's much
more. So "optional" part adds all work that needs to be done to support
strict typing in PHP, and on top of that, you also have to add work that
needs to be done to support cases where half of the code is typed and
the other half is not. And this is not only code writing work - this is
conceptual design work, testing work, documenting work, etc.

Without even going to the merits of the proposal itself, it certainly
looks to me like you are seriously underestimating what we're talking
about, complexity-wise. I am not saying it's not possible at all - a lot
of things are possible. It's just "it's merely an option" is exactly the
wrong position to take.

> Create a symbol table that holds the strict variables and the types they
> are locked into.  The strict keyword pushes them onto that table, the var
> keyword pulls them off. When an operation that cares about type occurs
> check that table - if the var appears there than authenticate it.

And now every function and code piece that works with symbol tables
needs to be modified to account for the fact that there are two of them.
Every lookup is now two lookups, and no idea how $$var would even work
at all.

-- 
Stas Malyshev
smalyshev@gmail.com