On 11/12/2017 7:25 PM, Rowan Collins wrote:
> On 12/11/2017 09:49, Fleshgrinder wrote:
>> 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.
>
> Yes, I wondered whether to mention type constraints; certainly the
> previous, stalled, proposal would have added them directly on what I was
> calling "fields". The more I think about it, though, the more I think a
> separate notion of "properties" like C# would be a great way to add new
> constraints in a clear way.
>
> Consider "int $foo { public get; private set; }" as defining the following:
>
> - a field which like any other variable could theoretically have any
> value, but which will never be accessed except via the property definition
> - a getter method with the signature "function(): int"
> - a setter method with the signature "function(int $foo): void"
>
> It immediately makes sense why you can't assign by reference (the setter
> method doesn't take a reference, only a value). It also makes sense to
> have this present in an interface (the implementing class is obliged to
> have such a property, but may define explicit getter and setter methods
> rather than defaults).
>
> You could then also have syntax for a property with a compile-time value
> and no setter, but I'm not sure whether this meets your requirements.
>
Having this functionality would be more than awesome. Especially because
it would allow upgrade paths for anemic code bases where all properties
are public.
On 11/12/2017 7:25 PM, Rowan Collins wrote:>> 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.
>
> What I'm not really clear on is *why* the value being known at
> compile-time is important to you. Is there some architectural decision
> you would make differently based on this guarantee? Are you expecting
> the language itself to have some optimisation or different behaviour
> based on that guarantee?
>
I expect certain optimizations, and as my fellow Austrian countryman
Harald already said, there is enough room for them.
I also expect the ability to perform calculations at compile time,
instead of at runtime. The values would stay the same forever with
proper caching.
abstract class A {
abstract const X;
abstract const Y;
final const Z = self::X + self::Y;
}
final class B extends A {
const X = 1;
const Y = 1;
}
On 11/12/2017 7:25 PM, Rowan Collins wrote:
> Would the ability to mark a function as "pure" (always returning the
> same output for the same input) serve the same purpose, since a pure
> function with no arguments can be substituted for its return value at
> compile time?
>
> abstract class A { abstract static pure function getFoo(): int; }
> class B extends A { static pure function getFoo(): int { return 42; } }
> class C extends A { static pure function getFoo(): int { return 999; } }
>
> Regards,
>
Pure functions in general would be an awesome thing in PHP, as they also
allow for many optimizations.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
