src/Type/PostalAddress.php
public function setAddressLines($var)
    {
        $arr = GPBUtil::checkRepeatedField($var, \Google\Protobuf\Internal\GPBType::STRING);
        $this->address_lines = $arr;

        return $this;
    }
public function setAddressLines($var)
    {
        $arr = GPBUtil::checkRepeatedField($var, \Google\Protobuf\Internal\GPBType::STRING);
        $this->address_lines = $arr;

        return $this;
    }
Unstructured address lines describing the lower levels of an address.
Because values in address_lines do not have type information and may
sometimes contain multiple values in a single field (e.g.
"Austin, TX"), it is important that the line order is clear. The order of
address lines should be "envelope order" for the country/region of the
address. In places where this can vary (e.g. Japan), address_language is
used to make it explicit (e.g. "ja" for large-to-small ordering and
"ja-Latn" or "en" for small-to-large). This way, the most specific line of
an address can be selected based on the language.
The minimum permitted structural representation of an address consists
of a region_code with all remaining information placed in the
address_lines. It would be possible to format such an address very
approximately without geocoding, but no semantic reasoning could be
made about any of the address components until it was at least
partially resolved.
Creating an address only containing a region_code and address_lines, and
then geocoding is the recommended way to handle completely unstructured
addresses (as opposed to guessing which parts of the address should be
localities or administrative areas).

Generated from protobuf field <code>repeated string address_lines = 9;</code>
@param string[]|\Google\Protobuf\Internal\RepeatedField $var
@return $this