--
Richard "Fleshgrinder" Fussenegger
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hout 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 sup
e 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
ively 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" Fusse
at 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
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
l 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
On 12/29/2017 1:26 PM, Rowan Collins wrote:
> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder
> 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 automatic
u'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
s 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.
--
Rich
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 h
to` 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
-
.
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 "Fleshgr
ew (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
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 s
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)
--
Richar
ituation 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" Fussene
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
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 nam
e 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 meth
gt;
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
tioned 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
e 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
rol that real friend classes have.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
or 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
redoc_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
[1] https://wiki.php.net/rfc/uuid
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
n 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
-
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
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
te, 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
On 9/2/2017 2:26 PM, Zeev Suraski wrote:
>
>> On 2 Sep 2017, at 13:43, Fleshgrinder 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, ... eve
();
$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
oting 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
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&qu
On 8/20/2017 1:56 PM, Dan Ackroyd wrote:
> On 20 August 2017 at 11:45, Fleshgrinder 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.
>
>
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://g
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
es 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" Fu
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
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
ment();
> $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
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
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
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
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 o
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
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
erent 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
ody 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 "
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 d
On 6/19/2017 2:31 PM, Jakub Zelenka wrote:
> On Sat, Jun 17, 2017 at 8:53 AM, Fleshgrinder wrote:
>
>> Hi!
>>
>> I started voting on the Doxygen RFC:
>>
>> https://wiki.php.net/rfc/doxygen
>>
>>
> I just wanted to send my feedback and the reas
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
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
Hi!
I started voting on the Doxygen RFC:
https://wiki.php.net/rfc/doxygen
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
\() => 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
hat implications this has, and do not want to make any
judgment regarding this issue.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
ntly.
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
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
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.
>
&
On 6/11/2017 12:35 AM, Dan Ackroyd wrote:
> On 10 June 2017 at 21:57, Fleshgrinder 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
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
. We can
of course wait if there is a serious issue.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
ught up and I
want to repudiate myself in the strongest terms from moving anything!
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
P 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
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 he
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
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
o:
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
ght 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
or of deprecation to fix more of these unexpected features.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
st 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
e 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
ome things are simply easier in C than in PHP (binary).
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
>= $b
($a, $b) ~> $a >= $b
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
ivation 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
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 -
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
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
, well, ...?!?
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
ight, 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
On 6/3/2017 3:20 PM, Dan Ackroyd wrote:
> On 3 June 2017 at 13:03, Fleshgrinder 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 acr
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
On 6/2/2017 11:47 AM, Dan Ackroyd wrote:
> On 29 May 2017 at 23:13, Fleshgrinder 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
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
s 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
t 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
domly 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
s 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
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
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
://www.reddit.com/r/PHP/comments/6e24pr/rfc_phpstduuid_namespaced_in_core/
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
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 sol
move 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
es.
> 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
ot 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
/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
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
RFC is finished
https://wiki.php.net/rfc/uuid
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
1 - 100 of 471 matches
Mail list logo
