Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109105
MIME-Version: 1.0
References: <CAJmjfvW8b=jYTjLfW9N9FT_eQVS7RBe768NZXv-g4V2RM3OgtA@mail.gmail.com>
 <CALKiJKqEbBY3vSFZ5uJoYQ-um0yiR5USgFSo6A6L5Z4Y7SOA2w@mail.gmail.com> <CAJmjfvXYpaGx=UfaKN-SA6gYx_Ya22E99AUydBuD=OHWTfcC4A@mail.gmail.com>
In-Reply-To: <CAJmjfvXYpaGx=UfaKN-SA6gYx_Ya22E99AUydBuD=OHWTfcC4A@mail.gmail.com>
Date: Tue, 17 Mar 2020 14:30:45 +0000
Message-ID: <CALKiJKqaTonoSEDQdePXB-N+LRQw+34v6i64Pe7vi9+ofDdR5A@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000acb9ac05a10dc88c"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000acb9ac05a10dc88c
Content-Type: text/plain; charset="UTF-8"

On Tue, 17 Mar 2020 at 01:47, Jakob Givoni <jakob@givoni.dk> wrote:

> Remember that the RFC explicitly says it's not an object initializer,
> nor does it solve "named parameters" which you mention.
>


I wasn't expecting COPA to "solve" named parameters, just thinking that if
we already had named parameters, we might not bother with COPA.

That said, your "argument bag" example looks very much like it's trying to
solve named parameters to me.




> An Options class add almost no extra boilerplate since you simply move
> the properties from
> the main class to the Options class.
> Notice that in contrary to your example, I simply copy the Options
> object whole into the main class.
>


Hm, I see, that does reduce the boilerplate somewhat, although it's still
split across two classes, and probably therefore two files, which is not
great.

You're missing some code in your example, though, because you've documented
one of the options as optional, implying the others should be mandatory; in
which case you need something like this in the constructor:

         if ( ! isset($options->mane) || ! isset($options->hum) ) {
             throw new Exception('Bad options');
         }

Which would soon get longer with more complex options. Maybe it would be
refactored out into $options->isValid() or something, but it would have to
go somewhere, or you'll just get "uninitialized property" errors in random
parts of your application.

You'd also want to copy the property onto the real object if it was
initialising state rather than retaining a constant value; it would be a
bit weird to write $this->options->counter++ instead of $this->counter++




>
> > COPA can only validate individual
> > parameters, not the whole object; so it's hard to complain if the user
> > forgets a mandatory field
> Correct, the goals for COPA are quite clear in the "Motivation"
> section and that kind of validation
> is not one of them
> Luckily you can still do things the way you prefer without COPA if it
> doesn't suit you :-)
>



It's not so much about preferring different styles, it's about what
circumstances this will be useful. It seems pretty rare that an object
would have no mandatory properties, so saying "if you have a mandatory
property, COPA is not for you" is ruling out a lot of uses.

It might be interesting to have the syntax run before the constructor
rather than after, or trigger some other magic method which could do
tidying and validation, so it could apply to more circumstances.


Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000acb9ac05a10dc88c--