Danack

ಠ_ಠ

I can't comment as to multi-region, but we saw issues last night at around 6pm UTC, which look similar to the ongoing issues we are seeing.

We've been having 'fun' with ongoing issues for a site since 6pm UTC yesterday, which got dramatically worse this morning...and having been recurring during the day.

Having multiple hour outages makes me really want to go back to hiring a couple of physical servers in a rack somewhere.

"it offers significant improvements." - citation needed.

It was better for a period after the fork, but the only guy working on it hasn't maintained it that well...there's a significant number of bugs in GraphicsMagick that have been there for years.

Yeah, it's terrible.

You can't give read only Oauth access to private repos....it has to be read/write. Which means if you want to use online CI tools with those private repos....you've got to hope they don't either turn malicious, or they get hacked and have their keys copied.

From the fine article:

  1. Customer places an order.
  2. SYN: Can I charge $30?
  3. SYN/ACK: Yes.
  4. ACK + SYN: Do it.
  5. SYN/ACK: I am gonna do it.
  6. ACK: I see that you're gonna do it.
  

"If that was their model, then at no point does a communication failure cause a charge to be in an ambiguous state. If I never get the message in #5, the customer is not charged. If I get the message in #5 and my response in #6 is not received, the customer is not charged."

Er.....that doesn't appear to solve anything, instead it just pushes the error state down a level; there's still an ambiguous state where #6 is sent and not received.

The client thinks the charge is going to take place, and so thinks the client will be charged, but the bank never gets #6 and so never makes the charge, aka distributed atomic operations are hard.

The slowness appears to be caused by continual directory scanning. For me at least, turning off the "Refresh when files change" option, and so having to do "view, refresh" or Command-R, made SourceTree be zippy again.

And as I'm usually on a laptop, having less continued CPU usage is a good tradeoff against having to press refresh when I'm going to do something in SourceTree.

Also people are probably used to holding things that don't matter too much if dropped. If someone dropped a 10/20/30 kg bag of rice and it landed on my toes, the bag would just fold around the foot and it wouldn't be a problem.

If someone dropped a 30kg piece of steel and it landed corner first, there's a decent chance of it just going straight through the foot.

> function add( ... ): float {}

Which if you read it out, it sounds entirely natural "This is a function called foo, which takes some params, and returns a float". Most of the other variants don't read as naturally.

> Since that's how it's done in other languages and people would feel at home with it.

PHP doesn't need to copy the mistakes of other languages. It's got plenty of its own mistakes.

> Is there any other benefit?

Strict types make it easier to reason about code, that the tl;dr version.

> To me it seems that Ze'ev's proposal would be even better for you - > it does the equivalent of the validation and conversion automatically > including with an error if it doesn't validate.

Rather than having int 'types' which we can reason about, it has int 'values' which are harder to reason about. Types can be reasoned about just by looking at the code. Values can only be reasoned about when running code. A contrived example:

    function foo(int $bar){...}

    foo(36/$value);

In strict mode, this would be reported as an error by code analysis.

For the coercive scalar type proposal, this code works - except when it doesn't. This code works when $value = 1, 2, 3, 4 and breaks when $value = 5.

This is the fundamental difference; whether conversions between types have to be explicitly done by code, and so any implicit or incorrect conversion can be detected by static code analysis tools, or whether the conversions are done at run time, and so cannot be analyzed fully.

This means most of these errors will be discovered by users on the production servers. Strict mode allows you to eliminate these types of errors.

Yes, this means I need to add a bit of code to do the explicit conversion, but I just don't convert between values that much. Once a value is loaded from a users request, config file or wherever, it is converted once into the type it needs to be. After that, any further change in type is far more likely to be me making a mistake, rather than an actual need to change the type.

> Any idea why it was rejected so badly? Is it because the coercion rules are different from the rest of PHP?

At least in part it was because the RFC was seen as a way to block strict types; about half of the RFC text is shitting on people desires for strict types, which did not make people who want strict types be very receptive. If it had been brought up 6 months ago, there is a good chance it would have passed, or at least would have been closer.

Some parts of the proposal were good - other parts were nuts that were pretty obvious the result of the RFC only being created once the dual mode RFC was announced and about to be put to the vote, with a very high chance of passing.

* Good - "7 dogs" not longer being converted to "7" if someone tries to use it as an int.

* Bad - Different mode for internal function vs userland functions e.g. "Unlike user-land scalar type hints, internal functions will accept nulls as valid scalars." and other small differences. This is even more nuts than you might realise as it means if you extend an internal class, and overload some of the methods on the class, those methods will behave differently to the non-overloaded methods.

* Bad - Subtle and hard to fix BC breaks in conversion which are probably not right anyway. e.g. false -> int # No more conversion from bool true -> string # No more conversion from bool

It is a shame that the discussion became so contentious. It would have been good if the conversion rules could have been tidied up, but all the time and energy had been used up the not particularly productive discussion.

> Can you explain why?

Hopefully.

> How does putting (int) before the arguments to function help anything?

It wouldn't. Anyone who is casting from an unknown type to an int by using just `(int)` is doing something wrong in my opinion.

Even in web-based applications there are at least two layers of code: i) One where the type of the values are unknown and they are represented as strings. ii) One where the types of the values are known.

At the boundary between these two layers you should have code that inspects the strings that represent the input values, check that they are acceptable, and convert them to the desired type. If the input values cannot be converted to the desired type, the code needs to give an error that is both specific to the type of error so that a computer can understand it, as well as provide a human understandable explanation of why the conversion was not allowed.

The reason why I want strong types is that I never, ever want to blindly cast from one type to another. The decision about how to convert from one type to another, should always be made at a boundary between areas of the application where types are known, and the areas where the types are unknown. I always want to be forced to make that decision in the right place, using code that gives useful errors and messages, rather than having the value coerced into the desired type.

tl;dr I won't use (int) to cast, I will use something like the code below.

cheers Dan

    function validateOrderAmount($value) : int {
        $count = preg_match("/[^0-9]*/", $value);
        
        if ($count) {
            throw new InvalidOrderAmount("Order amount must contain only digits.");
        }

        $value = intval($value);

        if ($value < 1) {
            throw new InvalidOrderAmount("Order amount must be one or more.");
        }
        
        if ($value >= MAX_ORDER_AMOUNT) {
            throw new InvalidOrderAmount("You can only order ".MAX_ORDER_AMOUNT." at a time.");
        }
        
        return $value;
    }

    function processOrderRequest() {
        $orderAmount = validateOrderAmount($_REQUEST['orderAmount']);
    
        //Yay, our IDE/static code analyzer can tell that $amount is an int if the code reached here.
        placeOrder($orderAmount);
    }

This is actually quite revealing. Some people think that PHP is just used for the same small web pages it was used for 15 years ago.

Other people would like to use PHP more as a general computing language.

Having optional types takes nothing away from using PHP for simple web pages, but does make it easier to right analyzably correct programs.

The fact that the founder of a language doesn't want to see it grow is quite depressing.