Re: [PHP-DEV] Suggested change: change priority of new and ->
On 2/8/2018 7:38 PM, Mcmuffin Mcguffin wrote: > What do you think? > > Jaroslav Wegner > Thanks for the hard work to figure out what the roots of this annoyance is. This could land in the next PHP version, considering that many other breaking changes were also allowed in the past, given the following prerequisites: * RFC with a 2/3 majority vote * Tool to convert any possibly broken code into valid code (basically putting parenthesis around any complex `new (...)()`). * Update to https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#the-new-operator -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Shorthand proposal for associative arrays
On 1/26/2018 7:16 PM, Christian Schneider wrote:
> Hi there,
> I have a proposal for a shorthand notation of associative arrays borrowed
> from another language:
> :$foo
> would be equivalent to
> 'foo' => $foo
> and would work with array, list or []
>
> Motivation behind it, maybe someone else finds more good uses:
>
> 1) Emulating named parameters with associative arrays like
> html::img([ 'src' => $src, 'alt' => $alt ]);
>could be written as
> html::img([ :$src, :$alt ]);
>which encourages consistent naming of variables and parameters
>
> 2) Simplifying list destructuring with non-integer keys, example taking from
> http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list
> foreach ($data as ["id" => $id, "name" => $name]) {
>becomes
> foreach ($data as [ :$id, :$name ]) {
>which reduces redundancy.
>
> I implemented a minimal patch (2 lines are added to the parser) to implement
> this which you can find at
> https://cschneid.com/php/php7_2/assoc_array_shorthand.patch
>
> What do you think, is this worth an RFC? I hope I didn't miss an existing one
> :-)
>
> Regards,
> - Chris
>
>
Hi Chris!
I really like this proposal. `compact` is cumbersome to use, or lets
say, almost impossible without an intelligent IDE. However, what is more
important is the fact that is would allow for a very readable and usable
approach for destructuring of associative arrays (as illustrated by your
example) which is very, very neat. The change is also extremely minimal
which speaks for it.
I would support you in writing up an RFC for this (if desired).
--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OPCache: invalidate vs unlink
On 1/21/2018 1:04 PM, Nikita Popov wrote: > Unless you are running specifically into the max files limit (and not the > memory limit), unlinking from the hashtable will not provide any benefit. > It does exactly what it says on the tin, and in particular it's not going > to free up any space. > > The reason why opcache has a restart mechanism, is that it does not track > which files are currently (potentially) in use. During a restart it waits > until all workers stop using SHM, at which point the memory can be safely > reset. To improve this some more precise tracking of SHM usage would be > necessary (not necessarily per-file, but more than just "yes or no"). > > Nikita > Many thanks. :) -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] OPCache: invalidate vs unlink
`zend_accel_invalidate` is exposed to userland as `opcache_invalidate` and marks a script as wasted, however, it does not remove that script from the OPCache. There is also the `zend_accel_hash_unlink` that actually does that, it's there since the beginning of time but without a single call to it in the entire codebase. It actually removes a script from OPCache, yielding the desired result of freeing up some space without requiring a complete restart of OPCache. What are the reasons that this function is not used and not exposed? What side-effects does it have if we actually selectively remove scripts from OPCache? We replaced the `zend_accel_invalidate` call with `zend_accel_hash_unlink` in the `opcache_invalidate` implementation and it worked flawlessly. However, it could be that there are some things that we are simply overlooking. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/29/2017 6:21 PM, li...@rhsoft.net wrote: > no, when i accept "int|float" i don't get something converted at all and > i can handle the cases different - when it#s silently casted to a float > i have no way to know it was a int at call time > Again, obviously, the question remains, why would you care? Please provide convincing arguments as this would become the body of the corresponding RFC. Adding that type is super simple, the question is why is it so super handy? PS: Despite union and intersection types, they automatically allow this form and I repeat that I am totally in favor of them. The question is truly about `number` only which would accept `int` and `float` (no `string`). -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/29/2017 4:09 PM, li...@rhsoft.net wrote: > > Am 29.12.2017 um 13:08 schrieb Fleshgrinder: >> What is the use case for `int|float`? I mean, if f is able to process a >> `float` than f is able to process an `int` and since `int` is already >> automatically changed to a `float`, well, you're done > > just read the mass of bugreports caused by float answered with the > default paragraph below and you know why you don't want your int-values > silently converted to a float > > 7 may become to 7.01 or something similar and "$x === 7" > may also fail wile the argument was int 7 > > > Floating point values have a limited precision. Hence a value might > not have the same string representation after any processing. That also > includes writing a floating point value in your script and directly > printing it without any mathematical operations. > > If you would like to know more about "floats" and what IEEE > 754 is, read this: > http://www.floating-point-gui.de/ > Obviously but this does not answer anything. You expect an int or a float, hence, you need to be prepared to handle floats. Your 7 example is the best illustration. You need to handle those situations in your script with the appropriate strategy for your domain (rounding, truncation, floor, ...). -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/29/2017 4:37 PM, Nikita Popov wrote: > int|float is the natural type of numeric operations in PHP. Integers > automatically overflow into floating point numbers, so signatures using int > in conjunction with numeric operations are somewhat problematic. > > Having an explicit number type also goes well with an explicit number cast. > PHP internally has a notion of a number cast (which is the basis for > arithmetic operations), but currently does not expose it. As such, number > casts currently have to be simulated using workarounds like +$x. > Not sure I fully understand what you are saying. I mean, the accuracy problem will prevail no matter what because at some point we have to change that long to a double. The earlier the better so users know what they are dealing with. `+$x` seems like something that is only of interest if my source is a string and I don't know if it should be int or float. This on the other hand sounds like something that is happening at the edges of the application. Or maybe you had something else in mind? On 12/29/2017 4:37 PM, Nikita Popov wrote: > Regarding the union type RFCs, from what I remember, one of my personal > issues with it were the complex rules involving scalar type unions in weak > typing mode. It's non-trivial to decide what a value should be casted to if > it does not have the correct type. It's sort of clear what "1.5" passed to > an int|float union becomes, but it's not intuitively obvious what should > happen if you pass "foo" to a bool|int union, etc. > Why exactly is it necessary to support weak mode together with unions and intersections? It is obviously unclear in many situations what should happen, so why not simply bail like in strict mode? I mean, strict mode was added for backwards compatibility reasons. This is a new future, there is no backwards compatibility. Anyone using it shall abide to the strict rules of it. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/29/2017 1:26 PM, Rowan Collins wrote: > On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder > <p...@fleshgrinder.com> wrote: >> What is the use case for `int|float`? I mean, if f is able to >> process a `float` than f is able to process an `int` and since >> `int` is already automatically changed to a `float`, well, you're >> done. > > I think it is somewhat tedious if we discuss every possible pair of > types, just as it would be somewhat messy if we added a new keyword > for every combination we found a use case for. The beauty of a > general-purpose syntax is precisely that a user can use whatever > combination they need, and not use combinations they don't need. I'm > sure there are plenty of nonsensical or redundant checks that can be > expressed in other parts of the language, but that doesn't mean those > language constructs are useless or damaging. > > Regards, > I agree and I do not intend to do so, I actually am not even questioning the usefulness of union and intersection types. I am more curious in regards to providing a `number` type. Seems useless to me. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/29/2017 12:21 AM, Larry Garfield wrote:
> On Wednesday, December 27, 2017 3:50:54 AM CST Rowan Collins wrote:
>> On 26 December 2017 18:35:29 GMT+00:00, "li...@rhsoft.net"
> <li...@rhsoft.net> wrote:
>>> Am 26.12.2017 um 19:18 schrieb Larry Garfield:
>>>> If I may, I think the argument has always been that
>>>>
>>>> 1) Foo & Bar makes total sense
>>>> 2) int|float makes total sense
>>>> 3) int & string is illogical so wouldn't matter anyway
>>>
>>> not true
>>>
>>> function x(int|string $x)
>>> {
>>>
>>> $x = (int)$x;
>>>
>>> }
>>
>> I think there's a misunderstanding here. Some previous proposals for "union
>> types" also included "intersection types", so that you could assert
>> "parameter must implement both of these interfaces". So 'Foo|Bar $x' would
>> mean '$x instanceof Foo || $x instanceof Bar' and 'Foo $x' would mean
>> '$x instanceof Foo && $x instanceof Bar'.
>>
>> I presume that's what Larry means by "int & string is illogical", because it
>> would translate to "is_int($x) && is_string($x)", which is false for all
>> values of $x. This is different from "int | string", which, as you say,
>> might have valid uses.
>>
>> Regards,
>
> Correct. Union types I've always seen presented as offering both union and
> intersection. There are cases where union is great, and where it's kinda
> silly. There are cases where intersect is great, and where it's kinda silly.
>
> Most of the anti- arguments I've seen for "union types" have fixated on "int
> &&
> string is meaningless, and Foo || Bar is bad design, so union types are bad!"
>
> Entirely ignoring the flip side, which is int || string (valid use cases) and
> Foo && Bar (many many valid use cases).
>
> --Larry Garfield
>
What is the use case for `int|float`? I mean, if f is able to process a
`float` than f is able to process an `int` and since `int` is already
automatically changed to a `float`, well, you're done.
The only situation (I can think of) where this might make a difference
is while formatting them. However, in those cases one usually wants to
accept many more types (or better yet, let the type format itself).
I think that the union RFC was missing proper rules for disjunction (and
conjunction if intersection were to be included) as well as information
on disjointness. The latter would be important for exhaustive switches
that are enforced by the runtime (we'd probably need new keywords here,
e.g. `match` + `is`).
--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/26/2017 5:20 PM, Alexander Lisachenko wrote: > In some distant future it could be implemented in more natural way with > classes for primitive types and automatic boxing/unboxing for primitive > built-in types: > > Php\Type\Object > Php\Type\Scalar >⌊ Php\Type\String >⌊ Php\Type\Integer >⌊ Php\Type\Float >⌊ Php\Type\Boolean > Php\Type\Array > > And it will be easy to typehint all scalars via common parent class: > > public function acceptsScalar(Scalar $scalarValue). > > But all scalar objects in this case should be implemented as immutable or > should be passed as copy (like arrays). So, I would vote no for adding > special scalar typehint without mapping it to the common class or > interface, like iterable => Traversable, callable => Closure, etc > > Best regards, Alexander > This is what I would like to see but making the primitives objects without too much BC is a complicated thing to achieve. Auto-boxing could be a solution. However, we would need many new things and new things are in general not well received in the PHP world if they replace other things. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/24/2017 5:42 PM, Fleshgrinder wrote: > I will extend it with some examples. > > I guess that that would be useful in weak mode. Will try to hack it in. > > I am currently also working on another RFC that adds a `Convertible` > interface with a single `into` method that has its return type set to > `scalar` where objects can opt-in to become `scalar` compatible. Even in > strict mode. The idea is that the object's `into` method is > automatically called by the engine and the receiver gets the canonical > `scalar` value that represents the object. This is specifically useful > for value objects that often represent single `scalar` values in a type > safe manner. > Added some examples but I will stop now working on anything because people already start complaining again. Contributing to PHP is like kicking a combat dog ... let's wait for some support for this feature in general first. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
On 12/24/2017 5:30 PM, Nikita Popov wrote: > I think this RFC could benefit from displaying some use-cases for this type > annotation. I can't recall any recent instance where I would have found > this specific type combination useful, though I'm sure there are good > examples. > > I also wonder whether in weak typing mode, scalar should also accept > __toString objects (and cast them to string), similarly to how a > bool|int|float|string union would behave. > > Nikita > I will extend it with some examples. I guess that that would be useful in weak mode. Will try to hack it in. I am currently also working on another RFC that adds a `Convertible` interface with a single `into` method that has its return type set to `scalar` where objects can opt-in to become `scalar` compatible. Even in strict mode. The idea is that the object's `into` method is automatically called by the engine and the receiver gets the canonical `scalar` value that represents the object. This is specifically useful for value objects that often represent single `scalar` values in a type safe manner. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
Hi Internals! I prepared a PR to add the `scalar` pseudo-type to PHP after the discussions around adding a `mixed` pseudo-type. I strongly believe that it makes sense to provide the most common primitive union types with handy aliases even if we are going to add union types in the future to PHP. https://github.com/php/php-src/pull/2987 I added support for parameter type covariance and return type contravariance to make it as useful in daily development as possible. I will provide the RFC write-up asap at: https://wiki.php.net/rfc/scalar-pseudo-type -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed Typehint
On 12/19/2017 9:59 PM, li...@rhsoft.net wrote: > yes, it's mostly cosmetic (frankly even the OP statet this in the > initial mail) but if that comes witout a noticebale price to pay why not? > > "It's a simple alias for the current behavior of no type and is fully > interchangeable" sounds like it could even be optimized out at compile > time of the script - so "you don't need it" is not much compelling for me > Adding that optimization step is already more effort than not introducing it in the first place, don't you agree? Seriously, I am neutral on the topic in itself. Fact is that it is an unnecessary change from a technical perspective and it will not bring PHP forward in adopting a sound type system. I just wanted to show support for Stanislav's position because he is simply right from a technical point of view (which imho is more important in language design). There is no argument against the "we like it pretty". -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed Typehint
On 12/19/2017 8:01 PM, li...@rhsoft.net wrote: > but that's a different thing and both don't collide > It's not a different thing, that's what I try to tell you. They do not collide, of course not, but having the others is going to make mixed useless. In other words: if there is no type left to constraint to, it must be the top type. (Note that we already have the ability to constraint to the bottom type void.) Other languages invest quite some time into getting rid of annotating their top types (and type inversion) and we already have this functionality and you (not you in person but the collective here asking for it) want to introduce it. Stanislav is right, this type would be there for no technical reason. It is only for cosmetics or maybe to allow people to say "my codebase is fully type constrained". Which is literally a meaningless statement. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed Typehint
On 12/19/2017 6:43 PM, Andreas Hennings wrote: > The argument, which I support, is that "mixed" would allow to > distinguish against cases of "developer forgot to add a type hint" or > "no type hint due to legacy / BC reasons". > Also, with a "mixed" type hint, you know it is not "void" (this is > still the same argument). > The developer forgot the type constraint if there is no type constraint in: 1. the code 2. the DocBlock This is a simple rule that you can already adopt without any changes to the language. The thing is that mixed is not required at all at the moment PHP supports more sophisticated type constructs. As I said earlier, pursue them, not this. PS: It's interesting how people fail to see the power of union and intersection. This is currently happening on the Kotlin side too. A simple example for a union type was already given: `string|int`. Although in this case I would argue that anything that is convertible to a hash (e.g. `Hashable` as found in php-ds) and ensures an equivalence relation (not partial like float) should be usable as a key in an associative array. The introduction of dedicated types for this is definitely required in the language. That being said, union types are usually of interest if you are interacting with some library code that you cannot change (e.g. add interfaces to an existing type). Of course, one could argue that the introduction of dedicated interfaces in your own codebase plus adapters is the way to go but this requires much more effort than the in-place union declaration. Discriminating unions would be much nicer but that is something a proper enum impl should cover. Intersection is a whole other beast that is actually more powerful than the simple unions we know from PhpDoc. Consider the following example: interface Writer interface Reader interface Seekable interface AutoCloseable interface Closeable We could now continue and provide ReadableWriter, SeekableWriter, SeekableReadableWriter, ... but this already gets out of hand. An intersection on the other hand allows you to define exactly the features you require: fn f(Closeable & Seekable & Writer writer) This can of course be provided with a generics impl which would probably make the parsing impl simpler: fn f(T writer) -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed Typehint
On 12/19/2017 7:32 AM, Stanislav Malyshev wrote: > I'm not sure what's the point of it. "mixed" means "any type". Not > writing a type means "any type". So why waste space and add something > that contributes nothing when everybody is already using the current > convention and the new one does not add anything at all? > I agree with Stanislav here, there is no point in adding this type constraint. Documenting mixed with PhpDoc was required in the past because it was not possible for documentation tools to distinguish between `@param string` and `@param mixed` because there was absolutely no type information available. This has change today, you can ensure that the tools understand your types. What is really needed are `scalar`, `number`, union types, intersection types, and all that together with generics. Note that the situation would be different if our super type (which is `mixed`) would allow for some common action, e.g. `equals`. That is not the case, hence, there is no point in constraining it. Both the super and bottom type (`void`) in PHP are totally behaviorless. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Constants and Access Modifiers
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
Re: [PHP-DEV] Constants and Access Modifiers
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
Re: [PHP-DEV] Constants and Access Modifiers
On 11/12/2017 12:44 AM, Stanislav Malyshev wrote: > Hi! > >> 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 am not arguing it's impossible, I am arguing it is not a good idea. We > have the concept of constants in this language, and bolting on it a > completely different concept from different language, which by > coincidence was named with the same term, would only be a source of > confusion. If we wanted immutable objects in language - which I am not > convinced at all we do, but assuming for a minute we did - there's no > reason to conflate them with constants as we have them now. These are > different things. > I did not mean to say that we have to have everything exactly as Dart has it. I just wanted to show, that the meaning of const as we have is not universally the same. Abstract constants would also only be truly useful if we could define the type as well on them. Which is currently not possible. Also, I am not saying that the requested feature MUST be done with const. However, it should behave like one, which is impossible with methods. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Constants and Access Modifiers
On 11/6/2017 1:44 AM, Stanislav Malyshev wrote:
> Hi!
>
>> An abstract constant is a constant that requires its value to be defined
>> later, like an abstract method that requires its implementation to be
>> defined later.
>
> It's not a constant then, and should be a method.
>
No, because a method can change what it returns, it is not constant.
On 11/6/2017 1:44 AM, Stanislav Malyshev wrote:
>>
>> The thing is that I want something that CANNOT CHANGE. I want to require
>
> You are contradicting yourself. If it is not known upfront, then it can
> change - otherwise, you'd know it upfront. I'm not sure what you're
> trying to do here, but I am getting pretty sure you shouldn't be doing
> it with const's :)
>
No, I want to split the definition and initialization. The value cannot
change, once it is initialized.
On 11/6/2017 1:44 AM, Stanislav Malyshev wrote:
>> Dropping support for constant inheritance is imho also wrong from a pure
>> logical point of view, since a constant's value is only constant if I
>> refer to the very same constant. Meaning, the value of a constant in a
>> subclass must not be the same value as the value in the superclass.
>>
>> class Integer extends Number {
>> public const MAX = \PHP_INT_MAX;
>> public const MIN = \PHP_INT_MIN;
>> }
>>
>> class WholeNumber extends Integer {
>> public const MIN = 0;
>> }
>>
>> class NaturalNumber extends WholeNumber {
>> public const MIN = 1;
>> }
>
> Integer::MIN and NaturalNumber::MIN are different constants. So, it is
> natural that they can have different values. Though using constants with
> these names is slightly misleading, but if you always use full name, not
> by much.
>
I do not follow, what is misleading about them? Referencing them without
the full name is also not possible in PHP, hence, not an issue.
On 11/6/2017 1:44 AM, Stanislav Malyshev wrote:
>> does, simply because it is a different value. Of course we expect it to
>> be compatible, they are after all in a tight relationship (inheritance).
>
> Here you are getting into a dangerous territory, btw. Depending on your
> modeling needs, of course, but your NaturalNumber can violate contract
> of Integer, such as "being able to represent -10". Thus, inheritance
> could be wrong way to do it, at least in the way you described above.
> One has to be very careful with which exactly contract are you modelling
> - inheritance is not just shortcut for avoiding copy-paste.
>
I am not sure how you deduce that NaturalNumber can be -10. There are
not invariants defined anywhere on the classes. You are correct that
inheritance should not be misused for code reuse, it should be used to
build type systems. Which is exactly what I am doing in the example.
On 11/6/2017 1:44 AM, Stanislav Malyshev wrote:
>> I mentioned Dart in the initial message, they have a much richer
>> understanding of const than we have it in PHP. Maybe this also helps to
>> broaden your views on the topic:
>>
>> https://news.dartlang.org/2012/06/const-static-final-oh-my.html
>
> 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.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Constants and Access Modifiers
On 11/5/2017 1:03 PM, Niklas Keller wrote:
>>
>> Hi!
>>
>>> My wording was maybe a bit wrong here, and I was biased by the fact that
>>> I would like to see abstract constants. The fact that not everything can
>>
>> What is "abstract constant"? If you need something that can change, just
>> use a method. Constant is meant to be a nice way to write something
>> inherently constant, such as instead of "/very long
>> (and+)cubmber|some?*regexp/" you'd write NICE_REGEXP_CONSTANT. But it's
>> not supposed to create parallel inheritance structure or something. If
>> it needs to be non-constant, just use a method.
>>
>
> Totally agree with that. We should deprecate constant inheritance instead.
>
> Regards, Niklas
>
An abstract constant is a constant that requires its value to be defined
later, like an abstract method that requires its implementation to be
defined later.
The thing is that I want something that CANNOT CHANGE. I want to require
that you define the value, a value that is known at compile time, a
value that is immutable, a value that can never changes during the
program's execution. This is not achievable by current, available means.
What you describe is the intention of the current class constant
implementation of PHP, and some other languages. Pure logic does not
support this claim. The only thing a constant should provide is that its
value is known at compile time. That being said, we already violate that
by supporting dynamic constant definitions via define, but let's not go
down that road here.
Dropping support for constant inheritance is imho also wrong from a pure
logical point of view, since a constant's value is only constant if I
refer to the very same constant. Meaning, the value of a constant in a
subclass must not be the same value as the value in the superclass.
class Integer extends Number {
public const MAX = \PHP_INT_MAX;
public const MIN = \PHP_INT_MIN;
}
class WholeNumber extends Integer {
public const MIN = 0;
}
class NaturalNumber extends WholeNumber {
public const MIN = 1;
}
We expect that `Integer::MIN` always yields the same value, rightly so,
since it is a constant. However, nobody expects that
`NaturalNumber::MIN` is going to yield the same value as `Integer::MIN`
does, simply because it is a different value. Of course we expect it to
be compatible, they are after all in a tight relationship (inheritance).
They also have to be compatible to each other, otherwise we would
violate the substitutability.
I mentioned Dart in the initial message, they have a much richer
understanding of const than we have it in PHP. Maybe this also helps to
broaden your views on the topic:
https://news.dartlang.org/2012/06/const-static-final-oh-my.html
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Constants and Access Modifiers
On 10/27/2017 11:15 PM, Nikita Popov wrote: > PHP does not permit self-referencing constants. > > However, this is only checked when the constant is first accessed. In your > first example the constant is never accessed, so no error is thrown. This > has nothing to do with subclasses defining the value -- you're using late > static binding, so you're accessing the constant of the child class > directly. > > PHP cannot detect self-referencing constants during compilation, because > they may be formed through non-trivial cycles involving multiple constants, > across multiple files. > > Nikita > My wording was maybe a bit wrong here, and I was biased by the fact that I would like to see abstract constants. The fact that not everything can be detected at compile time, but only later at runtime is normal in a highly dynamic language like PHP. Self-referencing constants make no sense, hence, it is fine. It would of course be better if the compiler could detect that earlier, but we are not doing AOT so imho that is fine. The behavior here is also consistent among versions as well as HHVM, all good. What do you think about the other ideas I raised? -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] Constants and Access Modifiers
Hey Internals! We currently have a couple of things that are broken about constants, and I wanted to gauge if people are interested in a) fixing it as well as b) to get to know the root causes of these things. # 1 A constant defined in an interface cannot be overwritten in the class that implements the interface, however, further subclasses can overwrite the content of the constant at will. - https://3v4l.org/DFB37 - https://3v4l.org/9LMci A constant defined in a class can be overwritten by any subclass at will. # 2 Constants can reference themselves, and subclasses can define the actual value. Kind of like abstract constants. This works nicely while working with an actual instance of the object, however, it breaks in the moment that constant is accessed anywhere in the parent, or from any other constant. - https://3v4l.org/HUCTh - https://3v4l.org/5aYB5 # 3 A constant that is defined with a visibility in a parent class, cannot be references between subclasses, like it is possible with methods. Instead we are presented with an access violation. - https://3v4l.org/2lU3i Note that this behavior is the same for static and instance properties that are being redefined in a child class. Hence, access is defined by location and not by modifier. # What I think I haven't thought very long about everything, but here are my initial thoughts: ## 1 This issue could be resolved by changing the behavior to enable overwriting of parent constant in any sublcass. This gives us a consistent behavior. Afterwards we should add support for the final modifier, so that people can seal their constants and protect them from redefinition. > Why not seal by default? It would disallow some dynamic programming that is possible with the late static binding of PHP, and I honestly see no reason why we should disallow something that is already possible: BC! ## 2 Disallow self-referencing constants in any context, and instead add support for the abstract keyword to constants. This raises the question on how to deal with constants in interfaces. I would allow the definition of both constants with and without a value there. Those without are abstract, those with a value are like they are right now. Directly referencing an abstract constant should result in an error. Abstract constants are a great thing in combination with late static binding, and the engine ensures that the value does not change over the course of the runtime of the program. An attribute that is impossible for methods. Dart for instance has support for the const keyword for many elements, including methods. ## 3 This seems like a bigger construction site. I think that the behavior should be that the access is determined by the modifier, and not the location. Especially because doing anything else is to great of a BC. The current behavior of allowing access to protected members of other classes with the same parent also allows the creation of friend classes. Although without the control that real friend classes have. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] json(Raw)Serializable?
On 10/24/2017 2:20 AM, Sara Golemon wrote:
> https://bugs.php.net/bug.php?id=75400 is asking for a version of
> JsonSerializable which doesn't involve deserializing/reserialzing
> round trips when a chunk of JSON is known in advance.
>
> It's not terribly unreasonable IMO, but before I just writeup the RFC
> as described (jsonRawSerialize taking preceedence over jsonSerialize),
> I thought I'd ask for opinions on the specifics.
>
> In psuedo-code:
>
> if (is_object($obj)) {
> if ($obj implements JsonRawSerializable) {
> // use $obj->jsonRawSerialize() as is.
> } elseif ($obj implements JsonSerializble) {
> // use json_encode($obj->jsonSerialize())
> } else {
> // Serialize the object's public properties as a key/value map
> }
> }
>
> Perhaps with the stipulation that if jsonRawSerialize() returns null,
> we'd fallback on jsonSerialize(). Any other non-string results in an
> encoding error.
>
> -Sara
>
I agree with the others here. People often think that they can simply
write the JSON on their own, but forget about the requirement for valid
UTF-8 and other escaping and encoding stuff. It's better to simply not
support it in the first place.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes
On 10/13/2017 11:40 AM, Thomas Punt wrote: > Morning internals, > > > I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more > flexible[1]. Any thoughts? > > > Thanks, > > Tom > > > [1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes > Hi Tom! I love it, definitely should go in. I am sure there are some special cases that will be discovered in this discussion, but it's an awesome feature. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Declined] UUID
Hey Internals! The UUID RFC [1] was now officially declined. Some of you might ask themselves what's going to happen next. Well, I will most probably move it to PECL after a little overhaul where I incorporate the latest feedback I got on the PR. After that I also hope to see some progress on the C+PHP front. I might revive the namespace topic after gaining some strength and free time, and hopefully we can create a real standard collection in PHP for a better future. We'll see. Thanks to all the voters and people who gave feedback. It was a ride, but that was to be expected. [1] https://wiki.php.net/rfc/uuid -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
On 9/6/2017 9:56 PM, Stanislav Malyshev wrote: > BTW, the RFC text does not have vote end date, please add it. > Done, had to move that to Wednesday, because I won't have Internet access until then. Closing it today would mean that the min of 2 weeks voting would not be achieved. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
On 9/5/2017 9:32 PM, Andreas Heigl wrote: > I'm well aware of that and perhaps I didn't express myself as clear as I > should have. > > Imagine a use-case where a UUID-class is needed. But alongside the > toString, toHex and toBinary there's also the need for a further > function (let's call it toArray). So currently I need to create a > wrapper arround UUID that then needs to implement all the public methods > of UUID as well as the new toArray. So it works identically to UUID but > it isn't UUID. And I have no way of using my own UUID-Class - as it > doesnt' extend UUID - as replacement for UUID. I'd need to expose the > wrapped UUID-Class to be able to retrieve it whenever some libray > expects a UUID. Perhaps this gist can make it clearer: > https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa > > I'm not saying it's the wrong choice. I for myself would probably not > immediately use it as the ramsey/uuid-package is widely in use, but I > could f.e. think, that that package might start to use the UUID-class > under the hood. And then that would be a case where extending could be > helpful as a \Ramsey\UUID would be an instance of \UUID. > > The alternative would be to implement a UUIDInterface that exposes the > relevant methods and that would be implemented by \UUID itself. > > But that's just my 0.02€ > > Cheers > > Andreas > OK, now I understand it better. I would argue that if we really find something existential that should be added, we should add it to the UUID class itself. See, the problem with allowing extension is that we have a real BC issue. All your arguments are well received and correct, but the open a can of worms that is impossible to close. Keeping it final ensures that this cannot happen, ever. We can continue to refine without breaking anyone. I think it also was Ocramius who released a nice article about "final first", but there are probably many from the Java world. Btw. the interface does not really make sense. Interfaces are for polymorphism, in other words, if there are different implementations of the same thing that should be usable interchangeably. This is definitely not the case with UUIDs, the algorithm is set in stone. Don't forget that you can instantiate any kind of UUID with the `fromBinary` method, so you can easily generate different UUIDs on your own and still use the built-in class; no need for extension. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
I'm sorry if my replies sound pissed. I'm generally not good at being diplomatic in writing or talking, and currently under a lot of stress in real life (which is of course not the problem of you guys). Please bare with me, I honor all constructive feedback I receive, truly! -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
On 9/5/2017 7:01 PM, Andreas Heigl wrote: > Hey Richard, Hey all. > > Thanks for putting up the RFC and the implementation! > > Having UUIDs in the core would be awesome. One of the reasons would be > that it's in C. That'd be faster but would also allow easier integration > with system-calls to be easier able to get the MAC-Address for a type-1 > UUID f.e. > > But why limit UUIDs to type 3 through 5? Having security in mind is good > IMHO but not implementing type 1 and 2 limits the usability and > therefore the usefullness. Let the users decide whether they need it or > not. As long as people can create SQL-Injections in PHP we should not > use the security argument to limit usability or not implement > standardized functionality. > > Especially when there is a full-fledged reference-implementation in > userland available. In the RFC you reference ramsey/uuid yourself. But > why should one use the internal UUID-class/functionality when there is a > more powerful one in userland available? > > And limiting the usability and extendability of the UUID-Class itself by > declaring it final means that userland-code can only wrap the class but > not extend it. So userland code can not typehint for the UUID-class when > special features are necessary that would need extending the class. And > as there's no interface, I can't typehint for that either. > > So all in all for me that's > > * less functionality than the reference-implementation > * missing UUID-types (the ones that are easier to implement in C) > * missing extendability > > and a naging feeling that the imlementation decides what I as a user > actually need. > > That's why I can't vote "yes". > > Sorry. > > Thanks for putting in the effort and coming up with a first implementation. > > Cheers > > Andreas > > PS: Personally I don't like a "uuid_4_create" as that would also mean > there should be a "uuid_1_create" through "uuid_5_create" as well and > then there also would need to be a "uuid_1_verify" through "uuid_5_verify"… > Hi Andreas! Thanks for your feedback. We can easily add v1 and v2 because the class is final. It would not be a breaking change, or anything. v2 is pretty much useless imho, but v1 if done right would not even harm your privacy. Composition is more powerful than inheritance. You mention that you cannot extend it to add functionality, at the same time you want to type-hint against it. Well, in order to use the extended functionality you need to type-hint against your extended version. Hence, there is zero value for you in extending it other than having some place using the extended version, and others the core version without noticing that it got the extended version. The thing is, you should create your own value objects for your identifiers and hide the fact what it wraps. In C, and many other languages, we have type aliases. In PHP, and many other OO languages, we use composition to achieve that. Whether to make it final or not was discussed, and especially Ocramius agreed with me on this. I believe that it is the right choice. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
> proposal is accepted as-is, would we feel comfortable deprecating it with
> 50%+1 majority? If the answer's no, introducing it shouldn't be at 50%+1
> either.
>
> Zeev
>
>
I'm not going to propose a procedural API, because I truly believe that
it is the wrong abstraction for the problem. You, or anyone else with
the required Karma, can however propose a procedural API in a separate
RFC. I cannot do anything against that, and that is good and fine.
However, there is nothing that requires that I do that if I believe that
it is wrong.
A UUID is not a string, it is a 128 bit integer as defined in RFC 4112.
The string forms are meant for human readability, and serialization
only, not for dealing with them in a program. The first question that we
would need to answer would be then, what should `uuid_vx_create` return?
The binary form? The hex form? The string form? No clue to be honest.
Let's say we return the string form, because it is immediately readable
for anyone if printed.
How do I get the hex version of it?
Dedicated function again?
How do I get the binary version of it?
Dedicated function again?
Or maybe require people to use Composer, and search for a package on
their own?
Then again, it's totally simple. `str_replace('-', '', $uuid)` and you
have your hex version, now just add a `hex2bin($hex)` to that result,
and you're good to go.
Should we add that to the documentation?
Should we keep it a secret, and everybody needs to learn that on their own?
The latter is how it is done in C. A low-level language. Is PHP a
low-level language? I do not think so.
Another issue with the whole thing is with passing that UUID around.
People have to validate the string everywhere. Hence, we need a
`uuid_parse` or `uuid_is_valid` function.
Or should we again recommend Composer?
Then again, is Composer part of PHP?
I hope you're still with me. What I want to say is, that a procedural
approach comes with more questions than answers. A class can provide all
of this at once. People can decide what they want, binary, hex, or
string. We do not have to make that decision for them!
The proposed UUID class is smaller than the one in Java, Rust, Python,
... I made sure of that. I made sure that it has the least impact, as
well as the least complexity possible. While still providing the ability
to accommodate almost all needs. Doing exactly the same with a
procedural API that covers all the same use-cases would be much harder.
This might have to do with personal preference as well. However, I think
that you can only design something good in the way you prefer it. I do
not believe that people who never create procedural APIs are good at it.
They lack the knowledge in doing so. The same is true for designing a
purely functional API, I would not be good at it.
Hence, me proposing a pure procedural API might lead to a bad API.
I would like to add that PHP not only historically has bad APIs. We just
added the Sodium extension which has a horrible and confusing API as
well. I complained about this, its still being merged. There are already
thread popping up on Reddit about it ... it was added a few days ago.
That is sad, that makes me sad, ... I understand now why the PHP-FIG was
initiated, those people probably had comparable issues with PHP.
I joined internals because I want to help, I want to help with getting
in stuff that is actually useful for all web developers out there. A
dedicated UUID structure is one such small thing. A UUID string is not,
because it creates more problems than it solves. Probably spawning a PSR
for UUIDs, with an interface and two hundred implementations, where the
one is more over-engineered than the other.
I say let us fix this for once, and be done with it.
I gladly stop the vote, to ensure that the UUID topic is not blocked for
6 months. I will not provide a procedural API, because of the points
made. However, anyone is free to pick my code and provide one. Anyone is
free to propose the PECL version, which is already procedural (well, it
works only on Linux).
I'm, however, open to change the API to accommodate all valid points
raised; like Nikic did and does on GitHub. I actually already addressed
many issues based on his and the feedback of others on GitHub.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
On 9/2/2017 2:26 PM, Zeev Suraski wrote: > >> On 2 Sep 2017, at 13:43, Fleshgrinder <p...@fleshgrinder.com> wrote: >> The discussion was really ongoing for a long time, and actually very >> heated as well. It was on GitHub with lots of comments, Internals, >> Reddit, Twitter, ... everywhere. > > As far as I'm concerned the only relevant discussion is on internals. It's > ok to use other mediums (although personally I think it's not very positive) > - as long as they're ultimately represented on internals. > > My quick search suggested there was only roughly two days worth of discussion > sometime in May, but it's possible I wasn't thorough in searching. > What I wanted to say is that the discussion was not held secretly, on the contrary, it was very loud on many channels. I am not sure what you want from me, because everything followed the officially prescribed procedures. Not sure if I can be blamed that some people missed it. I asked for additional feedback not two weeks ago before I started the vote. On 9/2/2017 2:26 PM, Zeev Suraski wrote:> Not really - all of those give substantial value that can't really be provided without a class. Not so with UUID - I'm quite with Nikita when he says that 95% of the value can be had with a single function call - it's therefore not a good candidate for mandatory object wrapping. > Type safety alone is such a substantial value to me, and many others, that it is reason enough to go for the class. This is also my argument in the RFC, and I stand by it. On 9/2/2017 2:26 PM, Zeev Suraski wrote: > Rightfully so - I don't think a UUID namespace is the answer as it's an > overkill. But UUID isn't just a global class name - it's actually a global > class name that's not that unlikely to exist in apps and collide with them > (as opposed to, say, UUIDParseException). At minimum the comment about the > risk being very low, as well as the personal preference not to have user > classes in the global namespace should be removed, imho, even if we can't > come up with a better name. It may be that sticking with the UUID class name > is the right choice (if we pick the wrong choice of introducing a class and > not a function :-) but we should be accurate and upfront as to why we think > it's ok. I did not propose a UUID namespace, that is what others from Internals wanted. My namespace proposal is much greater than that. However, the feedback was one-sided and hostile, so that I decided to withdraw the RFC, and seriously think about why I should continue contributing to PHP. https://wiki.php.net/rfc/namespaces-in-core On 9/2/2017 2:26 PM, Zeev Suraski wrote: > Where's the poll / vote that most people think differently? > Either way, even if it can be argued that for this particular case > performance is a weak argument (which is debatable), it's most certainly not > an inherently weak argument as the current wording implies. There shouldn't > be a ratified PHP RFC implying that performance considerations are weak > arguments, without clear context and explanation. The people were the ones here on Internals. Read the discussion thread again. I gladly change the wording, because I also think that performance is a valid argument, but did not feel like it would be accepted. Hence, the wording. On 9/2/2017 2:26 PM, Zeev Suraski wrote: > Regardless of being final, they'll become a basic building block in apps, and > taking them away or modifying them means substantial breakage. The very > introduction of the class, its name (and to a lesser degree its > functionality) - are tickets with remarkably expensive cancelation options. > > Zeev > This is true for any addition to the language, and imho not an argument against the inclusion of new features. I did my very best to create a good API that is useful in daily life. I understand that you prefer procedural programming, and I understand that you do not see the value of type safety. I prefer OO, like the majority of today's PHP community, and I prefer type safety, and the implementation is the result of these preferences. Feel free to create procedural aliases, like we have it for almost all other classes in core. I think one way to do things is better, but I also know that this is not the PHP way. Confusing APIs and multiple ways to do the same thing is the status quo. I believe we should break out of that, and cleanup, but many others don't ... alas. Another reason to leave PHP behind. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
Hey Zeev :) On 9/2/2017 12:14 PM, Zeev Suraski wrote: > I just voted 'no', and I'd like to quickly explain why: > > 0. I agree with the premise of the RFC, that we should have something better > than uniqid() built into the language. > 1. I think a renewed discussion, beyond the two days of discussion 3+ months > ago would be useful, as beyond that basic (yet important) point - I have > thoughts about a bunch of things in the RFC, and honestly didn't even notice > the brief discussion months ago (if there was another one then my apologies, > I couldn't find it). The discussion was really ongoing for a long time, and actually very heated as well. It was on GitHub with lots of comments, Internals, Reddit, Twitter, ... everywhere. On 9/2/2017 12:14 PM, Zeev Suraski wrote: > 2. I think that a function that returns a string (a-la uuid_v4_create() > Nikita proposed) would make perfect sense. Forcing the use of > classes/objects in such a case - where there's little to no added value, is > wrong and uncommon (possibly unprecedented) in PHP. DateTime? SPL? Intl? On 9/2/2017 12:14 PM, Zeev Suraski wrote: > 3. The section dealing with backwards incompatible changes, states: > "Both UUID and UUIDParseException are now globally defined classes, which > might collide with user defined classes of the same name in the global > namespace. However, the risk of the introduction of them is considered to be > very low, since the global namespace should not be used by PHP users." > ... erroneously assumes that all code in PHP utilizes namespaces. IMHO this > is a projection of a particular coding style onto the entire PHP userbase. > We haven't deprecated at any point the ability to place user classes in the > global namespace, we haven't even as much as said at any point we might be > considering it - and I don't think we should, either. My gut feel, backed > by a quick Google search refutes the assumption that the risk of introducing > - at least the UUID class - is very low. Not that I have a better suggestion > (other than not introducing a class at all) - but I think the text there > should be changed as it does not reflect reality. The very same would be true for any function that is being introduced in the global namespace. I had an RFC for namespaces prepared and ready for vote; incl. a namespaced UUID implementation. However, the feedback on it was so extremely negative and hostile that I decided to withdraw it. On 9/2/2017 12:14 PM, Zeev Suraski wrote: > 4. If I voted yes, it would also mean I agree with a statement such as "One > could argue that it is faster (C implementation), which it probably is, but > this is a weak argument". I disagree it's a weak argument - and I do think > that for basic building blocks of the language, performance absolutely > matters. If we manage to get JIT out the door and the performance > differences become negligible - then I see a lot of value in moving some of > our core value to PHP - but not before then. I would agree, but most people think differently. The wording is a result of the discussions. On 9/2/2017 12:14 PM, Zeev Suraski wrote: > 5. Given we seem to agree this is a basic building block of the language (as > it is in other languages), I do think it should be a 2/3 majority vote and > not a 50%+1 one. Taking the "is this something we can easily change w/o > affecting BC" test, this clearly gets a 'no'. Actually we can. Both classes are final and users cannot extend them. The only thing we cannot do is rename the stuff that's already in them. This is one of the reasons why I kept the provided functionality to a bare minimum. On 9/2/2017 12:14 PM, Zeev Suraski wrote: > To summarize - I'm strongly in favor of fixing this issue in PHP, but at the > same time against the proposed solution. I'd vote in favor of something > along the lines of uuid_v4_create() in a heartbeat. > $bin = \UUID::v4()->toBinary(); $hex = \UUID::v4()->toHex(); $str = \UUID::v4()->toString(); You can already use it like you want, with greater possibilities and freedom. Incl. auto-completion with your favorite editor to explore your possibilities, and type-safety everywhere as an opt-in. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] UUID
On 9/2/2017 9:32 AM, Niklas Keller wrote: >> >> Hello Internals! >> >> I just started the voting for the inclusion of a UUID value object in >> PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick >> the whole week. >> >> The voting is open starting now and until September 16. (2 weeks). > > > RFC: https://wiki.php.net/rfc/uuid > This is the second time that I forget the link, stupid me. Thanks a lot. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [VOTE] UUID
Hello Internals! I just started the voting for the inclusion of a UUID value object in PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick the whole week. The voting is open starting now and until September 16. (2 weeks). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 8/20/2017 1:56 PM, Dan Ackroyd wrote: > On 20 August 2017 at 11:45, Fleshgrinder <p...@fleshgrinder.com> wrote: >> On 5/24/2017 2:28 AM, Fleshgrinder wrote: >> >> I would like to start the voting phase the next days, but leave a little >> time for further feedback before doing so. > > > Perhaps it was clear in your head, but in the context of this email, > it is completely unclear which RFC is the subject of this sentence. > > Is it this one? > > https://wiki.php.net/rfc/uuid > > cheers > Dan > Oh, sorry, I thought its clear because I reused the original discussion thread for it ... yes, it is about https://wiki.php.net/rfc/uuid -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 5/24/2017 2:28 AM, Fleshgrinder wrote: > Hey internals! > > I haven't written the RFC yet, but the implementation is already done. I > think that this is enough to start the discussion, since the concept of > UUIDs should be well known to most people. > > https://github.com/php/php-src/pull/2535 > > The best starting point, also for non-C people, is the stubs directory > where I created PHP files with full documentation: > > https://github.com/Fleshgrinder/php-src/tree/rfc/uuid/ext/standard/stubs > > I am also planning on providing PHP 5 and 7 polyfills, so that people > can prepare their code long before the feature is actually landing in > userland. > The class naming [1] issue has been resolved and I withdrew the namespace RFC [2]. The Doxygen RFC [3] was declined, and I removed all comments from the sources as well as the stub files. I would like to start the voting phase the next days, but leave a little time for further feedback before doing so. [1] https://wiki.php.net/rfc/class-naming [2] https://wiki.php.net/rfc/namespaces-in-core [3] https://wiki.php.net/rfc/doxygen -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/3/2017 6:40 PM, Fleshgrinder wrote: > Next promised RFC (and the last one for this weekend): > > https://wiki.php.net/rfc/namespaces-in-core > > I am unsure about whether we should avoid the usage of abbreviations for > things like language (lang), standard (std), and utility (util). I think > it is not necessary to write them out fully, but, well, ...?!? > I am withdrawing this RFC. The topic is to controversial and I do not plan on pursuing it any further. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Voting] Class Naming
On 7/4/2017 11:24 PM, Christoph M. Becker wrote: > Hmm, one might dislike having the coding standards amended in this > regard, but still may have a preference on how it would be changed, if > the change will be accepted. > Haven't thought about it this way, that actually makes sense. What I want to avoid is that anybody thinks that the second poll has any meaning if the first one is a "no". In that case the second one is "nothing". That is basically the point. A vote like you said definitely makes sense, yes. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Voting] Class Naming
On 7/1/2017 7:42 PM, Fleshgrinder wrote: > https://wiki.php.net/rfc/class-naming > > Voting starts now and will be open for two weeks (July 15). > Just to clarify something that came up: Voting "no" on the first poll means that we are not going to define a rule for class naming. Hence, voting "no" on the first poll and yes on anything in the second has no effect! This is how all multi-polls so far worked and this one is no exception. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] [Discussion] Class Naming
On 7/3/2017 7:18 PM, Niklas Keller wrote: > While true, most applications actually depend on the case for class > names because of autoloaders. > > Regards, Niklas > Nobody is auto-loading internal classes, they are auto-loaded by PHP. That is the only thing this vote is about. PS: Note that I personally would vote for "always PascalCase" because context awareness is a bad thing when it comes to such things as naming. However, I have no vote and the current landscape of PHP internals goes more in the "except acronyms" direction. It is up to the voters, but the casing is not an issue for this vote, that's all I'm sayin'. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] [Discussion] Class Naming
On 7/3/2017 5:30 PM, Andreas Treichel wrote:
> With any exception from PascalCase you cannot e.g. generate class names
> from strings without a explicit mapping table:
>
>
> function findParserByRootNode(DomDocument $document)
> {
> $tagName = $document->documentElement->tagName;
> $className = ucfirst($tagName) . 'Parser';
> if (!class_exists($className)) {
> throw new RuntimeException('Parser not found for '.$tagName);
> }
> return new $className();
> }
>
> $document = new DomDocument();
> $document->loadXml($xml);
>
> $parser = findParserByRootNode($document);
> $parser->parse($document);
>
>
>
> acronyms in PascalCase looks strange, but consistent strange.
>
>
Not true in PHP because class names are not case sensitive:
https://3v4l.org/bcAAC
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Voting] Class Naming
On 7/1/2017 9:13 PM, Pieter Hordijk wrote: > https://wiki.php.net/rfc still says no RFCs are in voting. > > Thanks, fixed. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Voting] Class Naming
https://wiki.php.net/rfc/class-naming Voting starts now and will be open for two weeks (July 15). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Declined] Doxygen
The Doxygen style for commenting was declined with 16 (no) versus 11 (yes). https://wiki.php.net/rfc/doxygen -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/3/2017 2:03 PM, Fleshgrinder wrote: > As previously announced, I would like to set an end to these discussions > in the community: > > https://wiki.php.net/rfc/class-naming > Last call for comments. Four weeks have passed and I would like to start the voting phase on this one. Voting will start on Saturday around 4 PM UTC and last for two weeks if no concerns are raised here. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Vote] Doxygen
On 6/24/2017 11:28 PM, Anatol Belski wrote: > I voted no, because it is too short term and I'd see a productivity > drop having such an obligation suddenly right in place for 7.2. To > implement the change, there's more than just to put the doc into the > source. Every piece of code needs to be revisited by someone who > understands it. > > I'm not saying the current situation is better than the aim, but to > be realistic - the change needs a culture to be developed. It is > clear, that some know doxygen, but I believe maintaining the doc will > be still a huge effort for many contributors. If some patch were in > place - at least one would have a source for learning by watching, so > it would reduce the learn hurdle Without being familiar with > Doxygen the actual productivity will for sure suffer. > > Neither there's a patch covering at least the very core, nor there's > a strategy for the transition period. I can imagine, that even if the > RFC is voted positive, many contributors not familiar with doxygen > won't have time to complete the doc part. The intention good, but the > assertion might be hard. I might be wrong, but ATM I think the > intention is good, whereby the RFC implementation owes IMHO some > elaborated strategy. > > Regards > > Anatol > We are only voting that we want to use Doxygen for documentation as a format, not that documentation is a must for PRs or anything. From the RFC: > This RFC does not propose any big documentation fest where development > is halted and everybody starts writing documentation. Rather to start > documenting in the future, as well as while refactoring or rewriting > existing code. Hence, it would be nice to write a little while one is working on something anyways. There is no must to document! There is a must that IF you document, that it must use Doxygen. That's what we are voting on. Everybody has plenty of time to get acquainted with Doxygen and we can create follow-up RFCs with clearer rules on how to document (if need be). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Vote] Doxygen
On 6/23/2017 5:12 AM, Christopher Jones wrote: > That kind of detail belongs in the RFC. > > A link to existing 'prior art' would have rounded the picture out and let > people decide between alternatives of internal vs external doc. > E.g. link to https://wiki.php.net/internals/references > > Also, is this for core and for extensions? Or for core only? What > about PECL extensions not part of the PHP bundle? > > In summary, see point 8 of > https://blogs.oracle.com/opal/the-mysterious-php-rfc-process-and-how-you-can-change-the-web > > > Chris > Hi Chris! I agree and if I would have thought about it, I would have included it. (This is not an excuse, just the honest truth.) I can create a follow up RFC with more detailed rules, or maybe we wait a little so that everybody can get acquainted with Doxygen first. Regarding PECL: I clearly state in the introduction "for the C sources of PHP" (in other words, everything inside the php-src repository) and I would stick to that. PECL authors should be allowed, like Composer authors, to do whatever they want. PECL extensions that are to be included in "the C sources of PHP" should of course adopt the style, like it is already today in regards to the code style. Otherwise we can never get to the "future scope" of actually generating docs for browsing. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Unary null coalescing operator
On 6/21/2017 7:05 PM, Andrea Faulds wrote: > Hi all, > > Here's a small RFC for a small feature, which I've wondered about for a > while: https://wiki.php.net/rfc/unary_null_coalescing_operator > > What do you think of it? > > Thanks! I would prefer [1] to be extended to any and everything that can be null, like Kotlin, Ceylon, and others have it. Otherwise one needs to change back and forth between one and two question marks depending on context. The null coalesce operator is more of a special form of the ternary operator, but this proposal is a different beast and closer to nullable types than to the ternary operator. Hence, using a single question mark comes more natural. [1] https://wiki.php.net/rfc/nullsafe_calls -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Vote] Doxygen
On 6/21/2017 5:38 PM, Nikita Popov wrote: > Can you please clarify where functions that are declared in a header and > defined in a source file should be documented? I believe the usual > recommendation is to document in the source file, because it's closer to > the implementation and thus more likely to be updated. On the other hand, > documentation in headers only is more useful if you're just browsing code > and not using generated output. > > Nikita > The documentation should go into the header file. Source files actually must not have documentation, because everything in there is private anyways. Unless it is exported via a header file that is. Doxygen will automatically inherit the documentation (no @inheritDoc necessary), because it understands the C code in C mode. Documentation should never document what the implementation does, only how it can be used. This gets blurry if you implement a particular, standardized algorithm (like the UUIDs) where the actual implementation suddenly becomes an important part of information that should go into the documentation. In other words, refactoring and other changes in a functions body should not require changes of the documentation. A usage change usually directly translates to a breaking change. A situation in which many places require updates (e.g. CHANGELOG, NEWS, ...) and not something a dev should do without thinking about the implications of doing so. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Vote] Doxygen
On 6/21/2017 4:13 AM, Christopher Jones wrote: > > On 17/6/17 5:53 pm, Fleshgrinder wrote: >> Hi! >> >> I started voting on the Doxygen RFC: >> >> https://wiki.php.net/rfc/doxygen >> > Did I miss seeing when the vote ends? > > Chris > You did not, I forgot to mention it. The vote will close on July 1 at around 6 PM. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Vote] Doxygen
On 6/19/2017 2:31 PM, Jakub Zelenka wrote: > On Sat, Jun 17, 2017 at 8:53 AM, Fleshgrinder <p...@fleshgrinder.com> wrote: > >> Hi! >> >> I started voting on the Doxygen RFC: >> >> https://wiki.php.net/rfc/doxygen >> >> > I just wanted to send my feedback and the reason why I voted "yes". First > of all I don't really like adding too much documentation to the code (I'm > actually talking about the PR which seems really too much IMHO). However I > think that this RFC is more about having a standard for documenting > exported functions which would be really good in my opinion and I think > Doxygen is really good one (one can easily see that in Apache httpd for > example). I think that few lines is usually enough and sometimes it is > useful to have a note about the used parameters. What I want to say is that > we shouldn't think about the RFC as accepting the proposed PR. It should be > treated on case by case bases and over documented code should be still > rejected. > > Cheers > > Jakub > Thanks for the feedback, the intend of this RFC is exactly as you understood it. It's not a +1 for the linked PR. As I said to Nikic, whether a particular PR is acceptable or not must be part of a code review. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/3/2017 6:40 PM, Fleshgrinder wrote: > Next promised RFC (and the last one for this weekend): > > https://wiki.php.net/rfc/namespaces-in-core > > I am unsure about whether we should avoid the usage of abbreviations for > things like language (lang), standard (std), and utility (util). I think > it is not necessary to write them out fully, but, well, ...?!? > Bump! Voting could start tomorrow, but I would like to wait for the outcome of the class naming [1] RFC and update this one before going to vote. I also believe that there is actually still the need for further discussion here. @Nikita you are always quoted in this context. I would love to hear your feedback on the RFC. I still believe that I addressed your concerns, and actually agree with you. I hope that you understand the examples as, well, examples. @All I would still love some feedback on the open issues. I would also be happy if you have ideas how the RFC could be made clearer. I know that many want to see namespaces in core, this is a chance. Otherwise we need to wait at least six months before a new proposal can be voted on (see rule). [1] https://wiki.php.net/rfc/class-naming -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/3/2017 2:03 PM, Fleshgrinder wrote: > As previously announced, I would like to set an end to these discussions > in the community: > > https://wiki.php.net/rfc/class-naming > Last heads-up, voting will start tomorrow! -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Vote] Doxygen
Hi! I started voting on the Doxygen RFC: https://wiki.php.net/rfc/doxygen -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/15/2017 3:29 PM, Björn Larsson wrote:
> Seems like the constraints on this feature makes it hard to fly, i.e.
> 1. Not a hackish implementation
> 2. Non ambiguous syntax
> 3. Easy to parse & use syntax for the human
>
> HackLang then prioritised 2 & 3 making the end-users happy, but
> had to sacrifise a clean implementation. Any clue if this was a one-
> time effort once it was done or something with a lot of drawbacks
> in terms of maintenance, performance, evolution etc?
>
> r//Björn
>
On Reddit someone proposed the following syntax:
\() => echo 'Hello, World'
It is used by Haskell if I remember correctly and should not be
ambiguous since `(` is not allowed in names of classes or functions. It
actually aligns well with functions that are called with a
fully-qualified name (e.g. `\printf('')`).
Not sure if it would still require hacks though.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Extensions License
On 6/13/2017 8:23 AM, Remi Collet wrote: > Hi, > > All extensions in php-src are PHP 3.01 Licensed > (libs may, of course, have different license) > > Is there any strong rule about this ? > Or is it OK to have a BSD Licensed extension ? > > Context: see sodium PR > https://github.com/php/php-src/pull/2560 > > > IMHO, make sense to have only PHP Licensed ext. > > > > Remi > We also include GNU stuff: https://github.com/php/php-src/blob/6053987bc27e8dede37f437193a5cad448f99bce/ext/mbstring/libmbfl/LICENSE I cannot tell what implications this has, and do not want to make any judgment regarding this issue. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Doxygen
On 6/15/2017 11:33 AM, Nikita Popov wrote: > Hi, > > What makes me skeptical about this is the PR that started this discussion: > https://github.com/php/php-src/pull/2523/files > > Documentation sounds nice, but that is not the kind of documentation I > would like to see or find particularly useful. A useful way to document the > arginfo structure is to write some free-form explanation with an overall > example, and then describe the individual macros with one sentence each. > What we get instead is a 30 line doc comment for each macro, describing it > individually and repeating lots of information that is, of course, the same > for all arginfo macros. > > Done consequently, what we end up with is ~400 lines of documentation of > arginfo macros, documenting everything meticulously, but very redundantly > and not particularly usefully. To the contrary, it is noisy and requires > additional maintenance if anything ever changes or is added. > > Nikita > Hi! It is possible to group things and document them once with Doxygen. A feature Jefferson has pointed out (I was not aware of it). This is something that could be used to document variations of macros that are essentially doing the same (as in the PR you linked). Of course, parameter documentation becomes useless at that point, but it can be challenged if it is useful in the first place if the parameter name is chosen in a way that it explains itself sufficiently. But please note that the RFC is not about the "how to document", this is something that should be part of code reviews. It is about allowing it in the first place and agreeing on a standard way of doing it, that ultimately allows us to generate API documentation (future scope, not part of this RFC). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Doxygen
On 6/1/2017 9:04 PM, Fleshgrinder wrote: > Hey guys! > > Just finished the very brief Doxygen RFC. Please let me know if you > require more information in it, I feel that it is sufficient as is, > since documenting is not rocket science (writing useful documentation > definitely is, but we cannot vote on that): > > https://wiki.php.net/rfc/doxygen > I would like to start voting on this, unless someone has still an open question regarding this. @Jefferson would you like to extend the RFC before we start the vote? -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > Hi 'Fleshgrinder', > > I object to this RFC on principle. > > RFC's are supposed to be opionated. They are supposed to present an > argument for why we should do something, and why doing that is a good > idea. > > This RFC does not do that; it presents a series of questions to vote > on, without any clear presentation of what problem they are solving or > why people should be vote for the RFC. > > Asking people to vote on things like this, leads to choice being made > at random, when there may not even be a need to make a choice in the > first place. > > Introduce namespaces to user-level symbols to avoid collisions with > user defined symbols, decrease breaking changes due to the > introduction of new symbols and thus increase future compatibility. On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > These parts of the RFC are particularly lacking justification: >> Allow plural nouns in namespaces? Yes/No >> Use namespace for the language itself (in the future)? Yes/No >> Name of the language namespace? core/lang >> Use namespace for tiny self-encapsulated things (in the future)? Yes/No >> Name of that namespace? std/util > > In addition, there are problems with other parts of the RFC. > > An important question to answer, if namespaces are to be used by PHP, > is how they should be written. PHP has a long history of > inconsistency, it therefore makes sense to define this upfront to > ensure that any future effort is not going to introduce new > inconsistencies. > The vendor namespace itself does not contain any code directly, but > instead is split into multiple sub-namespaces. This should ensure that > we are not creating a new global namespace where everything that > cannot be categorized ends up in. > Std or util — for tiny self-contained types (e.g. > InvalidArgumentException) and functionality where it would be total > overkill to create a dedicated namespace for (e.g. UUID). On 6/11/2017 1:08 AM, Dan Ackroyd wrote: >> Coding Standard? snake_case/PascalCase > Shouldn't this be part of the other RFC? > > There are two possible choices: > > 1. snake_case > 2. PascalCase (in accordance with class naming) > > Arguments for both approaches exist, however, it is after all a purely > cosmetic question: On 6/11/2017 1:08 AM, Dan Ackroyd wrote: >> This could help to avoid those 1,000+ LOC files > Splitting files to only contain related things is a good idea. > Splitting related things into separate files, just because some > arbitrary line limit has been reached, is not. > Splitting files to related things is exactly what this RFC is about. Nowhere does it state that files must be split by a line limit. On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > > From the RFC: >> Introduce namespaces to user-level symbols to avoid collisions with user >> defined symbols >> >> Use namespace for the language itself (in the future)? Yes/No >> > > From email, Fleshgrinder wrote: >> I personally do not like this approach. PHP is the vendor of these >> things, thus, it should reside in the namespace of the vendor. Same >> rules for everyone. > > If this is actually problem, a better solution might be just reserve > the global namespace in addition to the 'PHP' namespace. However the > RFC does not say why it is a problem that needs addressing, and so we > cannot explore possible solutions. > > Introduce namespaces to user-level symbols to avoid collisions with > user defined symbols, decrease breaking changes due to the > introduction of new symbols and thus increase future compatibility. Reserving the global namespace now cannot achieve this, because it is already in use by millions of projects out there. On 6/11/2017 1:08 AM, Dan Ackroyd wrote: > Multiple people have given you feedback that your idea of using a top > level 'PHP' vendor namespace isn't a good match for the project. > Rather than rephrasing what they have already said, I will just remind > you of an earlier reply: > > From http://news.php.net/php.internals/98225 > On 2/6/2017 9:47 PM, Nikita Popov wrote: >> >> I'm strongly against use of the PHP namespace as a blanket namespace >> for bundled PHP extensions. The PHP namespace should be used only >> for functionality that is actually in some way related to PHP. For >> example, the php-ast extension could reasonably be namespaced as >> php\ast, as it provides an AST for PHP specifically. Similarly the >> tokenizer extension could reasonably be namespaced as php\tokenizer. >> >> Extensions which are not of this type should not live in the PHP >> namespace, because they don't have anything specifically to d
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/11/2017 12:35 AM, Dan Ackroyd wrote: > On 10 June 2017 at 21:57, Fleshgrinder <p...@fleshgrinder.com> wrote: >> >> This RFC is only > > "When collaborating with others – especially when designers and > programmers are part of the mix – watch out for these dirty four > letter words: Need Must Can’t Easy Just Only Fast" > https://signalvnoise.com/posts/439-four-letter-words > > It's actually setting a rule for a project, that has gone 23 years > without needing that rule, which doesn't sound completely trivial. > It is a clarification of an existing rule. A rule that already exists for 16 years. On 6/11/2017 12:35 AM, Dan Ackroyd wrote: >> Hence, one week seems sensible. > > It doesn't seem sensible to me. > > The minimum discussion period is for when there is an urgent problem > that ought to be addressed but there is disagreement about the best > way to resolve it. > The existing rules are pretty explicit about their intend and applicability. Not sure where this is coming from. On 6/11/2017 12:35 AM, Dan Ackroyd wrote: > We should be taking longer periods to think about committing to coding > standards, rather than just the bare minimum. > Here I agree in general, but the RFC's question is trivial and its choices are obvious. That is why I believe that it does not require much though. On 6/11/2017 12:35 AM, Dan Ackroyd wrote: > People (in general) have better things to do than read internals. Some > of the discussions over the past couple of weeks have been even more > demotivating than usual, which is probably one of the reasons why > people haven't responded yet. > >> We can of course wait if there is a serious issue. > > We can of course wait anyway. > > This RFC isn't going to affect 7.2, so the first release it will > affect is 7.3 - so we could wait 12 months to vote before it became > critical. > > cheers > Dan > Seems like people have serious issues, so let's wait. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/10/2017 11:11 PM, Levi Morrison wrote: > You put out namespaces for them which implies you think we might do that. > Erm ... not really ... I am sorry if my examples lead to a confusion on your side. Let's try this the other way around. What are *other extensions* for you? -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/10/2017 10:54 PM, Niklas Keller wrote: > The minimum discussion period is two weeks. > > Regards, Niklas Not according to our rules, no: > There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is > required. Other RFCs might use a smaller timeframe, but it should be > at least a week. > > --- https://wiki.php.net/rfc/voting#discussion_period This RFC is only about a tiny extension of the coding standards, no other change to PHP is proposed. Hence, one week seems sensible. We can of course wait if there is a serious issue. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/10/2017 9:24 PM, Levi Morrison wrote: > If we were starting from scratch maybe we'd do as you are proposing. > However, there is absolutely zero value in these specific things being > namespaced *anywhere*: > > - Arrays > - Reflection > - Strings > - IO > > We already have established conventions and prefixes around these. > Moving them to a namespace has zero value. > > I'm not sure what logging you are talking about for PHP. > > That leaves UUID, which I am fine with having its own namespace if > there are enough functions, constants, classes, etc to support it. > These are examples!?! I see no reason to limit our thoughts and imagination here. This is a proposal for the future of PHP, for whatever might come. Limiting us seems more than counterproductive to me. Array, Bool, Int, Float, String, ... all of them are valid things to think about. Not only as an intellectual game, but also in the light of _scalar objects_ [1]. [1] https://github.com/nikic/scalar_objects PS: Moving of anything that already exists was never mentioned, implied, or part of the proposal. This is something Levi just brought up and I want to repudiate myself in the strongest terms from moving anything! -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/10/2017 8:54 PM, Levi Morrison wrote: > I gave this feedback before but I'll repeat it. I support namespaces > in the core, with the `PHP` namespace (with whatever capitalization we > decide) to be reserved *solely* for things related to the language > itself such as lexer, parser, etc. > > I am fine with other extensions using namespaces but should use > appropriately named ones. Using the `PHP` namespace to indicate > something is packaged in core is a poor decision. We have moved > existing extensions into core and it would not make sense to rename it > simply because it was moved into core because it's a backwards > compatibility break. Similarly we've moved at least one extension out > of core and it doesn't make sense for it to have the `PHP` name when > it's not in core, but renaming it is yet other backwards compatibility > break. It's simply not prudent. Instead extensions should be named > after what they are, the vendor they are for, or some other name; this > is the same process user-land packages go through and core should not > be different. > Thanks for that, much appreciated. This is exactly what I am proposing. Only things that are provided directly from the PHP Group should go into the PHP namespace. Any- and everything else should go into appropriate vendor namespaces. I think that you are considering e.g. array functions as not being part of PHP, and that you want to put them in a separate namespace. So effectively we would have something like: PHP\Lexer Arrays\Array IO\File Logging\Logger Reflection\Reflector Strings\String UUIDs\UUID I personally do not like this approach. PHP is the vendor of these things, thus, it should reside in the namespace of the vendor. Same rules for everyone. IO for instance is not a vendor, it is a particular use-case (working with files) and thus should not go directly into the global namespace. There is imho no reason to move `PHP\Reflection\Reflector` to `Reflection\Reflector` just because we decided, for whatever reason, to remove reflection from core and instead providing it via PECL. PHP would still be the vendor of it. The misconception that I am seeing is, that the PHP namespace is bound to PHP, which it isn't: it is the vendor namespace of the PHP Group. The PHP community at large has settled with this approach, and I believe that it is a very good approach. It effectively avoids namespace collisions and helps to identify the vendor of a particular implementation. Would love to hear what others think about this. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/3/2017 2:03 PM, Fleshgrinder wrote: > As previously announced, I would like to set an end to these discussions > in the community: > > https://wiki.php.net/rfc/class-naming > I am planning to put this to vote tomorrow, unless somebody has serious concerns and raises them here. The minimum discussion time of one week has passed, and this RFC has no impact on the language itself. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Namespaces in Core
On 6/3/2017 6:40 PM, Fleshgrinder wrote: > Next promised RFC (and the last one for this weekend): > > https://wiki.php.net/rfc/namespaces-in-core > > I am unsure about whether we should avoid the usage of abbreviations for > things like language (lang), standard (std), and utility (util). I think > it is not necessary to write them out fully, but, well, ...?!? > Bump, would love some feedback on the RFC and the open issues. Otherwise this goes into voting and lots of complains pop up. It would be much more efficient to use the discussion time for that. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/8/2017 6:28 PM, Rasmus Schultz wrote: >> it could be a single symbol instead of two > > even if this can be done without parser ambiguity, it suffers from visual > ambiguity with the assignment operator. > > consider what this would look like if the expression itself uses the > assignment operator... > > f($x) = $y = $y + $x; > > versus something like: > > f($x) => $y = $y + $x; > > even that is visually ambiguous when used in arrays though: > > $a = [ > "foo" => f($x) => $y = $y + $x, > ]; > > also unreadable. > > even if the parser can cope, I think we need some other symbol that isn't > visually ambiguous when used in these contexts? > Absolutely, yes. One thing that could work is a combination of colon and equal sign with an optional type in between: f($x, &$y):= $y = $y + $x f($x, &$y): int = $y = $y + $x Still, kind of ambiguous if used with a type. Earlier I used the greater than sign only: f($x, $y)> $x > $y f($x, $y): bool > $x > $y As we can clearly see, also not optimal. A thing that should work is a hyphen greater than: f(object $o)->$o->property Looks weird without proper spacing, but with proper spacing ... f(object $o) -> $o->property ... it looks fine, imho. Of course, we still have the other options that were mentioned earlier already: f ~> 42 // bad on some keyboard layouts f ==> 42 // I personally do not like this option Another possibility is to use a keyword. This would definitely avoid symbol soup and help visual recognition: f do 42 f($x) do $x^3 f($x, &$y) do $y = $y + $x However, I am very unsure about this option to be honest. I'd say my choice here is `~>` but I'm on a US layout, second is `->`. Note that the latter is used in Java, Elixier, Erlang, Haskell, Julia, OCaml, F#, and probably others. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/7/2017 9:45 PM, Rasmus Schultz wrote: >> the `fn($a, $b) => $a + $b ** $c` syntax suddenly becomes an acceptable > compromise. > > I have to second that. > > I might even propose to shorten it from "fn" to just "f" - the resulting > syntax then resembles a mathematical predicate :-) > I really like your thinking here. +1 for just `f`. I am not sure why we would require the fat arrow anymore. We most probably want some symbol there to separate the return type constraint from the body, but it could be a single symbol instead of two: f($x) = $x^3 f(int $x): int = $x^3 We could go full math here! :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Basic string comparison functions still use old parameter parsing API
On 6/7/2017 7:15 PM, Benjamin Coutu wrote: > Hi Dmitry, > > I just noticed that all basic string comparison functions in > Zend/zend_builtin_functions.c, especially "strcmp", "strncmp", > "strcasecmp", "strncasecmp" still use the old and inefficient > parameter parsing API, unlike similar functions in > ext/standard/string.c such as "substr_compare", "strtok", > "str(i)str", "str(i)pos", "strr(i)pos", "strrchr" that already > consistently use the new efficient macro-based API. > > I think one can consider "str(n)cmp" and "str(n)casecmp", etc. at > least as important as "substr_compare", especially considering that > these are wrappers around very basic functions that often get called > in very hot code or inside tight loops (e.g. sorting). I therefore > recommend changing those 4 functions in Zend/zend_builtin_functions.c > to use ZEND_PARSE_PARAMETERS_* macros for PHP 7.2. > > What do you think? > Help? :) https://github.com/php/php-src/pull/2565 -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index
On 6/7/2017 8:23 PM, Pedro Magalhães wrote: > I will not change the target version now during the voting phase. Also > because it wouldn't make sense to vote for a feature for 8.0 yet. If the > RFC is rejected and the sentiment is that most people would agree with the > change but not with the timing, I will propose it again when RFCs for 8.0 > are relevant. > > Thanks, > Pedro > It does not loose relevance just because the implementation is postponed. On the contrary, we could directly start advertising that change, which is super useful to the PHP ecosystem because they can prepare their code for the change. The change you are proposing is absolutely necessary, and it is a great initiative of yours! :) However, the possibility of introducing this kind of change in a minor is dangerous. I am usually against almost all of these changes, but in favor of deprecation to fix more of these unexpected features. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
I agree with Nikita and Sara here, interfacing between PHP and C however would be very important. My current UUID proposal for instance. Doing the bit shifting in PHP is a pain. Doing it in C is a breeze. However, doing the signatures and accessors in PHP would be MUCH simpler. On 6/6/2017 2:43 PM, Nikita Popov wrote: > There are essentially only two good reasons for implementing functionality > in C: One is performance, the other is FFI. Unfortunately, the requirement > to use C for everything inside an extension means that we write a large > amounts of C code that does not fall into either of those categories. The > resulting code is hard to maintain, often subtly buggy and usually not > consistent with ordinary userland PHP code. Typical issues we see all the > time are bad or completely absent serialization support, lack of circular > garbage collection, crashes when the object is improperly initialized and > bugs appearing when internal classes are extended. I think that one of the main reasons for this is that lots of the C code implements this stuff again, custom made. Instead of just using the default stuff. Regarding the maintainer problem. PHP internals is a very hard turf and literally has a very bad reputation out there. It is very hard to get in, and it is very hard to contribute. Other communities (Go, Rust, ...) are much more welcoming. I think that the move to GitHub already helped a little, but it needs to open up even more. Internals needs to encourage, support, guide, and not simply turn down every idea. The internals book goes in the right direction here. Going more community with stuff like the mailing list (maybe a forum that is easier to join) and a chat (maybe something like gitter) are only tiny things that can help a lot here. We can learn from the other communities. I think that there are more than enough people out there who would be able to write some C. On 6/6/2017 5:55 PM, Sara Golemon wrote: > 100% this, though PHP's version of HNI will suffer a few shortcomings > due to the lack of a type_traits equivalent in C99. I'm not > suggesting we go C++11 just to get a better bridge, but it's a real > constraint in getting the same advantages that HNI has. Upgrading to C99 is imho long overdue! No clue why we are not finally doing the switch. I'd rather invest in Rust than C++11, seriously. C++ (regardless of version) is as painful as C after all. Sure, RAII solves all problems, but than we could also do Python instead of PHP if conventions is all we ask for. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/6/2017 6:38 AM, Stephen Reay wrote:
> As someone who sees limited appeal in short closures (Ok, they may
> make for slightly simpler constructs that are slightly too complex
> for a regular “collect” type collection method), I see a *lot* of
> people spending a *lot* of time to save typing 8 characters
> (function).
>
> If this feature truly is about making it easier to read, then that
> should be your goal: make it easy to mentally parse, basically
> instantly. Given that even proponents of the approach are admitting
> the syntax can get quite hard to understand quickly, perhaps it’s
> time to accept that “more characters” !== “harder to read &
> understand” and importantly, “less characters” !== “easier to read &
> understand”.
>
> How long does it take someone to type function? A second, maybe two?
> How many times are other people going to read that, once it’s been
> written?
>
I can only agree once more. PHP is verbose, PHP always was verbose, PHP
should stay verbose. Not to say that short closures are bad, but
searching for the perfect symbol soup seems wrong. We could easily
create a syntax that is totally unambiguous and easy on the parser
without lots of look-ahead with a new keyword.
fn> 42
fn($a, $b)> $a + $b
fn($a) (&$b)> $b += $a
$a = [fn()> 42];
usort($data, fn(T $a, T $b):int> $a <=> $b);
Our (simplified) production rule would be (where brackets denote optional):
"fn" [ (" [P] ")" ] [ "(" U ")" ] [ ":" T ] ">" E
P := param list
U := use list
T := return type
E := expression (to return the result of)
This would also ensure that nobody can use it for more complicated
expression, since we are not supporting braces. Anything complex should
continue to use the long closure notation, as it is more readable.
Extending this for usage with methods would also be quite easy. In that
case we can even drop the keyword (methods require a name anyways):
final class SomeEnum {
// ...
public static Foo(): self > new static('foo');
public static Bar(): self > new static('bar');
}
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
On 6/5/2017 7:46 PM, François Laupretre wrote: > So, please give me your thoughts. Suggestions of potential candidates to > be rewritten from C to PHP are welcome too. > > Regards > > François > Hi François! I really, really like this. It would allow us to write most of the stuff in PHP, especially the reflection part, while delegating to C where appropriate. I skimmed through the documentation of yours. There is however one question left. Is it possible to have C code that is accessible only to the PHP code of an extensions, instead of all user-level code? Some things are simply easier in C than in PHP (binary). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/5/2017 9:03 PM, Ryan Pallas wrote: > However, ($obj) -> $var is valid variable property syntax. > Gosh, we really have support for everything. :D That one is even very important for stuff like `(new A)->f()`. How about ~> which I at least cannot think of any place it is used at all. ~ in binary negation and the only place we use it (I checked the language parser this time to make sure). I really dislike the ==> idea. One of the main reasons here is to write less and it looks too much like => or even >= which I really don't like. ($a, $b) ==> $a >= $b ($a, $b) ~> $a >= $b -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [RFC] [Discussion] Doxygen
Hey Jefferson! On 6/5/2017 8:40 PM, Jefferson Gonzalez wrote: > First, thanks for taking the initiative to do this! > :) On 6/5/2017 8:40 PM, Jefferson Gonzalez wrote: > Second, the rfc doesn't touch the ability of grouping that doxygen > provides which could be really useful in order to navigate the > documentation more easily. For example: grouping functions related to > the manipulation of zvals in groups like: Objects, Strings, Numbers, > etc... More about this: > http://www.stack.nl/~dimitri/doxygen/manual/grouping.html > and this is some example of how it may look like: > http://docs.wxwidgets.org/trunk/modules.html > Do you have Wiki access? You could explain this feature there. Or maybe send me a write-up directly and I add it. :) On 6/5/2017 8:40 PM, Jefferson Gonzalez wrote: > Third, maybe you can add 2 vote choices in which to document the source > code in case one is favored more than another. One to document the core > directly and another method using the interface directory that I > mentioned in my previous e-mail. > The problem I have with this approach is that we have to maintain two header files. One is already total overkill in my book (luckily other languages have learned from this). On 6/5/2017 8:40 PM, Jefferson Gonzalez wrote: > Finally, you mentioned on the RFC that I didn't got any support which > could sound harsh... but what I wrote on the e-mail was that I lost > motivation due to my day/night job, that was the real reason I did not > continued the work with it. > I actually wanted it to sound dramatic, but will change it to the real reason. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were required, it's not ambiguous with the
> trailing -- operator, is it?
>
> $foo->bar(($baz) -> $baz + 1);
>
> Consistent use of parens around the params might make closures a bit easier
> to spot in the wild?
>
This would actually work with everything, me likes.
() -> 42
($a, $b) -> $a + $b
($a) (&$b) -> $b += $a
public static Foo() -> new static('Foo');
It also avoid any association with
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/5/2017 7:55 PM, Rowan Collins wrote:
> I think it's not just a case of implementation problems, it's actually
> ambiguous with current syntax:
>
> $foo = array( ($x) => 42 );
>
> Sure, those inner brackets are redundant, so it's not likely to break much
> actual code, but it's kind of weird to have this one case magically turn into
> a closure, when anything else you put in those brackets would just be used as
> the array key:
>
> $foo = array( f($x) => 42 );
> $foo = array( ($x+1) => 42 );
> $foo = array( (42) => $x );
> $foo = array( (X) => 42 );
> $foo = array( ($x) => 42 );
> $foo = array( ("$x") => 42 );
>
> Even if we could teach the parser to understand it, I'd personally be against
> it for the difficulty of *humans* parsing it. I find shorthand closures hard
> enough to read anyway, especially when people suggest things like ($x) =>
> ($y) => $x * $y * $z;
>
> Regards,
>
Ah thanks, yeah, that was the problem.
At trivago we have such a super fancy ES6 code base where everything is
done in a super cryptic syntax, so that absolutely nobody who is not
used to reading this all day has a chance to understand a single thing.
So, yeah, I completely agree with you on everything.
That being said, they are handy if not overused, like so many features. :)
The pipes should still be in the game.
$foo = array( |$x| => 42 );
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
On 6/5/2017 6:17 PM, Larry Garfield wrote:
> 3 > 4 > 1.
>
> 2 is not even worth considering and I'd almost prefer not having arrow
> functions if their syntax is going to be that self-defeating.
>
> I also see no reason to include both by-value and by-reference binding
> Arrow functions are for trivially simple cases where the extra ceremony
> of an anonymous function is a waste. If you need to do something
> non-trivial, use a full-on anonymous function as we already support.
>
> I want to reiterate that, from a user-POV, arrow functions are barely
> functions. It's a case for applying an expression to a set. In most
> cases I don't "think about it" as a function in the first place.
>
> $y = 2;
> array_map($arr, ($x)=> $x*$y);
>
> While I know that implementation-wise $x * 2 gets wrapped into a
> function, that's not really how I'm mentally thinking about it. I'm
> thinking of it more like a single line in a foreach. In my head, it's
> an expression, not a function. If I needed to be "thinking about it
> like a function", I'd use a more function-esque syntax.
>
> The extra complication of multiple binding styles to think about are
> just that: extra complication. If I care, then I should be using an
> anonymous function whose use() syntax already lets me control that case.
>
> I wonder if "Arrow functions" is even a misleading name for the feature,
> in terms of how it should be used.
>
> --Larry Garfield
>
I agree with Larry here. Another thing that would be great to have is a
universal syntax that we can expand to cover methods at a later point
too. Ceylon has that available everywhere, and it is nice for writing
simple methods.
final class SomeEnum {
private $v;
private __construct(string $v) => $this->v = $v;
public static Foo() => new static('FOO');
public static Bar() => new static('BAR');
}
Could someone explain me again what the problem with the simple
fat-arrow and normal parenthesis is? Cannot find it anymore (too many
messages in too many thread I guess). I would guess that it has to do
with the arbitrary look-ahead that is required to check for the fat
arrow before the lexer knows that this is a short closure and not some
parenthesis that simply groups something. Wouldn't it be possible to go
for the pipes then? I mean, pipes without an expression to the left are
not valid right now, and they most probably will never be. Union types
might require them, but they are not lonely there too. Hence:
|| 42
function () { return 42; }
|$a, $b| $a + $b
function () { return $a + $b; }
References and use should be easy to add:
|$a| |&$b| $b += $a
function ($a) use (&$b) { return ($b += $a); }
This syntax does not translate nicely to method though:
public static Foo|| new static('FOO');
Looks kind 'a weird and now we have something on the lhs of the pipes
that looks very much like a union type. We could still go for the fat
arrow syntax here, even if the pipes are used for short closures. The
two features are not the same after all.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Discussion] Namespaces in Core
Next promised RFC (and the last one for this weekend): https://wiki.php.net/rfc/namespaces-in-core I am unsure about whether we should avoid the usage of abbreviations for things like language (lang), standard (std), and utility (util). I think it is not necessary to write them out fully, but, well, ...?!? -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/3/2017 4:07 PM, Rowan Collins wrote: > Hi Richard, > > I think 3-way votes are potentially confusing, and saying it's a > "simple 50%+1 majority vote" doesn't really make sense if it's not a > yes/no question. > > What if the vote splits 49/48/3? Does "do nothing" win because the > other options didn't pass the winning post, even though some people > would actually be happy with either option? I don't think there are > many people who would rank the options as A > neither > B in this > case. > > Perhaps it would be better to separate the vote in two: - Should > coding standard be changed? Yes / No, 50%+1 required for change - > Which style should be used if change is accepted? A / B, highest > total wins regardless of proportion. > > Regards, > You are completely right, this makes no sense as it stands. Changed to how you propose it, as it is the only thing that actually makes sense. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] Class Naming
On 6/3/2017 3:20 PM, Dan Ackroyd wrote: > On 3 June 2017 at 13:03, Fleshgrinder <p...@fleshgrinder.com> wrote: >> https://wiki.php.net/rfc/class-naming > > For the RFC to be precise, it probably needs to specify the rules for > initialisations explicitly. > > Presumably the same as acronyms? > > cheers > Dan > Thanks, I updated the RFC and PRs accordingly. Acronyms and initialisms are basically the same thing, the differentiation is only important for spoken language. Still good to cover right away, so very good catch! I also added a special case with Radar to the examples. Some acronyms are not all-upper in their standard notation, hence, they should't be in our code. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Discussion] Class Naming
As previously announced, I would like to set an end to these discussions in the community: https://wiki.php.net/rfc/class-naming -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Class Naming in Core
On 6/2/2017 11:47 AM, Dan Ackroyd wrote: > On 29 May 2017 at 23:13, Fleshgrinder <p...@fleshgrinder.com> wrote: >> Hey guys! >> >> People are complaining over at Reddit [1] > > While the "STD" is slightly humorous, it is unneeded verbosity, and > will lead to pointless arguments in the future of whether other > features in the future should catch the STD name, or whether they > should be directly under PHP. I would recommend not using it. > > I don't care about case, though there may be a slight argument that > upper-casing initialisations is the 'standard' in PHP core. > > cheers > Dan > > > [1] - situation is nominal > The whole ext/standard (PHP\Std) namespace thingy will be part of a separate RFC, this is only about the casing and there will be three choices available to accommodate everyone. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] [RFC] [Discussion] Doxygen
Hey guys! Just finished the very brief Doxygen RFC. Please let me know if you require more information in it, I feel that it is sufficient as is, since documenting is not rocket science (writing useful documentation definitely is, but we cannot vote on that): https://wiki.php.net/rfc/doxygen -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Documentation (Doxygen)
On 5/30/2017 9:26 PM, Stanislav Malyshev wrote: > Hi! > > Sorry if it sounded that way, I of course meant nothing like it. I just > meant that introducing docs standard should not be made in a routine > unrelated patch, where it could be missed by many people, but as an > ordered process. Otherwise, you'd introduce Doxygen, somebody unaware of > it would introduce another thing, and pretty soon we have code > documented in a dozen of incompatible ways and it's a mess. I certainly > did not imply any malice on your part, just that we need to do it in an > explicit way that informs everybody what it happening. > >> used to properly documenting my code, as it is part of any professional >> code base in my opinion. > > Surely, and it's without doubt a good thing. We just need to do it > right, otherwise we'd have to spend more time later to fix it. It > requires a bit of time, but better spend it now than end up with code > documented in a way that no doc system would be able to parse, IMO. > No offense taken. :) I totally agree with you in all of this. Writing an RFC for every tiny thing is a lot of work, but it is the correct way of doing things, so I'll sit down and do exactly that. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Documentation (Doxygen)
Hey Jefferson! On 5/30/2017 2:04 AM, Jefferson Gonzalez wrote: > Hi, > > It seems that five years ago I was chatting on the php.internals irc and > I was asking wether documenting the source code with doxygen was > something that it could be worked on, but it seems that most core > developers where against having lots of code comments on the engine > code. So I suggested the idea of taking out the include files and > prepare them as interface files that could be documented separately. One > of the core contributors, (which I don't remember right now) said that > if done well they could accept it. > > The idea was to add another directory on the source tree of php named > 'interface' this directory would have three subdirectories: Zend, TSRM > and main which at the same time would contain stripped down copies of > the include files with only the declarations of functions, constants, > typedef, etc... so that they could be documented freely using doxygen > flavored comments. Ofcourse, this interface files would need to be > manually maintained, but the result would be documentation that anybody > can read to understand the core better and contribute to it. > > I started a repo (five years ago X_X) https://github.com/jgmdev/phoxygen > to try and document the php source code with doxygen and put a simple > Doxyfile that would generate documentation, unfortunately I lost the > time/motivation due to my day/night job. > > An inspiration was the wxWidgets project which is doing the same to > document the project without filling the main codebase with lots of > comments. You can take a look here: > https://github.com/wxWidgets/wxWidgets/tree/master/interface, also check > the output documentation generated with doxygen: > http://docs.wxwidgets.org/3.0/ > > In any case when I was coding the php wxWidgets wrapper (wxPHP) I > struggled a lot to understand the php core while trying to put up a 1:1 > wrapper of wxWidgets that contains hundreds of classes, and I needed > good core documentation since I didn't have lots of time to fully read > and understand the whole PHP core source code. > > So IMHO an initiative of documenting the core this way has its merits. > Nice to see that I'm not the only who thinks that proper documentation is a good thing. I already mentioned that it is not super important to me personally to actually generate the docs from the code base. However, there is also nothing bad about doing so. Outsiders or especially PHP users might be very interested in us doing so. That being said, what exactly are the arguments for that interface directory? Why not simply keep the code as is and document it. Saying that proper documentation is code pollution is like saying every successful PHP project is crap, because they are properly documented (or Java, or Rust, or Boost, or C#, or ...). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Documentation (Doxygen)
Hey Stas! On 5/30/2017 12:50 AM, Stanislav Malyshev wrote: > Hi! > >> I used Doxygen in both PRs to document the code. Right now the code base >> is lacking a lot of documentation, which, if done right, would greatly >> improve accessibility of the code base. > > Well, the problem as I understand it is that we don't have Doxygen setup > for docs generation. So, adding docs in Doxygen format is not very > useful, until we get some Doxygen setup. > > If we don't get one, then I think it's better to use format that is > either completely generic (no special tags, etc.) or matching existing > usage. > > Or make an RFC to establish docs standard, be it Doxygen or anything > else. Which of course would include some plan on how to deploy that system. > Not sure if it is really so important to actually generate the doc. It is imho more important to have documentation in the first place. The problem with no format is simply that it is not easy to document things consistently. For instance input/output parameters, return values, where else to look at, examples, etc. I am documentation all of my PHP code, everywhere, but never generate any API docs for it. Just having the documentation as part of the code is sufficient in 99% of all cases. A simple [Ctrl]+[Q] or hovering with the mouse will bring it up, that's what I care about. ;) On 5/30/2017 12:50 AM, Stanislav Malyshev wrote: > But randomly introducing docs system without any explicit decision in an > unrelated patch doesn't look like a good idea to me. > Wow! This sounds like you think that I am trying to deliberately sabotaging the PHP project. Quite the opposite is the case. I am simply used to properly documenting my code, as it is part of any professional code base in my opinion. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: Class Naming in Core
@Tony: exactly what Rowan said. We will not change a single line of code, and nobody will be forced to do anything. **UNLESS** the code is meant to become part of the core of PHP. In that case it must follow the rules, the rules that are part of the coding standard. It is fine if you change your coding style in every file in your project where you are the only person working on. However, we are a team if changing members, and having a consistent code style helps newcomers to get into the code base. It, hopefully, helps future maintainers to cope better with the legacy code we are producing every day. Feel free to disagree with this, but this is reality here, and these kind of policies are established as part of any professional code base in the world. On 5/30/2017 3:58 PM, Derick Rethans wrote: > It is also really irrelevant, as function and class names are > case-insensitve. > > cheers, > Derick > It matters to a lot of people, and that is why it should matter for us. We are leaders of an unbelievably huge community and we must address their concerns. Sometimes those concerns are complete bullshit, in that case we can and should ignore them, but in this case we actually already have a policy, it is just incomplete and I am asking to complete it. ;) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Class Naming in Core
Hey Stas! On 5/30/2017 1:00 AM, Stanislav Malyshev wrote: > Hi! > >> People are complaining over at Reddit [1] > > Isn't it what Reddit is for? ;) > I guess it is. ;) >> I know that this is probably a topic nobody cares much about, at least >> we did not end up in this kind of bikeshedding in the UUID discussion >> thread, but it is after all an important question when designing a language. > > I personally don't think it is a very important decision, since nothing > much would change either way, but my preference would be: > > 1. If there's an established acronym, keep it (GMP, DOM, XML, HTTP). > 2. If it's just words, use CamelCase. > > Second preference is all CamelCase, treating acronyms as a single word > (e.g. RpcOverHttpsViaXml). > Exactly how I see it. I am only asking to decide on one of both and put it into our coding standard so people who keep on complaining can be pointed there, and we're done. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Documentation (Doxygen)
On 5/24/2017 12:33 PM, Fleshgrinder wrote: > Hey internals! > > Nikic recommended that we discuss this topic before my latest PRs can be > merged. > > https://github.com/php/php-src/pull/2523 > https://github.com/php/php-src/pull/2535 > > I used Doxygen in both PRs to document the code. Right now the code base > is lacking a lot of documentation, which, if done right, would greatly > improve accessibility of the code base. > > The decision for Doxygen was not really a question of taste or anything, > it's just one I know very well for C. I am open to anything, as long as > we do something. > Bump, would be great to get some feedback here. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
[PHP-DEV] Class Naming in Core
Hey guys! People are complaining over at Reddit [1] about using PHP, Std, UUID, ... in other words about case. I know that this is probably a topic nobody cares much about, at least we did not end up in this kind of bikeshedding in the UUID discussion thread, but it is after all an important question when designing a language. Our coding standards are extremely unspecific about this kind of problem, the only thing that is written there is to avoid abbreviations, and acronyms are not mentioned at all: https://github.com/php/php-src/blob/master/CODING_STANDARDS#L154-L166 The question is, what would you guys want? The PHP community that follows the PSR rules is using PascalCase everywhere. The PHP core is inconsistent: - PascalCase: - Spl instead of SPL (Standard PHP Library) - Abbreviation/Acronym (Java style): - Intl - GMP - DOM - XML* I guess that already covers most of the stuff that is actually part of the core. This is also exactly why I chose to go for UUID and not Uuid. Personally I am fine with both, but we probably should extend the coding standards to create a source of truth, or otherwise people will continue to complain about this. [1] https://www.reddit.com/r/PHP/comments/6e24pr/rfc_phpstduuid_namespaced_in_core/ -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 5/26/2017 11:00 AM, Nikita Popov wrote:
> To clarify, I certainly do *not* want the behavior that was implemented
> here. The correct way (in your specific case) to handle this if by using
>
> if (zend_parse_parameters_throw(ZEND_NUM_ARGS(), "") == FAILURE) {
> return;
> }
>
> or adding a zend_parse_parameters_none_throw() API.
>
> Of course this should not throw a warning and of course it should not
> return NULL, because that would be inconsistent with how the other UUID
> methods behave. Of course it should not allow silently passing additional
> arguments, because that would be inconsistent with both how the other UUID
> methods (with at least one argument) behave and with how PHP in general
> behaves.
>
> Nikita
>
Thanks for the clarification. I changed the implementation to always
throw. This solves the issue for me. :)
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 5/26/2017 10:30 AM, Nikita Popov wrote: > Especially if it would allow us to replace a 4kloc diff with one 10loc > function. > > Nikita > I could remove the provided C API for other modules. Would make the header file empty and the implementation much shorter. Or at least remove those that are not of much interest (e.g. php_uuid_get_variant, php_uuid_get_version, php_uuid_is_nil). -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 5/26/2017 1:08 AM, Marco Pivetta wrote: > Saw the discussion on github, and I wish that the argument parsing just > behaved like a *NORMAL* PHP method. > > The following is perfectly valid: > > $crapTonOfUuids = array_map([UUID::class, 'v4'], range(0, 1000)); > > This would raise a lot of warnings if the API didn't behave like it does in > userland (warning on too many arguments). > A point was raised about BC compliance when adding parameters (future > scope), well here's the news: stop adding arguments to existing functions, > make some damn new functions/methods/classes (to whoever still thinks that > adding arguments is a valid decision). > Well, I agree on the adding arguments part. I actually complained a lot about this in the past. https://github.com/php/php-src/commit/49aed4fd75e9560444f63593b67fc4ed18e233c9#commitcomment-22277780 I added them because Kalle and Nikita really want to have them. Changing the return types to be nullable is a complete no-go for me. I am sure Larry would agree here with me. The approach I've taken right now would allow one to write: $crapTonOfUuids = @array_map([UUID::class, 'v4'], range(0, 1000)); As it would emit a warning, but still generate them. Well, unless you have strict-types mode activated, in that case you would receive the ArgumentCountError. I really don't know what the proper solution for this problem is. I would just leave it out, as I did initially. Nothing bad can happen from passing too many arguments; not enough should directly lead to an ArgumentCountError, that's for sure. On 5/26/2017 1:08 AM, Marco Pivetta wrote: > The UUID type and specification is simple and clear. > Also, a UUID is a data type with no real behavior. > The only possible and valid scenario for subclassing would be to add > semantic meaning because the developer invented a new type of UUID: that's > to be excluded, as such an implementation (if relevant and secure) would > land in core anyway in future PHP releases. > Subclassing to alter behavior (generation/serialisation, if you want to > call them "behavior") would be a mistake that could even lead to security > issues, and it should be avoided. > This class should be final, so keep it final, IMO. > > Marco Pivetta > +1 -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 5/25/2017 7:50 PM, Levi Morrison wrote: >> https://wiki.php.net/rfc/uuid#namespace >> >> This is more a general thing. I know from many online conversations, >> meetups, and conferences that people would love to see it. > > My $0.02 is basically what Nikita Popov has said at some point in the past: > > The PHP namespace should be reserved for things that are language > oriented, not stuff shipped by default by PHP. For instance a PHP AST > library would appropriately live in the PHP namespace. A UUID library > which has nothing to do with PHP except that's the language we are > using would not be appropriate there. > Added variations with that to the RFC: - Core\UUID - Lang\UUID - Standard\UUID - STD\UUID - UUIDs\UUID Although I have to say that it seems very weird to me. The conclusion that the PHP standard module does not belong to PHP makes no sense to me. I most definitely do not want that my username (vendor) would be used as a namespace in a core module (I also did not add that to the RFC). I am also very unsure if that is exactly what Nikita meant back then. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Parameter type widening RFC
On 5/25/2017 6:38 PM, Andrey Andreev wrote: > Sorry, but by "source" I didn't mean somebody state it here. :) > > When I said I don't claim to fully understand LSP, I didn't mean "tell > me what it is" - I'm familiar with it. What I don't understand is how > do we get from this: > >> Wikipedia: >> >> an object of type T may be substituted with any object of a subtype S > > > To this: > >> A single type may be substituted by any other type > > > Cheers, > Andrey. > Hey Andrey! Do not mix the LSP with type variance on arguments or return types. The LSP is targeting subtyping directly. The quoted sentence refers to the fact that S is not allowed to behave differently than T. I think you get a better understanding if you read the "A typical violation" part of the Wikipedia article. The problem we are dealing with is variance of method arguments (and return values). The corresponding Wikipedia article is here: https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) Specifically contravariant arguments: https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Contravariant_method_argument_type Hope this helps to clarify things. :) -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
On 5/25/2017 4:45 PM, Fleshgrinder wrote: > RFC is finished > > https://wiki.php.net/rfc/uuid > Would it be possible that we discuss the open issues, instead of trying to get rid of the proposal completely? I will not back up anyways after investing so much time. ;) https://wiki.php.net/rfc/uuid#argument_parsing The argument parsing is a huge problem together with return type constraints. Would love some feedback here from nikic. Even if this does not get included, the issue will pop-up with the next implementation that wants to use return type constraints. https://wiki.php.net/rfc/uuid#final_class I am not sure about the final class modifier. Would love some feedback here from Ocramius. https://wiki.php.net/rfc/uuid#namespace This is more a general thing. I know from many online conversations, meetups, and conferences that people would love to see it. https://wiki.php.net/rfc/uuid#doxygen_documentation I opened a separate thread for that, please answer there. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] [Discussion] UUID
RFC is finished https://wiki.php.net/rfc/uuid -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
