Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66993
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.43 as permitted sender)
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> <CADqTB_hChZ2u6vabwkwwsFckr=S1Cnz1V__Cb5ARuPHv0jt=bw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CADqTB_hChZ2u6vabwkwwsFckr=S1Cnz1V__Cb5ARuPHv0jt=bw@mail.gmail.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <375A8E79-D6F9-4526-9837-39ADC7B8176A@gmail.com>
Cc: ALeX <lists.php@tx0.eu>,
 Richard Bradley <Richard.Bradley@softwire.com>,
 Benjamin Eberlei <kontakt@beberlei.de>,
 PHP internals <internals@lists.php.net>
Date: Sat, 6 Apr 2013 14:15:36 +1100
To: Rasmus Schultz <rasmus@mindplay.dk>
Subject: Re: [PHP-DEV] Re: [lists.php] Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
From: davidkmuir@gmail.com (David Muir)

On 06/04/2013, at 1:40 AM, Rasmus Schultz <rasmus@mindplay.dk> wrote:

>> 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.
> 
> As said, I don't know the innards of the codebase, but that sounds more
> "hacky" to me somehow? - other value-types in PHP such as array already
> have the semantics we're looking for in value-types, whereas
> classes/objects do not. I don't know how it's implemented though.
> 
>> 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.
> 
> Other languages use the term "struct" - I don't think there's any reason to
> invent new terminology for something that is already well-known and has
> established terminology?
> 
> 
> 
> 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).
>> 

Isn't this basically the way classes were originally implemented in php4?

Cheers,
David