> > For the record, I'm still very uncomfortable with this new language > > syntax - even if it's a no-op right now. > > I know you are; but from what I understood, there were no more comments > to the latest mail (with patch and RFC) that I've made towards this.
I know, I took some time off after reaching agreement we're not going to add strict checks - but I said from the get go that it's questionable whether we should add this syntax. > > I'm not comfortable about not having the proper strict checks that we had. Except we never had them. It's like me committing support for inline assembly syntax or whatever other weird idea I might come up with, and then saying I don't feel comfortable about removing it. With such fundamental changes there should be a very broad support, with the status-quo being the default in case no such broad support is reached. The status quo is not the latest state of trunk, but rather, the state of previous versions. > It seems we're both having to live with something uncomfortable. We should attribute as much importance to adding features as removing features; Can I jump ahead and remove this support in trunk, and get back to you with 'one of us will have to feel uncomfortable' feedback? I don't think it works that way. The status quo, and the way PHP existed since forever, is no strict type checking or syntax for supporting it. IMHO before there's a clear informed decision to change that, it should stay that way. With the kind of phpdoc updates we're likely to add, you should be able to implement your extension-level support on top of this meta data. The chances of that becoming mainstream and creating two flavors of PHP are much slimmer which make it a much better fit than a big chunk of language level syntax that's a no-op by default. > > Are we effectively going to create the original type checking > > implementation, but in a separate component people would have to > > install - thereby creating two very different flavors of PHP? > > It's clearly a debugging aid for me. So this should be in a debugging > extension. I doubt any sort of shared hoster would install it, but it > *does* give people the power to do this for their own controlled set-up. > Also, if the extension is suddenly not there, the app will still work so I am > not > buying your "two flavours" argument. It may or may not work depending on how you write your code. If you rely on that feature your app may very well stop working properly (e.g. it may expose it to security issues). It's very much creating two flavors. > > Regarding the alpha release, I think there are two key issues here: > > > > 1. Does this alpha mean anything at all. Some, myself included, > > don't feel comfortable about the state of certain things in the > > current codebase (example given above). Are we all in sync that even > > if a certain feature makes it into the alpha, it doesn't mean that it > > won't be removed or be severely modified in an upcoming beta/GA? > > Is it clear it has no implications on when the final release would be? > > That is, at least, the way I perceive alpha releases. In which case > > it's not exactly clear to me what the benefits of releasing an Alpha > > in this day and age for PHP - where we have snapshots every few hours. > > We need to have a very clear understanding of what this does or > > doesn't mean, and make sure we communicate it properly to the users. > > To me this alpha would be a "this is what we're mostly likely going to have > thing". I wouldn't like to see new major features, engine rework being done; > but I also think we shouldn't try to remove stuff from it unless really > necessary. If that's the case, count me in those who oppose the release of the current codebase as an alpha. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
