> On 16 Apr 2016, at 11:19 , Lester Caine wrote:
>
> On 16/04/16 06:56, André Rømcke wrote:
This actually summarises many of the problems all of these 'extras' are
creating for very little gain.
'Seconds' is a 'Traditional Property' so is untyped and if accessed as a
val
On 16/04/16 06:56, André Rømcke wrote:
>> > This actually summarises many of the problems all of these 'extras' are
>> > creating for very little gain.
>> >
>> > 'Seconds' is a 'Traditional Property' so is untyped and if accessed as a
>> > value from some OS's will be a floating point number[...]
On 14. apr. 2016, at 11.47, Lester Caine wrote:
>
>> On 14/04/16 08:52, André Rømcke wrote:
>> * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
>
> This actually summarises many of the problems all of these 'extras' are
> creating for very little gain.
>
> 'Seconds' is a 'Traditional Proper
On 14/04/16 08:52, André Rømcke wrote:
> * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
This actually summarises many of the problems all of these 'extras' are
creating for very little gain.
'Seconds' is a 'Traditional Property' so is untyped and if accessed as a
value from some OS's will b
> On 14 Apr 2016, at 00:36 , Stanislav Malyshev wrote:
>
> With getters/setters, the answer is clear - yes, you can extend it with
> setters, but if your invariant relies on immutability, you'd be
> violating LSP. With properties, not clear.
So in summary preference would be that something l
Hi!
> var class ?!?
> var function ?!?
> var const ?!?
> var static ?!?
Ah, of course not. "var" is for vars.
> I did not say that a userland developer should care I only stated that
> it is one difference between a constant and a final property. ;)
This is not a difference that is important.
On 4/13/2016 10:18 PM, Stanislav Malyshev wrote:
> How exactly it isn't? Except for "static"/"const" thing (which is really
> a parser glitch and could be easily fixed if anybody cared) I don't see
> a difference. Pretending like that static/const thing is a serious issue
> that warrants some deep
Hi!
> Well, no. The differences are well explained in the deprecation RFC:
>
> https://wiki.php.net/rfc/var_deprecation
"var is currently a simple alias for public. "
> The documentation states the *var* is a substitute for *public* but in
> reality it isn't.
How exactly it isn't? Except for
On 4/13/2016 6:42 AM, Stanislav Malyshev wrote:
> Hi!
>
>> The *var* keyword is not going to be deprecated and its meaning is
>> currently kind of ambiguous. I tried to assign it a new meaning in
>> the
>
> Why is it ambiguous? It's pretty well defined, it's the same as public.
>
Well, no. The
Hi!
> The *var* keyword is not going to be deprecated and its meaning is
> currently kind of ambiguous. I tried to assign it a new meaning in
> the
Why is it ambiguous? It's pretty well defined, it's the same as public.
> class Foo {
>
> val $x;
>
> var $y;
>
> val $z;
>
> }
>
> class Bar
On 4/11/2016 7:12 PM, Fleshgrinder wrote:
> Support for mutable public properties is a different story but allowing
> them would destroy the encapsulation and I am against it without anyone
> bringing some good arguments that convince me.
>
This of course would be different with the RFC you menti
On 4/11/2016 6:59 AM, Larry Garfield wrote:
> There's an important point here that should not be missed. If these
> values are "write once then locked', which I can definitely see as
> useful, we need to have another shot at modifying them from __clone().
> If not, they are effectively useless fo
/Sending this again because the PHP mail server was down./
I thought some more about it and I think that the best choices would be
*val* (for /value/) and *var* (for /variable/) as in Scala.
Why?
The *var* keyword is not going to be deprecated and its meaning is
currently kind of ambiguous. I tr
On 4/11/16 5:51 AM, André Rømcke wrote:
On Apr 11, 2016, at 06:59 , Larry Garfield wrote:
...
(Which leads to "can interfaces define properties", which leads right back to "well
what can you do with them", which leads back to the Properties RFC. Which I still want to see
happen at some point i
I would prefer putting the "final" keyword before the "public".
final public $items;
Since we should emphasis "final" rather than "public"
There is a concept in storage devices that fits: Write Once Read Many
(WORM) https://en.wikipedia.org/wiki/Write_once_read_many
final class Value {
public worm $name;
public function __construct(string $name) {
$this->name = $name;
}
}
I'm not aware of any programming language
> On Apr 11, 2016, at 06:59 , Larry Garfield wrote:
> ...
> (Which leads to "can interfaces define properties", which leads right back to
> "well what can you do with them", which leads back to the Properties RFC.
> Which I still want to see happen at some point if at all possible, as it
> wou
On 04/05/2016 05:13 AM, Marco Pivetta wrote:
Ad. 2. `final` means class variable (like static) or class instance
property can not change their reference, it is impossible to replace zval
in such property, in my opinion `immutable` is object behavior when using
some methods you receive newly creat
Readonly is already used in the documentation for some things in the DOM
book. Writeonce sounds strange.
Sebastian Bergmann schrieb am Sa., 9. Apr. 2016 15:52:
> Am 09.04.2016 um 12:55 schrieb Niklas Keller:
> > Another possible choice would be "readonly".
>
> Rather "writeonce", no?
>
>
> --
>
Am 09.04.2016 um 12:55 schrieb Niklas Keller:
> Another possible choice would be "readonly".
Rather "writeonce", no?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Another possible choice would be "readonly".
> On Apr 9, 2016, at 09:39 , Sebastian Bergmann wrote:
>
> Am 05.04.2016 um 11:13 schrieb Marco Pivetta:
>> First of all: +1 to this: very useful for value objects!
>
> My thought exactly.
Big +1 on this feature for the exact same reasons.
>
>> do we want to use `final`, or `immutable` for
Am 05.04.2016 um 11:13 schrieb Marco Pivetta:
> First of all: +1 to this: very useful for value objects!
My thought exactly.
> do we want to use `final`, or `immutable` for these properties?
I have the same sentiment you have, that "final" would be confusing
and "immutable" would be better.
/Sending this again because the mail server was down./
+1 from my side too for this proposal. Retrofitting immutability with
additional keywords is not the nicest thing but PHP has no other way
(same was true for Java when they added it).
Using the *final* keyword while subclasses are able to ove
On 5 April 2016 at 18:28, Chris Riley wrote:
>
> I started a discussion on this a while back, but it fizzled due to not
> having an elegant solution for the 'give me a new one of these with these
> values changed' problem. I would HIGHLY suggest not using the final
> keyword. If final is used as a
On 5 April 2016 at 11:57, Michał Brzuchalski wrote:
> Hi,
>
> 2016-04-05 12:13 GMT+02:00 Marco Pivetta :
>
> > Hi,
> >
> > On 5 April 2016 at 12:06, Michał Brzuchalski
> > wrote:
> >
> >> Hi Marco,
> >>
> >> Ad. 1 it is posiible to redeclare in a sub-class final property as
> >> non-final, here
Hi Robert, Marco and Chris,
now I see your point. Lastly I've found in DZone newsletter about Java
putting `var` and `val` keywords, interesting is the second which is going
to be used in case of immutable "variables" like a "values" (that's where
`val` came from) see here http://openjdk.java.net/
Hi,
2016-04-05 12:13 GMT+02:00 Marco Pivetta :
> Hi,
>
> On 5 April 2016 at 12:06, Michał Brzuchalski
> wrote:
>
>> Hi Marco,
>>
>> Ad. 1 it is posiible to redeclare in a sub-class final property as
>> non-final, here is some gist presenting my current impl working like:
>> https://gist.github.c
Hi,
On 5 April 2016 at 12:06, Michał Brzuchalski wrote:
> Hi Marco,
>
> Ad. 1 it is posiible to redeclare in a sub-class final property as
> non-final, here is some gist presenting my current impl working like:
> https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728
>
Does this work
Hi Marco,
Ad. 1 it is posiible to redeclare in a sub-class final property as
non-final, here is some gist presenting my current impl working like:
https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728
Ad. 2. `final` means class variable (like static) or class instance
property can not
Hi Michał,
First of all: +1 to this: very useful for value objects!
A few questions:
* can you re-declare a final property in a sub-class, making it therefore
non-final? (I have reasons to do that, related with altering states via
mappers)
* do we want to use `final`, or `immutable` for these
Hey Internals,
I'm new here. I've been wondering / working on adding final properties into
PHP lang.
This work started once I had the time to read the "Core Java for
Impateient" by Cay S. Horstmann
and found it very usefull to have final properties like Java.
Those properties differ than `const`
32 matches
Mail list logo
