On 5 February 2015 at 05:37, Adam Harvey wrote:
> I'm not totally clear on what this RFC is proposing, honestly. Is the
> new script statement meant to only include files that are entirely
> wrapped in tags? Are files included that way assumed to
> be PHP and don't require tags? Something else?
On 5 February 2015 at 10:24, Pierre Joye wrote:
> I do understand what you try to achieve, from all point of view.
> However I strongly disagree with this as a security improvement. I see
> this more as yet another attempt to replace what should be done at the
> OS level.
>
I'm inclined to agree,
On 6 February 2015 at 12:02, Yasuo Ohgaki wrote:
> Hi all,
>
> This RFC was renamed from "script() and script_once()".
> Original proposal had defect. It wasn't perfect.
>
> This RFC proposes "script_path" INI directive to eliminate
> file/script inclusion at all via require().
>
> https://wiki.ph
On 8 February 2015 at 17:03, Pierre Joye wrote:
> I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to
> keep it around for BC. I simply do not have the resources to make that
> happen so someone has to jump on it (Derick?)
>
Are we happy to accept that we'll lose access to so
On 10 February 2015 at 21:38, David Muir wrote:
> Does this mean PHP will be taking on the role of maintaining libmcrypt as
> well?
That's not what it means, no.
> If a security issue is found, what is the course of action?
Well, what happened when there was vulnerabilities in OpenSSL?
I've b
On 10 February 2015 at 23:29, Paul Dragoonis wrote:
> It's common sense that if something receives significant resistance then
> there's usually a good reason for it and it shouldn't be ignored regardless
> of how mathematically accurate it may seem to exclude it. Let's keep MSSQL
> in.
https://w
I don't think there is time to get something finalised for 7.0, I
certainly wouldn't want anything cryptography related to be rushed, so
this is a pre-RFC discussion to gather ideas and opinions for
something we can work towards in PHP 7.1 and that can live as a PECL
extension between now and then.
On 14 February 2015 at 00:32, Benoit Schildknecht wrote:
> I don't think EngineException should inherit from Exception, it would be
> very dangerous. I'm sure a lot of exceptions are handled like this by a lot
> of devs, without creating custom exceptions :
>
Agreed, EngineException should be a b
On 15 February 2015 at 02:46, Andrea Faulds wrote:
> Hi everyone,
>
> I should’ve done this a long time ago, but I’m going to hold a vote on this
> RFC. The implementation isn’t finished, but the remaining work isn’t
> impossible to surmount (though help would certainly be appreciated). RFCs can
On 15 February 2015 at 13:51, Andrea Faulds wrote:
>> Extensions "that deal with numbers" are all going to need updating. So
>> probably every extension?
>
> Anything accepting a zval rather than a long through zpp, but the changes are
> quite small in most cases. It’s a much smaller change than,
On 17 February 2015 at 05:48, Sara Golemon wrote:
>>> We can sigh and tut about this not being "the PHP way", but the script
>>> author was the one who chose to enter into a tight contract, and the
>>> script author, not you, is the one who should have that authority over
>>> their own application
On 17 February 2015 at 11:46, Alexander Lisachenko
wrote:
> Hello, internals!
>
> I want to introduce a RFC for providing a userland API for accessing an
> Abstract Syntax Tree of the source code and to provide userland parser
> hooks for source code modification:
> https://wiki.php.net/rfc/parser
On 17 February 2015 at 12:22, Alexander Lisachenko
wrote:
> Yes, parser extensions will be called for all require/include/evals after
> registration. This part is transparent for opcache, because opcache just
> stores an opcodes for the file. AST is parsed only once for each file, then
> hooks can
On 17 February 2015 at 17:35, Tim Bezhashvyly wrote:
> Dear PHP internals,
>
> this is my first RFC proposal and I am not sure if in this email is supposed
> to contain all RFC details or just a brief idea .. which is to drop PHP
> constants in favour of “final" immutable variables.
I think we
On 17 February 2015 at 22:03, Sara Golemon wrote:
> Based on conversations here and elsewhere on the internet, I'd like to
> put forward a rough gameplan for scalar types which I hope addresses
> most concerns. This is back-of-the-napkin and I'm not asking for a
> committed yes/no, just pre-rfc s
On 18 February 2015 at 13:18, Rowan Collins wrote:
>> This leaves us in a state where some functions will have defined types
>> with their aggressive coersion rules and some will not, and we can't
>> expect users to remember which set of functions have been updated or
>> not.
>
> That's precisely
On 18 February 2015 at 14:40, Lester Caine wrote:
> But my favourite is still
> '\143\141\164' == "\143\141\164" which is false, but I doubt many would
> know why?
Pretty sure one of the first things PHP devs learn is that single
quoted strings only accept \' and \\ as escape sequences.
--
PHP
On 18 February 2015 at 20:44, Anthony Ferrara wrote:
> Dear Internals,
>
> Since the resignation of Andrea, the mixed-mode type hint (called
> declaration in the proposal) proposal has been left abandoned.
> Considering that the ending votes were 67/34 (66.3%) with several
> no-votes being only du
On 18 February 2015 at 21:50, Anthony Ferrara wrote:
>>> Static Analysis Is Possible With Weak Declarations
>>
>> The advocacy of allowing `accepts_float(returns_int());` doesn't help
>> the cause of static analysers in strict mode.
>
> Java does exactly this and is statically analyzable. So...?
On 18 February 2015 at 22:21, Albert Casademont Filella
wrote:
> So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
> combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
> different Yes votes is needed.
This is pretty flawed, but nice try.
--
PHP
On 19 February 2015 at 15:45, Pierre Joye wrote:
> Still, no announce for a discussion about this specific RFC. And
> really, the content of the RFC is almost empty, pointing to the ML
> archive is really not the right way :)
There was an RFC announce thread 3 days ago. I agree 3 days is a short
On 20 February 2015 at 08:47, Markus Fischer wrote:
> This sounds two-folded to me: "very cool" (albeit I can't see a use-case
> right now) on one hand and "utter magic" on the other.
Inclined to agree.
@Joe what use-case prompted this feature?
--
PHP Internals - PHP Runtime Development Mailin
complaint about naming.
"empty_expressions" ... I'll give you an empty expression!
But overall +1 on functionality and patch.
Cheers!
Leigh.
On 21 February 2015 at 05:11, Thomas Punt wrote:
> Hello Internals!
> The following RFC aims to make empty() have a variabl
Hi Andrey,
On 24 February 2015 at 09:51, Andrey Andreev wrote:
> I noticed that the patch checks for /dev/arandom availability first,
> and I'm pretty sure that on systems that have it, /dev/urandom simply
> redirects to /dev/urandom, so that might be a bit redundant ... Maybe
&
On 24 February 2015 at 10:55, Pierre Joye wrote:
> It should use the session.entropy_file setting as it aims to be the exact
> same thing. It also allows custom entropy src (better ones for higher
> demands) as well.
I disagree. We want to take responsibility away from the user to
choose the best
On 23 February 2015 at 21:15, Albert Casademont Filella
wrote:
> I like it! That's what I proposed to Anthony (and Andrea before) before
> Zeev presented their alternative, to held a double vote on the strict vs
> weak feature. It was not met with much enthusiasm, hope they change their
> minds wi
I've been having a play around with the implementation, and it's been
behaving pretty solidly, nothing unexpected so far.
I've even gotten around my issue regarding no strict-by-default option
for those of us who want it.
Maybe this will sway a few voters. I'll put the source up if this
particula
On 24 February 2015 at 19:23, Thomas Bley wrote:
> I think this is a huge bc break that will affect many applications. For
> example:
>
> // test.php
> error_reporting(E_ALL & ~E_NOTICE);
> echo $_GET['value'];
>
> curl http://.../test.php?value=foo // ok
> curl http://.../test.php?value[0]=foo&v
On 24 February 2015 at 20:54, Pierre Joye wrote:
> On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote:
>> PERHAPS, it could be written in such a way that a PECL extension can
>> alter the RNG to accommodate that usecase. But I'd be wary of that and
>> core supporting userland RNGs.
>
> Yes, driver
On 25 February 2015 at 09:09, Zeev Suraski wrote:
> Leigh,
>
> There isn't a weak-only proposal on the table. There's the original one
> (dual mode) and the coercive one. Both have both strict and dynamic
> elements in them.
> I think that what Anthony proposed about
On 25 February 2015 at 10:43, Yasuo Ohgaki wrote:
> Anyway, Zeev's proposal is much better. IMHO. Since we don't
> have RFC owner for older proposal, we may only have vote for
> Zeev's proposal.
Did I miss something? Pretty sure Anthony is still owning the proposal
he has put forward.
--
PHP In
ehow make it clear that this is not to
be used for keys or IVs, but it's a good fit for things like session
IDs or CSRF tokens.
> - Don't offer a crypto-secure random integer getter unless the
> requirement for such a thing is clear.
The random_int function will always provide an
On 25 February 2015 at 20:24, Stanislav Malyshev wrote:
> Hi!
>
>> For example, the number of users that actually need to do something
>> better than read from /dev/urandom is small. A user that is concerned
>
> Good summary read on the topic: http://www.2uo.de/myths-about-urandom/
> TLDR: it's ok
Might as well mention it because it has been discussed OTR.
We've thrown the idea around that we could cater for other sources of
random via a PHP extension. (I.e. if someone has a particular hardware
RNG they want to use). We're concerned that this may be misused, or
even abused as a way of delib
On 26 February 2015 at 15:04, Tom Worster wrote:
>>I actually started down this RFC path out of frustration on this very
>>point of needing secure random alphanumeric stings. The originally RFC &
>>patch contained a `random_hex()` function that would convert bytes from
>>the CSPRNG into hex.
>
> b
On 26 February 2015 at 15:37, Tom Worster wrote:
> On 2/26/15, 3:48 AM, "Stanislav Malyshev" wrote:
>
>>The custom is that the first word names the function group (yes, I know
>>old functions do not follow it, but this is new one). Unless we're going
>>to introduce a group of functions called sec
On 26 February 2015 at 16:07, Stefan Esser wrote:
> Hi,
>
>> libgcrypt does at least have a maintainer but it's poor
>> Werner Koch who is so destitute he lives on charity raised
>> on Kickstarter and has his work cut out just trying to deal
>> with GPG: http://is.gd/cbHCYO
>
> Wow. Just WOW.
>
>
On 27 February 2015 at 08:06, Sebastian Bergmann wrote:
> While working on PHPUnit today I noticed one test of its own test
> suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
> this can be found at
>
>https://github.com/sebastianbergmann/phpunit/issues/1630
>
> Florian M
On 27 February 2015 at 08:20, Leigh wrote:
> Looking through git blames, this property has been protected for a long time.
>
> Possibly related (although not at all sure), Dmitry made some changes
> to zend_read_property()
>
> https://github.com/
On 27 February 2015 at 21:14, Tom Worster wrote:
> 1. You say it "doesn't leave any room for interoperability" but I'm
> not sure I agree. I invite you again to look at the Cryptography lib
> for Python.
There are countless applications/services that will do things "their
own way", and the odds o
On 1 March 2015 at 03:32, Stanislav Malyshev wrote:
> I don't see why the first one needs any vote. It is supposed to be
> implemented as an extension, so why not go and implement an extension,
> and put it in PECL, and then propose it for core inclusion, if it proves
> popular?
Agree
> As for t
On 3 March 2015 at 11:56, Alexander Lisachenko wrote:
> Good morning!
>
> I have cleaned https://wiki.php.net/rfc/parser-extension-api and restricted
> it's scope only to the parsing API. Extension API can be implemented later
+1
> on top of
> https://github.com/php/php-src/commit/1010b0ea4f4b9f
On 1 March 2015 at 11:29, Yasuo Ohgaki wrote:
>
> Thoughts?
>
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it causes.
Sorry if this
On 11 March 2015 at 18:46, Eli wrote:
> Benoit ... actually Anthony's original proposal specifically was
> designed to be live at the same time as this alternative proposal. And
> it's even mentioned in the proposal (stating that it would stay open
> until the 13th or when the alternative proposa
voting against because you
don't want to declare strict in every file, there are ways around
this. Don't oppose the RFC simply on this issue alone.
Cheers,
Leigh.
On 13 March 2015 at 17:24, Marcio Almada wrote:
> Hi,
>
> 2015-03-13 12:45 GMT-03:00 Anthony Ferrara :
>
>
On Mar 13, 2015 10:36 PM, "Pierre Joye" wrote:
> So law is firm when it fits your goal but flexible when not? We have
> relatively strict rules for this exact reason: nk double standard. Stop
> playing with the rules and stand as someone willing to find compromises.
Totally with Pierre on this on
On 14 March 2015 at 02:50, Rasmus Lerdorf wrote:
> The problem there is what does "without dataloss" mean? At which precision do
> you consider there to be no dataloss?
>
> -Rasmus
"without dataloss" would mean you can go from typeA -> typeB -> typeA'
and typeA === typeA'
--
PHP Internals - PH
On 15 March 2015 at 08:42, Pavel Kouřil wrote:
> Sure, per-file is better than ini setting, but better doesn't mean
> good (because it is still a pretty bad approach). The ini setting at
> least has the option to be turned off in code once everyone realizes
> it was a bad idea (register_globals v
On 15 March 2015 at 19:24, Zeev Suraski wrote:
>
> I don't think you understand the meaning of unity, but I'll let internals
> be
> the judge of that.
Judging.. judging..
https://www.youtube.com/watch?v=bjEmHAeE4DY&t=1158
On 15 March 2015 at 10:29, Matteo Beccati wrote:
>
> I want to vote yes, but naming is something that scares me a bit. Without
> any indication that it's CSPRNG, people might start using it even when
> unnecessary, and I'd be worried about potential negative effects, such as
> exhausting the entro
On 15 March 2015 at 13:17, Pádraic Brady wrote:
>
> Were folk to use random_int() by default, it would be actually be
> considerably better than the situation today where many reach for
> mt_rand() without really considering the use case. Using a strong
> source of ints instead of a weak source st
On 15 March 2015 at 21:09, Admin Admin wrote:
>
> I'll need some help with the patch. I took a look at it once, and since my
> C skills are abhorant, I found myself scratching my head at all the places
> that seem to throw the error message above and what each of them did. So if
> there is anyone
On 15 March 2015 at 22:56, Stanislav Malyshev wrote:
>
> if
> running PRNG for "too long" is dangerous, wouldn't we already have much
> more serious problem with encryption routines based on them which
> basically do it all the time?
Indeed we would, it's the kind of issue that would get solved
On 16 March 2015 at 08:04, Lester Caine wrote:
>
> Some of this Syntactic sugar would in the past have been developed in
> PEAR, but the support for 'userland' solutions via that path seems to
> have lost favour, with even the suggestion that PEAR should be dropped?
> Perhaps if PEAR contained exa
On 16 March 2015 at 04:58, Levi Morrison wrote:
> Dear Internals,
>
> I am tentatively opening the vote on this RFC:
> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>
> It's a bit tentative because I would prefer to wait until the vote on
> Anthony's RFC closes tomorrow as there is some ov
On 16 March 2015 at 23:37, Dan Ackroyd wrote:
>
> In particular the keywords 'Resource' and 'mixed' seem to have limited
> need to be reserved. I don't believe there has been any suggestion
> that either of these would actually be used as types for PHP 7.x. So
> making them be unusable seems to be
On 17 March 2015 at 07:08, Leigh wrote:
>
> I agree, mixed seems to serve no purpose (just don't hint the parameter,
> same result). Resource is something we're hopefully going to phase out over
> time as they get replaced with objects (like Nikita already did with GMP
On 17 March 2015 at 08:37, Lester Caine wrote:
> To help towards that end, can someone who understands what is wanted
> from the weak type hint mode actually produce a summary of that as it is
> very difficult to extract just what has now been agreed for that area of
> type hinting. A base that c
On 19 March 2015 at 21:03, Larry Garfield wrote:
> Variations of this proposal have been discussed many times. I don't
> recall what the pushback was but it's worth your time to check the archives
> to see what the objections were and if you can address them, and/or if the
> new engine in PHP 7
On 20 March 2015 at 10:38, Leigh wrote:
>
> I've tried implementing python style slice on both strings and arrays in
> the past (I don't seem to have an existing branch with it in any more
> though it seems). The biggest problems I hit were regarding the syntax, the
> fu
On Mar 20, 2015 11:40 AM, "Alex Bowers" wrote:
>>
>> I've tried implementing python style slice on both strings and arrays in
>>
>> the past (I don't seem to have an existing branch with it in any more
>> though it seems). The biggest problems I hit were regarding the syntax,
the
>> functionality
On Mar 20, 2015 12:33 PM, "Alex Bowers" wrote:
>
> We also need to consider then the possibility of setting data by position.
>
> What should $array[@1:3] = [1,2,3] do?
>
> Should it overwrite the values there, and append any that don't exist, or
> should it be a parse error?
I'd say overwrite/r
On Mar 20, 2015 2:59 PM, "Alex Bowers" wrote:
>
> >
> > So $dictionary['elephant':'snake'] returns all elements with keys which
> > sort lexically between 'elephant' and 'snake', regardless of whether the
> > array is sorted.
>
>
> Makes sense to me.
>
> Alternatively, a key-based slice could look
On Mar 20, 2015 4:00 PM, "Alex Bowers" wrote:
>>
>> IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.
>
>
> I have to agree, we are get
On 21 March 2015 at 12:30, Peter Cowburn wrote:
> On 21 March 2015 at 08:14, Xinchen Hui wrote:
>
> > Hey:
> >
> > On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui wrote:
> > > Hey:
> > >
> > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams
> > wrote:
> > >> On Fri, Mar 20, 2015 at 10:46:58PM +11
nd RM?
Cheers,
Leigh.
On 22 March 2015 at 07:49, Pierre Joye wrote:
>
> From A RM point of view, I agree with other here, I could not think of
> a better person than you as one of the RMs. You did and still do a
> fantastic job, keeping things up and running, awesome communications,
> etc. As a 2nd RM, I would like som
On 22 March 2015 at 07:00, Patrick Schaaf wrote:
>
> Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
> good point to spell out a change clearly, and anchor it for reference in
> discussion. Discussion on internals itself cannot provide that, it is too
> scattered, and POC c
On 21 March 2015 at 12:13, Georges.L wrote:
> Hi php internals,
>
> After some long and deep research i finally decided to write my first RFC
> about a feature i'd be interested to be improved in the php core: *Nested
> enclosing returns*
>
>
> The main purpose, as the title say, is to have the p
On 22 March 2015 at 08:54, Patrick Schaaf wrote:
>
> Okay, that's easier to implement and probably sufficient, if everybody
> play nice. Or, another idea and maybe a lot less work to implement: all
> active release managers could have a "want a vote" button on pending RFC
> pages.
>
+1 on RM sign
On 22 March 2015 at 13:33, Yannick Komotir wrote:
> Hi,
>
> I am sorry if I am wrong but why it is not people that started php 7/ng
> project ? Dmitry, Nikita or Xichen ?
>
Personal opinion: I'd prefer all of these people had more time to work on
code, and didn't have to worry about RM duties :)
Hi all,
Voting has now closed on this RFC. The feature has been accepted for PHP 7
with votes of 41 - 0.
Thanks to all who participated in the discussion and gave feedback.
Regards,
Leigh.
;s a huge bonus that one of the RMs has this focus. I
expect a large amount of "casual" testing leading up to GA will be done by
people who just want to download on their desktop and try things, and
quality Windows builds will help a lot.
Many thanks for nominating yourself.
Cheers,
Leigh.
On Mon, 3 Aug 2015 at 21:54 Scott Arciszewski wrote:
> Hi,
>
> I would like to make it easier for PHP developers to implement
> cryptography features in their applications. I intend to work on some
> of these ideas and submit them for inclusion in PHP 7.1.
>
> Some of these might be familiar to s
On Thu, 6 Aug 2015 00:55 Scott Arciszewski wrote:
All,
I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are *the
worst*).
Here's a quick recap
Argument
Session Handler enhancement (create_sid)
I would like to propose a new feature to the current custom session
handling; the ability for a user defined function to be used when
generating the session id.
The reasons are as follows:
The Session Handler doesn't know when session_regenerate_id is us
> Basically, the current function library is moved to the legacy
> namespace. The default setting is import the functions of the legacy
> namespace into the root namespace for BC. But with that setting
> turned off all the existing functions go away to be replaced with a
> designed API, instead o
> While I think having a legacy implementation is definitely worth while, it
> needs to be in core. So PHP6 would introduce the new syntax, and include the
> legacy functionality in as close to 100% backwards compatible way as
> possible. From there, we'd only remove the legacy functionality from c
I missed the discussion on this one, the RFC examples are very simple. Does
it support aliasing array indices?
For example: (use $matches[0] as $name)
On Jul 18, 2012 3:55 PM, "Laruence" wrote:
> Hi:
> Call for voting for "Allow use T_AS in closure use statement",
> https://wiki.php.net/rfc/
What about expanding the syntax instead of introducing new reserved words.
use A\B {
Class1,
Class2
}
On Aug 2, 2012 5:44 PM, "Yahav Gindi Bar" wrote:
>
> Hi,
>
> I don't know how to tag this kind of discussion (because it's not RFC
> request).
> I've interested in runkit PECL extension and think that it should be part
> of the PHP core runtime.
>
> I do think that the implementation should be dif
> Sandboxing: Complicated by the fact that it only works in a threaded
> build, can't transfer all types (e.g. resource, complex objects), and
> can't run concurrently. Until/unless these problems can be
> meaningfully solved, I wouldn't consider it a functional
> implementation.
To me the "threa
ss is disabled. I'm
wondering in how many other places this could occur.
The obvious solution is to be more careful and check return values,
but a FATAL would also have prevented execution continuing.
Thanks,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
> Because there isn't anything actually wrong.
>
> A fatal error is reserved for things we cannot recover from, but a
> disabled function is easily recoverable.
I don't see how it is any more recoverable than the function/class not
existing at all. How much code do you know of that checks for the
Hi
> The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
wi
> Basically we shouldn't break any interfaces that are user-facing but
> we are free to change things internally as much as we want as long as the
> external interface is honored.
So how do you actually go about adding a feature that requires an
interface change?
Take for example the SessionHandl
don't think this requires an RFC, as it does not break any existing
expected behaviour.
I'd like to hear the lists opinion on introducing these new formatting options.
Provisional PR: https://github.com/php/php-src/pull/812
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Developmen
On 9 September 2014 21:16, Andrea Faulds wrote:
>
> Why is there no big/little-endian signed long long?
>
Because there is no big/little-endian signed long :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 9 September 2014 21:16, Andrea Faulds wrote:
>
> Why is there no big/little-endian signed long long?
>
I suppose you could argue that these count
i - signed integer (machine dependent size and byte order)
I - unsigned integer (machine dependent size and byte order)
However they specify machi
On 9 September 2014 23:08, Nikita Popov wrote:
> Hi internals!
>
> I've created a small RFC proposing the removal of the alternative PHP
> opening/closing tags:
>
> https://wiki.php.net/rfc/remove_alternative_php_tags
>
> It removes <% and
On Sep 9, 2014 7:36 PM, "Leigh" wrote:
>
> Hi Internals,
>
> I would like to propose giving pack() and unpack() 64 bit format
> codes, mimicking the current behaviour of 32 bit format codes.
>
> Pack and unpack are obviously functions inspired by Perl, which has
&g
they all make sense for PHP.
Please review and discuss the proposed changes and see how you feel about them,
Thanks,
Leigh.
P.S @andrea your comments from the original thread are addressed in the RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 16 September 2014 16:14, Anatol Belski wrote:
> I made a build from the current revision
> http://windows.php.net/downloads/snaps/ostc/master-f469dc74/ so anyone
> curious can easy snuffle :) It contains all the currently ported exts +
> debug symbols, no PGO. Please catch up later with windows
On 16 September 2014 17:25, Leigh wrote:
>
> What's the difference between the build you put up, and the builds in
> http://windows.php.net/downloads/snaps/master/ ?
Since I am home now and can test. I'll answer my own question - builds
in snaps/master are still 32 bit builds.
On 17 September 2014 15:52, Christian Stoller wrote:
> Hello all,
>
> I hope the subject is not misleading. Please look at the following code:
>
> class A { }
>
> class B extends A { }
>
> interface C {
> function foo(A $a);
> }
>
> class D implements C {
>
On 12 September 2014 22:30, Leigh wrote:
> Hi list,
>
> I would like to propose the addition of format codes for pack() and
> unpack() to work with 64 bit integers.
>
> https://wiki.php.net/rfc/pack_unpack_64bit_formats
Dear list,
If there are no outstanding issues in one week
segfaults, I am working on it)
Thanks for reading.
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19 September 2014 23:08, Rowan Collins wrote:
> It's worth noting that both Smarty and Twig implement a similar mechanism in
> their respective foreach loop syntax.
>
> Smarty spells it {foreachelse}
> http://www.smarty.net/docs/en/language.function.foreach.tpl
>
> Twig spells it {% else %}
> h
ether. This thread is about the "loop not entered" syntax. Lets
stick to that for now, and I'm more than happy to create a thread for
the other scenario later on, and we can discuss the python style there
instead.
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 20 September 2014 00:15, Andrea Faulds wrote:
>
> Why not? Python uses “else”, and before creating this RFC you initially
> wanted to use “else”.
Then I realised it was folly. Documented in the RFC why "else" is a bad choice.
> I’m bringing it up because I think we’re only going to end up wi
1 - 100 of 338 matches
Mail list logo
