I will not On 22 January 2018 at 22:11, Stanislav Malyshev <smalys...@gmail.com> 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 > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
