On 11/11/2017 9:51 PM, Rowan Collins wrote: > On 11/11/2017 18:39, Fleshgrinder wrote: >> On 11/6/2017 1:44 AM, Stanislav Malyshev wrote: >> >>> From this link, it looks like const in Dart has pretty much nothing in >>> common with const in PHP, besides name, so in the interest of avoiding >>> confusion, I would not discuss it in the same topic. >>> >> Yes, Dart has a different understanding of const, which is exactly why I >> posted it for you guys. In the hope that it helps to get more different >> views on the topic. Currently you are too concentrated on how it is >> implemented in PHP at this time, and argue that it is impossible to >> diverge from that path. Which is simply not true, we only have to ensure >> backwards compatibility. > > I think the point is that adding "single-assignment variables" (which > Dart calls "final") or "deeply immutable values" (which Dart calls > "const") would be a completely different feature which could be added > side-by-side with what we have now, under a different name. What PHP > calls "const" (in the context of classes) is neither of those features. >
I know and I repeat, I posted the link just to show that const can be
more than the const we currently have, and to fuel the discussion. I
never said that we have to have the same implementation they have. ;)
On 11/11/2017 9:51 PM, Rowan Collins wrote:
> The debate seems to be whether you view class constants as more like
> static properties, or static methods. Given this:
>
> class A { public const Foo = 42; }
> echo A::Foo;
>
> Is it equivalent to this (using an imaginary "readonly" modifier)...
>
> class A { public static readonly $foo = 42; }
> echo A::$foo;
>
> ...or is it equivalent to this (particularly if you imagine an
> optimising compiler that caches / inlines the result)?
>
> class A { public static function foo(): int { return 42; } }
> echo A::foo();
>
>
> The difference is that a field is never "abstract" - it either has a
> value, or it is undefined; you can't add a contract to an interface
> saying "you must have this field" either. A method, on the other hand,
> is assumed to encapsulate something - it's a black box with a contract,
> so defining the contract without any implementation makes sense. (Note
> that I've called $foo a "field" to distinguish it from a "property", as
> C# does: a property with a contract like "$foo { public get; private
> set; }" could indeed be abstract.)
>
> The interesting thing about the above examples is that the static method
> with a fixed return *already works right now*, whereas the readonly
> field doesn't exist; so it makes some sense to say that "const FOO" is
> PHP's way of saying "static readonly $FOO", and have it subject to
> similar semantics.
>
> Regards,
>
Other languages allow you to have a contract on fields.
class A { const FOO: int = 42; }
class A { final static $foo: int = 42; }
These are basically the same, as you already said. However, I added a
contract to both of them. There is one thing that differs for the const
and the field: a const value must be known at compile time, whereas a
field value does not. An important difference!
class A { abstract public const FOO: int; }
class A { abstract public function foo(): int; }
These also look basically the same. The return value of the method,
however, may also be determined at runtime (just like with fields) and
on top of that might change with every invocation.
As I said, the idea is to have a constant value that is known at compile
time. This is the definition of const in PHP. The only thing I was
asking for is to split definition and initialization by reusing the
abstract keyword.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
