Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66988
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.212.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFFuhJqzDi7EXw3rDhcOTDqM-_EDEk0AJPGdQHKKvampETh4Zg@mail.gmail.com>
References: <CADqTB_jjb9v=jZ_RkRucVvY6Vv1EOrqhJEqbcirhVV3ZgpG0vg@mail.gmail.com>
	<op.wu0woxzmc9evq2@nikita2206-n56vj>
	<CADqTB_i20MPuF=1rg0S+m8dPBwpmEWu_AwhaS1=c1KUQkvOHuw@mail.gmail.com>
	<CAEPJdum7pnhg1TwRv4FVp=Z41jOcr0UmsLw_L=qWHKN5vF_h-g@mail.gmail.com>
	<CADqTB_jra=fCh0UkZ5iCVgs5kJSqqQtytxg6Wucs6kh11_+b3w@mail.gmail.com>
	<A225D9BBF238624AB8DB155CC6466CCA0B57561F@VEXCHANGE10.zoo.lan>
	<CADqTB_hYyezJ_mCNr=_PNRDX0=O=7e-STUF64qfvz2bqFr2imQ@mail.gmail.com>
	<CADqTB_jyH1p1mBycJ99qi7Jgb6hpbu-F+t6vOpWuPH+wpQ-PDw@mail.gmail.com>
	<CAFFuhJqzDi7EXw3rDhcOTDqM-_EDEk0AJPGdQHKKvampETh4Zg@mail.gmail.com>
Date: Fri, 5 Apr 2013 10:35:03 -0400
Message-ID: <CADqTB_iY8G9PPZsAAG4ZODeSScFqJLEY=WRdpaZ6KZvYZmgiPg@mail.gmail.com>
To: ALeX <lists.php@tx0.eu>
Cc: Richard Bradley <Richard.Bradley@softwire.com>, Benjamin Eberlei <kontakt@beberlei.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b675b2621e11404d99dfe4d
Subject: Re: [lists.php] Re: [PHP-DEV] a couple of thoughts on the DateTime
 type debate
From: rasmus@mindplay.dk (Rasmus Schultz)

--047d7b675b2621e11404d99dfe4d
Content-Type: text/plain; charset=ISO-8859-1

> On the other hand, I would just use an array. (without any "magic"
> like methods on structs, yes you would have to write plain functions
> and not use OOP like methods).

Yeah, that's what people are doing right now - the problem with that, is
you have the class-name referenced on every call, e.g.:

abstract class Color
{
    public static function create($r, $g, $b)
    {
        return array('r'=>$r, 'g'=>$g, 'b'=>$b);
    }

    public static function mix(array $base, array $mix, $amount)
    {
        return array(
            'r' => $base['r'] * $amount + $mix['r'] * (1 - $amount),
            'g' => $base['g'] * $amount + $mix['g'] * (1 - $amount),
            'b' => $base['b'] * $amount + $mix['b'] * (1 - $amount),
        );
    }
}

$red = Color::create(1, 0, 0);

$green = Color::create(0, 1, 0);

$mix = Color::mix($red, $green, 0.5);

The problem with this approach, is you have a static reference to the
Color-class for every method-call.

With structs you can accomplish the same thing without littering your code
with static class-references.

With pseudo-types implemented as arrays in this way, you also can't hope to
have IDE support or static analysis, e.g. for properties...



On Fri, Apr 5, 2013 at 10:00 AM, ALeX <lists.php@tx0.eu> wrote:

> > I imagine the implementation could be something along the lines of
> checking
> > for the '__struct' key when somebody attempts to use method-call syntax
> on
> > an array, invoking the appropriate method with $this referencing the
> array
> > you were using.
> >
> > The rest of the time, a struct, for all intents and purposes, is just an
> > array.
>
> One thing I do not like about the "struct as array" is that you can
> create "invalid" structs, in classes you could have all variables
> private and check during set, but not here: "$array = ['r'=>1,
> 'b'=>'yes', '__struct'=>'Color'];".
>
> Hmm... just an thought: why not make struct almost like a class except
> that $this is a copy (on write) - modifying and returning $this would
> be a new instance of that struct/class. That would give you
> public/private/static/variables/methods/interfaces/..., but it would
> lead to another type.
> Or use a keyword to the class, e.g. "autoclone class Color {...", and
> not the new name struct -> it would be clear that struct/classes use
> the same namespace.
> You maybe even could do "autoclone class DateTimeImmutable extends
> DateTime {}" to create the immutable version. (I see no reason why an
> "normal" class could not be extended into autoclone, but useless in
> most cases though)
>
> On the other hand, I would just use an array. (without any "magic"
> like methods on structs, yes you would have to write plain functions
> and not use OOP like methods).
>

--047d7b675b2621e11404d99dfe4d--