> 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....@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).
>
