Providing additional functional tests for the PHP runtime
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nes,
Why can't this be done at autoloading time?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
e worries of mine, consider that mistakes like the
one with the `ValidatorInterface` may happen again in the future, and this
"PHPism" is actually saving our asses out there.
Don't get rid of it for the sake of clean code, because these "dirty hacks"
have already proven the
ort of additional cognitive load either.
In short, I stand firm on my "if you can implement it in userland, don't
implement it in the language" idea.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
o cut it here, as we all test our
stuff with E_ALL.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Hi Lester,
On 16 March 2015 at 08:04, Lester Caine wrote:
> On 16/03/15 00:16, Marco Pivetta wrote:
> > Syntactic sugar won't really make things easier when adopting the
> language,
> > and I don't like this sort of additional cognitive load either.
> >
> &
libraries using this trick) about this, for example:
>
> http://ocramius.github.io/blog/accessing-private-php-class-members-without-reflection/
>
Also note that this is the only way to access private properties by-ref
(yes, I do need that for my horrible use-cases. No, don't a
Absolutely +1 - most developers are dragged into using the PDO Oracle
driver by "hope" (since they find the docs), and then they get to know the
sad truth about it...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 22 April 2015 at 10:40, Stelian Mocan
be very efficient, as it saves us a method call for an
operation that really doesn't need one.
Systems that depend on `get_class()` a lot would benefit from such a
feature: see for example mapping caches in data mappers and handlers
matching in event handlers.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 27 April 2015 at 19:39, Rowan Collins wrote:
> Marco Pivetta wrote on 27/04/2015 18:25:
>
>> On 27 April 2015 at 16:35, Anthony Ferrara wrote:
>>
>> On Mon, Apr 27, 2015 at 7:18 AM, S.A.N wrote:
>>>
>>>> Now this code causes an error PH
ys get a string representation of what the fully
> qualified class name resolves to.
>
Hey Ralph,
Please refer to current behavior:
http://3v4l.org/3sgLa
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
tandard rather than these
> seeming to be subject to different interpretation all the time.
>
> This before addressing the problems of PHP7 migration ...
>
>
Please refer to https://github.com/php-fig/fig-standards/pull/169
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 13 July 2015 at 12:20, Lester Caine wrote:
> On 13/07/15 11:51, Marco Pivetta wrote:
> > Please refer to https://github.com/php-fig/fig-standards/pull/169
>
> This just adds another level of complication. FIG is not part of the
> core PHP standards, and some of their choice
On 13 July 2015 at 13:23, Lester Caine wrote:
> On 13/07/15 13:12, Marco Pivetta wrote:
> > It's actually the PhpDocumentor folks (and Mike van Riel in first place)
> > pushing forward PSR-5: there's nothing more "official" than that right
> now.
>
moved before going stable?
I also wasn't able to find any RFC information around it on
https://wiki.php.net/rfc#php_55 - is there any previous discussion around
this, or did it just sneak its way in?
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
e OO model basics by introducing a limitation in the interface, rather
than in the broken implementations.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
I should also add that this breaking change was introduced in a patch
release (5.5.8).
What has happened has happened, and I don't want to blame anyone, but this
is actually really broken :-\
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 21 July 2015 at 12:14,
On 21 July 2015 at 12:56, Derick Rethans wrote:
> On Tue, 21 Jul 2015, Marco Pivetta wrote:
>
> > I should also add that this breaking change was introduced in a patch
> > release (5.5.8).
>
> That wasn't good, but I don't see how it was a *breaking* change. It
;
> function dirname_n($path, $n) {
> while (($path !== '.') && $n--) $path = dirname($path);
> return $path;
> } <http://www.php.net/unsub.php>
>
>
Indeed.
What need is there to add a functionality to a relatively simple function
like this one?
What's
This sort of change would be a major BC break for 8.x or similar. I also
don't see security implications, tbh.
On Jul 28, 2015 18:41, "Stanislav Malyshev" wrote:
> Hi!
>
> > -1 on this. If there is no technical problem with serializing the
> > Exception class itself, it should be possible to seri
New BC breaks in Beta? Meh.
On Jul 28, 2015 22:44, "Rowan Collins" wrote:
> On 28 July 2015 21:34:06 BST, Marco Pivetta wrote:
> >This sort of change would be a major BC break for 8.x or similar.
>
> I think that was the point of trying to squeeze it into 7.0
>
>
eak. I'd
prefer a strict, well defined list of possible magic methods for the
various internal types. Would that be a big performance issue?
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 March 2012 14:38, Simon Schick wrote:
> Hi, all
>
> To
Thank you for clarifying some things :)
>4. Strict weak type hinting:
>
> This realm is the most likely to succeed because the core already does
> something like this for internal functions (via zend_parse_parameters).
> This balances utility (enforcing the type) with fundamental language des
@Stefan: travis could be setup to build PHP and check your branches on your
own fork whenever you push... That would reduce some of the overhead
hopefully.
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 18 March 2012 19:14, Stefan Marr wrote:
> Hi David:
>
&
there's no conflicts...
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 14 April 2012 21:50, Ralph Schindler wrote:
> Hi all,
>
> There are many different use cases were in code we expect classes names as
> arguments to functions as fully qualified nam
@Nicolas: wouldn't __CLASS__ introduce a bit of confusion with the existing
constant?
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 April 2012 11:17, Nikita Popov wrote:
> On Sat, Apr 14, 2012 at 9:50 PM, Ralph Schindler
> wrote:
> > Hi all,
responsible for those libraries, and that usually happens through IRC
networks.
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 12 July 2012 09:28, Ziad Jammal wrote:
> Deal all phpiers,
>
> It took me a while before I hit the send key.
> I have been a php
Well, being able to disable the fallback would allow developers to eagerly
discover features that are going to be dropped (and it doesn't need to be a
soft failure).
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 July 2012 16:14, Brandon Wamboldt wrote:
>
ing refactoring (at least
without freezing the project), that's part of our job.
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 25 August 2012 11:27, Ferenc Kovacs wrote:
> 2012.08.25. 11:16, "Lester Caine" ezt írta:
> >
> > Many of m
@Dmitry that looks more like a function call, while (IMO) it is more
intuitive to consider it like a static property...
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 13 September 2012 10:17, Dmitry Stogov wrote:
> Hi Ralph,
>
> I think the syntax is wired.
b.com/php/php-**src/pull/187<
> https://github.com/php/php-src/pull/187>
> >
> > Thanks,
> > Ralph
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
I don't think autoloading is needed here, since the FQCN can be resolved
without it (exactly like with type hinting).
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
reads about this failure, we (doctrine) can move
away from the `unserialize()` hack if
`ReflectionClass#newInstanceWithoutConstructor()` provides support for
internal classes.
It doesn't need to cover ALL internal classes, just the most commonly
extended ones.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
e
> values are expected.
Yes, that indeed.
What I am suggesting is to provide a small map of internal PHP classes that
are supported by `ReflectionClass#newInstanceWithoutConstructor()`, so that
their internal data can be initialized even if the userland constructor is
not invoked.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
master.
>
I don't know how things are driven here, but I assume that OSS projects
don't merge stuff into master until tests pass: it's as simple as that.
That's your blocker right there, regardless of voting or any other
discussion going on.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ontinuous feedback as well.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 3 August 2014 23:50, Andrea Faulds wrote:
> Good evening,
>
> I am proposing two new RFCs. As they are both inter-related and
> complementary, with the second having the first as a prerequisite, I’m
> making just a single email to cover both:
>
> https://wiki.php.net/rfc/closure_apply
> https:
On 4 August 2014 14:11, Andrea Faulds wrote:
> On 4 Aug 2014, at 12:36, Marco Pivetta wrote:
>
> > Is the advantage of `Closure#call()` only performance? Because I don't
> see other advantages otherwise, and I don't think the performance impact is
> relevant
On 4 August 2014 15:02, Andrea Faulds wrote:
>
> On 4 Aug 2014, at 13:27, Marco Pivetta wrote:
>
> > The fact that I'm arguing about is "yet another method to maintain" for
> an API that can simply live in userland (and is easier to
> maintain/upgrade/etc)..
>bar->call()->call();
>
> At the risk of stating the obvious, can’t you just use $f->bar->__invoke()
You can't do that if you can't assume that `bar` is a `Closure` instance.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
gnature breakout.
> Oops! ;)
>
> http://php.net/manual/en/class.closure.php
>
Interestingly, reflection doesn't even expose it: http://3v4l.org/8Jutn
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
is a smell. Shouldn't that be
fixed instead?
What particular use-case denies using an interface or abstract type instead?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
fixing" of internal classes has been to disallow operations in
other PHP APIs, while the correct fix would be to make them `final`, with a
`final public function __wakeup`, with a `final public function
__construct` and so on: at least the limitations would make sense from a
userland persp
dable/clear/inspectable stack
trace: http://3v4l.org/i4G8c
Thoughts? If this idea gets enough traction, I'd gladly go and ask for
karma, open an RFC and eventually provide a patch if I'm able to.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 10 October 2014 22:34, Andrea Faulds wrote:
>
> On 10 Oct 2014, at 21:27, Marco Pivetta wrote:
>
> > While rambling with some code today, I realized that `call_user_func`
> > behaves strangely, appearing and disappearing from stack traces depending
> > on vers
t;
Of course they are, but that's obviously because any codebase written so
far didn't have PHP 5.6 support :-)
The main point here is moving forward and killing API that has no use-case
anymore (and has to be maintained).
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
t
adoption rate anyway for the next 5 years.
Even in such a case, isn't it possible to have PHP "include" the polyfill
from an actual location instead of basing the function definition on some
internals voodoo?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
a lot of fuss about BC compat here,
but I don't see why providing them as separate file or using something like
a "global include" is a problem. Is/would something like that (be) possible
via ini setting?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
r extensions.
I would suggest the same deprecation approach for many `array_*` functions,
but I assume that I'd only start a giant shitstorm (pardon the wording, but
that's the most precise term for that) about performance.
Anyway, it's clear that this proposal has short legs, and won't get
anywhere in a vote.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 13 October 2014 16:12, Andrea Faulds wrote:
> 2. Shouldn’t it return fully-qualified class names beginning with a
> backslash?
>
When in string context, we are typically always talking about FQCNs, so the
leading backslash is not needed and should be omitted.
Marco Pive
On 13 October 2014 20:20, Marc Bennewitz wrote:
>
> On 13.10.2014 02:45, Marco Pivetta wrote:
>
> Your implementation of "userland_call_user_func" doesn't have the same
> visibility as "call_user_func[_array]":
> http://3v4l.org/lNgub
Interesting: t
eh_legacy_includeh = '/zeh/path/to/old/functions.php';"
Stupid idea?
Security implications?
And of course "yet another ini setting".
Yet this would allow removing a lot of internal functions that were written
just for the sake of it, and move them to something that c
On 13 October 2014 21:18, Marc Bennewitz wrote:
>
> On 13.10.2014 20:48, Marco Pivetta wrote:
>
> On 13 October 2014 20:20, Marc Bennewitz wrote:
>
>>
>> On 13.10.2014 02:45, Marco Pivetta wrote:
>>
>> Your implementation of "userland_call_user_
ese functions weren't written "just for the sake of it". They were
> written because people needed it.
>
Right, and now they can be built in a way that isn't coupled with the
engine itself.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ns, but not the way doctrine/annotations does it
(calling the constructor of an annotation), and the annotations themselves
can still decide what to do with nested values.
No autoloading is going on, no code execution, nothing: plain and simple
arrays which may as well be used for phpdocumentor as well, if needed.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
uot;hard
> to fix bug" knowing this, you're welcome to.
>
Is there a `.phpt` test-case or discussion backing this?
I find this quite hard to believe, especially since following examples are
broken in php and working "as expected" (by me) in hhvm:
http://
Except for the H1 on the RFC (needs to be updated), I can really see a lot
of cases where I needed this: badly.
On Nov 27, 2014 4:48 AM, "guilhermebla...@gmail.com" <
guilhermebla...@gmail.com> wrote:
> Hi,
>
> I worked on an implementation of a somehow controversial concept that
> exists in hack
ss Foo {}
$foo = new Foo;
$bar = ($foo instanceof foo); // stricts standards
Same goes for type-hints in methods, as those may break reflection (which
triggers autoloading).
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 22 December 2014 at 01:52, Andrea Faulds wrote:
>
> > On 22 Dec 2014, at 00:50, Marco Pivetta wrote:
> >
> > On 22 December 2014 at 01:43, Andrea Faulds wrote:
> >
> >> Hey,
> >>
> >>> On 21 Dec 2014, at 23:33, David Muir wrote:
&g
when).
This will also reduce clashes with the current HHVM implementation.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
($i < $amount) {
$i += 1;
$acc .= $value;
}
return $acc;
}
As you can see, mixing implicit cast and strict constraining behaviors is
perfectly fine in this case, so please don't include contextual switches:
that would be even worse IMO.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 2 January 2015 at 14:00, Andrea Faulds wrote:
> Hi Marco,
>
> > On 2 Jan 2015, at 09:16, Marco Pivetta wrote:
> >
> >
> > I'm not sure why everyone is still taking the PHP manual as a good
> reference about how to write software: PHP internal functions
ppealing in theory but it's not worth
> it in practice.
>
I'm actually already using https://github.com/beberlei/assert for that, and
I'd like to get rid of it for simpler types.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
too much pain (already trying to get there, and mbeccati has a CI
system running with php7 and some major libs).
The only trouble that could eventually come up is with legacy software that
isn't tested at all.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
an do so by
simply using closures, as I described above.
Otherwise, making properties `public` and marking them as `@internal DO NOT
TOUCH THIS!` is perfectly fine, and doesn't need language-level
restrictions IMO.
If you need this sort of feature, consider looking at the recently
discussed https://github.com/php/php-src/pull/947, which is really much
more useful and less magic :-)
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
eeling when dealing with cases such as PDO's constructor is
"WAT?!".
Therefore gogogo Danack!
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Well, the example just shows what I've already got used to when working
with Java.
I like it and it would be of great help to me (especially in reducing the
amount of code to be tested), but there's a lot more around that, like
multiple generic types (new Map()) and how reflection would
deal with it...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ing to have that.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ion of an interval
to me...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
It's just a matter of getting used to it IMO. I am not sure if you can
simply modify its public properties, but if that's the case, that should
handle your problem.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ll use it. We
tried to implement an immutable DateTime in userland, but it doesn't work
out well...
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
it a bit hard to migrate for existing apps.
If you check the doc comments of
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations/DocParser.phpyou
will find the EBNF of the currently used implementation.
I'd really love to see this happening!
Marco Pivetta
on and build a full
annotation reader that instantiates classes and does fancy stuff as we
currently do in doctrine/common.
A fast parser is more than enough I suppose. That's our bottleneck (besides
scanning files).
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ke it impossible to nest annotations. For example, something
like following wouldn't work if the output is just arrays:
@MyApp\Acl({
"allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}),
"deny"=@OtherAp
ty without a real need" :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 8 January 2013 15:22, Lester Caine wrote:
> Having been using 'docblock' elements to document classes in PHP for many
> years, their use by PHPEclipse and PDE
annotations).
And it is also very useful for validations and forms generated from
classes+metadata.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
problems is the warning currently causing in your code?
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 18 January 2013 16:33, KISE wrote:
> Paul Dragoonis,
>
> Actually it wont work i did tried it before, if the dir end with / it will
> list the directories ins
@Lester seems pretty much opt-in to me :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
@Pete actually, your "less than elegant" solution seems quite enough for
this use case.
What's your use case for this kind of static properties? What if you make
them private/protected and use an accessor method to initialize them (and
avoid the overhead during autoloading)?
Marc
e running in circles looking for perfection :)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 22 January 2013 16:39, wrote:
> I am actually going to +1 this idea I thought about discussing it, but
> opted out of it because classes are most often in their own file and if you
> need to do some static bi
ould probably
imply having to think more about the trace we want to follow when analyzing
our bugs. It is just a matter of being aware of new setter/getters (that
are anyway in our trace).
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
tly is the limit that you see when applying the more verbose
`function () {}` syntax? I am just wondering since moving to `{}` will
still not make this portable to any platform except PHP itself.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ctly ok: just vote
"NO".
Don't sell us the "YAGNI" or "additional complexity" story: annotations and
property accessors already demonstrated that there are use cases that even
bring performance improvements.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 21 February 2013 17:04, Johannes Schlüter wrote:
> The quoted business decision was "We want something stable and fast", an
> emphasis of fixing bugs over adding new ones. This sounds sane to me.
>
> johannes
>
>
>
Doesn't exclude new features then: so wh
This *could* be useful if I want to keep track of the state of a proxy, but
it's just an additional property to keep track of manually on the other
side. The additional property is also more explicit and easier to track.
Yes, it needs a better use case.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
For consistency, in strings we should already be using the FQCN implicitly.
Therefore output of serialization and var_export should not need the
leading backslash.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 9 April 2013 06:38, Madara Uchiha wrote:
> Sou
Well done! Congratulations!
On 20 Jun 2013 23:23, "Julien Pauli" wrote:
> Hello!
>
> The PHP Development Team would like to announce the immediate release of
> PHP 5.5.0. This release includes a large number of new features and bug
> fixes.
>
> A separate release announcement is also available. F
e if you think it's a
bad idea)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
as
nothing to do with class names.
PS i'm not so practice with composer ( used few times ) but when modular
> systems , such as CMS , give the possibility to extends them with external
> components...i don't think that composer could solve this problem.
>
It is actua
e space to
> reset to the previous behaviour.
>
>
Hi Andreas,
PHP moved away from the "ini-setting-for-all-the-things" approach, since it
causes more entropy than what it attempts to fix.
Marco Pivetta
On 17 September 2013 16:43, Bob Weinand wrote:
> You could also argue that the current $obj->default; (that's already
> possible)
> is also bad.
>
Yep, and should probably be removed.
It's still there because of BC compatibility as far as I know...
Marco Pivetta
ht
al abstract methods in one interface/class, which
> would need several callbacks passed to the constructor.
> Also '$this' is mapped to the right objects.
>
> Regards,
> Sebastian
>
>
It also avoids usage of these classes outside the scope where they are
defined...
You are probably looking for something like `array_key_exists($varName,
get_defined_vars());`: https://3v4l.org/XagEA
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 26 August 2015 at 04:26, Sherif Ramadan wrote:
> I get that it exists. I'm asking wha
; Regards
> PK
The same usually applies to ~, {, }, [ and ].
I personally stopped buying non-en_US keyboards and that's it.
Basically, if you code you kinda want to use en_US layout anyway (or dvorak
if you had too much free time).
I realize that this is unfriendly to beginners, but the ~ al
ing all of the scope into
the closure: while it is working for functional languages, that's where
most of the headaches come from in languages such as javascript.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 24 September 2015 at 14:27, Pierre Joye wrote:
> On
As mentioned already by Andrea: why not just a named constructor on the
closure class, like `Closure::fromCallable(callable $callable)`?
Much simpler, easier to find, etc etc...
On Sep 29, 2015 11:23, "Dan Ackroyd" wrote:
> Hello internals,
>
> I'd like to start a discussion of a proposal to allo
arlier 8.0 is not a problem either.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 7 January 2016 at 20:12, Pierre Joye wrote:
> On Jan 7, 2016 11:54 PM, "Scott Arciszewski" wrote:
> >
> > All,
> >
> > I propose the following timeli
Edit: never mind - I must have misread somewhere that dropping in 7.2 was a
plan. Sorry for the misunderstanding!
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 10 January 2016 at 12:56, Marco Pivetta wrote:
> While I'd love to see mcrypt die, unless we al
even worse in the
global namespace.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 20 January 2016 at 17:40, Jakub Zelenka wrote:
> Hi,
>
> The vote is now open:
>
> https://wiki.php.net/rfc/openssl_aead#voting
>
> Cheers
>
> Jakub
>
On 24 January 2016 at 13:08, Jakub Zelenka wrote:
> Hi,
>
> On 23 Jan 2016 21:01, "Marco Pivetta" wrote:
> >
> > Just FYI, I'm voting against this proposal, as the number of parameters
> is simply growing out of control, which involves:
> >
1 - 100 of 646 matches
Mail list logo
