Why is that 1 too many, exactly?
Like I said, I would be ok with just having it behave as strong without the
distinction, though that might be a harder sell for some people. On the
other hand, having it just behave as weak without the option to blow it up
would also be a harder sell for some people, myself included. That's why,
from a pragmatic standpoint at least, having both levels makes the most
sense without really having any glaring drawbacks, aside from the fact that
some people might see it as superfluous.
--Kris
On Tue, Feb 28, 2012 at 3:41 PM, Michael Morris <dmgx.mich...@gmail.com>wrote:
> It's better to have it blow up in all cases then. Avoiding the break is
> trivial
>
> int $a = (int) 3;
>
> And this example illustrates cleanly the difference between this
> proposal and casting by itself. Introducing this creates a new level
> of typing, for a total of two. Your proposal creates 3, which is 1
> too many.
>
> On Tue, Feb 28, 2012 at 6:36 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > But again, that same argument could be used to eliminate the require()
> > function, which is something that I and many other developers use quite
> > frequently.
> >
> > There are cases where I would want my script to blow-up and stop
> executing,
> > such as if an included script could not be loaded (hence "require"); or,
> > given the right circumstances, when my script is relying on a variable
> that,
> > as a result of some unanticipated behavior, receives an incompatible
> value
> > for its type.
> >
> > After all, just look at how many PHP scripts out there already do this
> > manually; i.e. terminating the script (with die() or some other means) if
> > the variable doesn't pass a bulky and convoluted sanity check. All that
> > code could be eliminated by simply having the strong type, since that
> would
> > now be done for you at the lower level. There are other cases where this
> > sort of conflict would be undesirable but the coder might still want the
> > script to proceed anyway, hence the need for the weak type. There are
> > valid, real-world use cases for both.
> >
> > --Kris
> >
> >
> >
> > On Tue, Feb 28, 2012 at 3:30 PM, Michael Morris <dmgx.mich...@gmail.com>
> > wrote:
> >>
> >> I don't see a point in two error levels. Either the coder cares or
> >> they don't. Further, there are mechanisms already in place.
> >>
> >> int $a = 'House'; // Warning.
> >> @ int $a = 'House'; // No warning because the suppression operator was
> >> used.
> >>
> >> If you need something more than a warning you can code it. Let's use a
> >> real world example
> >>
> >> @int $id = $_POST['id'];
> >>
> >> if ($id != $_POST['id']) {
> >> throw MyValidationException();
> >> }
> >>
> >> In the language as it stands we have
> >>
> >> $id = (int) $_POST['id'];
> >>
> >> if ($id != $_POST['id']) {
> >> throw MyValidationException();
> >> }
> >>
> >> So we have the means to make things secure. The one thing, the only
> >> thing this is really going to give, is to prevent $a from changing
> >> type.
> >>
> >> To be honest, this isn't useful with solo programmers. Where it will
> >> be useful is with teams and API enforcement.
> >>
> >> This whole strong/weak keywording is a Very Bad Idea(TM) IMHO. Weak
> >> can already be done with casting.
> >>
> >> On Tue, Feb 28, 2012 at 6:17 PM, Kris Craig <kris.cr...@gmail.com>
> wrote:
> >> > +1 on that.
> >> >
> >> > However, I believe the coder should also have the option of
> determining
> >> > whether this should be recoverable or not, just like they have a
> choice
> >> > with
> >> > regard to using "include" or "require" (one fails gracefully, the
> other
> >> > terminates execution).
> >> >
> >> > That's where I think strong/weak could be very useful. Here's how I
> >> > would
> >> > do it:
> >> >
> >> > weak int $a = "House"; // Throws E_WARNING
> >> > strong int $a = "House"; // Throws E_RECOVERABLE_ERROR
> >> >
> >> >
> >> > In both cases, the error can be caught, which would mirror the
> >> > flexibility
> >> > in languages like C#. However, if the weak one isn't caught, the
> >> > warning is
> >> > thrown but the script proceeds as normal. If the strong one isn't
> >> > caught,
> >> > the script will terminate as if it was an E_ERROR.
> >> >
> >> > I think this would be the most sensible approach in terms of balancing
> >> > simplicity and flexibility.
> >> >
> >> > --Kris
> >> >
> >> >
> >> >
> >> > On Tue, Feb 28, 2012 at 3:08 PM, Michael Morris <
> dmgx.mich...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Agreed. If conversion can occur without data loss (that is, if the
> >> >> value being assigned is == the value that actually IS assigned) then
> >> >> no error should occur.
> >> >>
> >> >> So
> >> >>
> >> >> int $a = "1"; // no error. 1 == "1" so who cares?
> >> >> int $a = 'House'; // error 0 != 'House', so this is a problem.
> >> >>
> >> >> Again, errors should only raise if the final value != source value.
> >> >>
> >> >> On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer
> >> >> <vch...@developersdesk.com>
> >> >> wrote:
> >> >> > On 2/28/2012 2:58 PM, Kris Craig wrote:
> >> >> >
> >> >> >> strong int $a = "1"; // Converts to 1. May or may not throw an
> >> >> >> error
> >> >> >> (I'm
> >> >> >> still on the fence).
> >> >> >
> >> >> >
> >> >> > It this is an error, it is no longer PHP.
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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
> >> >>
> >> >
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
