Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101669 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71322 invoked from network); 25 Jan 2018 17:18:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jan 2018 17:18:20 -0000 Authentication-Results: pb1.pair.com header.from=andreas@dqxtech.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=andreas@dqxtech.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.41 cause and error) X-PHP-List-Original-Sender: andreas@dqxtech.net X-Host-Fingerprint: 209.85.215.41 mail-lf0-f41.google.com Received: from [209.85.215.41] ([209.85.215.41:37937] helo=mail-lf0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/E1-61119-8511A6A5 for ; Thu, 25 Jan 2018 12:18:16 -0500 Received: by mail-lf0-f41.google.com with SMTP id g72so10752739lfg.5 for ; Thu, 25 Jan 2018 09:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dqxtech-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1B+1q2z6LEzbXDb7yfWnX4Z9I0bIQzWw4szZ2rpCfNQ=; b=JNq8VEPmG1vpaVBhwBplcIL2aEmyVLJCYc1nWcZN73XUHMa+wnkc4jF0LUzQ+ZkQsw VeksOjtRKfgiQhbJwaq+qkG4K5Nvqis8UxJr8ywEWQ8oUxjdICRJb4cz7ximcazgzZbv CImPE0e+PGmlXdz95aXLyxA7KHLrviEf94ePtHAS6HT0o8y7SIFJBSKpril6QapN9r9v ozojoeDnp6Hdi8qqN2Q81yNyIaj7epMKBd8cKZURYlJ8qqRoy2xxX0tJrd4b7uJDTS8T YzCmHHfk6MMPebYsAmDiBfj7RXwGcgZAo6IB0Bcvj45Nl85nKKcrhxbW1i1OwkGVUIKC NOzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1B+1q2z6LEzbXDb7yfWnX4Z9I0bIQzWw4szZ2rpCfNQ=; b=WTwhmmCwxukxQ4QajOkdojdRC9rrg9jwBrMO7LO8vpR8MTMK9t/amOh/LEYxOBloxf 74a875s0FAX3mgkt6jbh7h/cTktWGqPu9cF91NKgaZ1a/9fKrKepUAnutAIYwWw3hd5n XPYZDUGCjGUHohnp0mRSo2SuLATbmTkofZnvv6Qv4vo3psCUGX6z9o53gYbmjrxDe64+ lDlHJz2Y0XGMA4YQGbXWCe+EDYNplTUT0tq0BMVBFpJ8VxaisQpr5jODeAzniztJ07ZQ xtt3BLVLav8qzrjFtQJnNc8LTA4jBlmNYXWeOhcKUGI5R/LMImy6b++jYjUygkT4ETx1 hWNw== X-Gm-Message-State: AKwxytfr8HLHhpXwIyJ2lOdzCZgJpHy7R1s1hzWlS3Igh51peMUHRT9t Iuzwkty+5F4ggGFYRwBKReYaHR1L X-Google-Smtp-Source: AH8x227atuUYM/QIMbA4ik+mtwM+t2KJxXuGE0uaUj0UxGyPP1OmDpmQhlbbsYvN1NKJ8zJu6FK2gg== X-Received: by 10.46.77.87 with SMTP id a84mr6051719ljb.100.1516900692180; Thu, 25 Jan 2018 09:18:12 -0800 (PST) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com. [209.85.215.48]) by smtp.googlemail.com with ESMTPSA id z205sm1058216lff.33.2018.01.25.09.18.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 09:18:11 -0800 (PST) Received: by mail-lf0-f48.google.com with SMTP id 63so4436667lfv.4 for ; Thu, 25 Jan 2018 09:18:10 -0800 (PST) X-Received: by 10.25.67.67 with SMTP id m3mr6493309lfj.105.1516900689861; Thu, 25 Jan 2018 09:18:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.71 with HTTP; Thu, 25 Jan 2018 09:17:49 -0800 (PST) In-Reply-To: <8ce8f4d4-8240-4d0b-dde7-5ba6e0d78ff4@gmail.com> References: <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com> <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com> <8ce8f4d4-8240-4d0b-dde7-5ba6e0d78ff4@gmail.com> Date: Thu, 25 Jan 2018 18:17:49 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Stanislav Malyshev Cc: Michael Morris , PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax From: andreas@dqxtech.net (Andreas Hennings) I will not On 22 January 2018 at 22:11, Stanislav Malyshev wrote: > 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. I do not doubt that it would be a lot of work, possibly so much that it becomes unrealistic. There are languages which have a number of strict types and then a "variant" type. https://en.wikipedia.org/wiki/Variant_type https://msdn.microsoft.com/en-us/vba/language-reference-vba/articles/variant-data-type In PHP, to allow a mix of strict statically typed variables and dynamically typed variables, we could adopt such a model, where all dynamically typed variables would have the type "variant". The strict types would become the basic model, and the variant type would be a special case within that model. This does not make this any easier to implement, but it seems more promising than seeing this as two parallel systems which have to be maintained separately. > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >