On Fri, 02 Mar 2012 17:45:20 -0800, Kris Craig wrote:
I think it's a solid approach but I've always been a fan of having
written policies and clear procedures as opposed to the more ad hoc
approach that this appears to be. I wouldn't mind seeing this drafted
into an RFC; I believe the policy
Hi, Anthony
At first, thanks for your great work!
As I have to learn C and C++ from scratch it was quite a good help to have
someone like you pushing it forwards.
I like having the casting exactly in the definition of the function, even
if it just saves the 6 characters. You have all information
On 29.02.2012 10:43, jpauli wrote:
On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joyepierre@gmail.com wrote:
hi Bill,
On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
wr...@rowe-clan.net wrote:
On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
On 02/28/2012 02:44 PM, Christopher Jones
On 02/03/12 02:56, Philip Olson wrote:
Hello!
Please clarify whether or not get_magic_quotes_gpc() and
get_magic_quotes_runtime()
are deprecated, because I do not think they are. Deprecated means people
should not
use them while writing new code, but they are perfectly sensible
To be honest, I'm not as sold on this version (I built it as a POC, but to
see how useful it is). It feels like it's not doing enough. All it really
does is save 6 characters.
Personally, I think it saves much more characters (,,,in the
documentation).
And I think, that's enough. Nothing
Hi Internals,
with 5.4. out of the door, we can start thinking about moving
the php-src repository to git. Commit access to the php-src SVN
repository will be disabled on March 15. I will run the final
migration on that date and push the php repository to git.php.net.
Updates:
(1) Pull
Thanks for the update!
Quick question: As far as the branching model goes, are we going to stick
with the SVN-style of just having a branch for each release version and
dumping all the commits directly onto it, or do you plan on switching to a
more modern Git-style branching model of merging
Lol well personally I disagree. I was super-stoked when the RFC process
was introduced and I would LOVE to see us make more use of it! Not only
does it help get a clearer guage of vote totals, but it also forces
proposals to be more explicit and well-thought-out IMHO.
Of course that's only my
On Sun, Mar 4, 2012 at 12:28 AM, Kris Craig kris.cr...@gmail.com wrote:
Lol well personally I disagree. I was super-stoked when the RFC process
was introduced and I would LOVE to see us make more use of it! Not only
does it help get a clearer guage of vote totals, but it also forces
Hmm yeah that's a good point. I guess the RFC would be to document what
the procedure is; and, if there's not a procedure, then to establish one
for consistency. I'm all for meritocracy for OOP project admins but if
there's no established process for determining who goes into that inner
circle I
On Sat, 2012-03-03 at 16:19 -0800, Kris Craig wrote:
Hmm yeah that's a good point. I guess the RFC would be to document what
the procedure is; and, if there's not a procedure, then to establish one
for consistency. I'm all for meritocracy for OOP project admins but if
there's no established
Yeah your argument makes sense. The lack of process still makes me uneasy,
but you shouldn't take that too seriously. I just tend to be very neurotic
about this sorta thing. So don't let my apprehensive face-twitching about
it bother ya too much lol. =)
--Kris
2012/3/3 Johannes Schlüter
Hey all,
I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to
Hello all,
I've drafted an RFC and functional-complete patch for disucssion
another alternative to add scalar object casting magic methods.
https://wiki.php.net/rfc/object_cast_to_types
Please review the RFC and attached patch, and start some discussion on
this proposal.
Thanks,
Anthony
--
Hi!
I've drafted an RFC and functional-complete patch for disucssion
another alternative to add scalar object casting magic methods.
https://wiki.php.net/rfc/object_cast_to_types
Please review the RFC and attached patch, and start some discussion on
this proposal.
Some notes:
1. Use cases
Stas,
On Sat, Mar 3, 2012 at 9:27 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
https://wiki.php.net/rfc/object_cast_to_types
Some notes:
1. Use cases for this are unclear. Wrapping scalar types does not seem very
efficient as conversion is always one-directional - once you do any
Hi!
Well, as you know that was part of my original proposal (
https://wiki.php.net/rfc/object_cast_magic ). However, after talking
with a few core devs about it, it seemed that separate methods are the
preferred solution, as the single method requires a big switch (which
isn't as clean, and
Anthony Ferrara wrote:
2. Having separate methods is probably not the best idea. It may lead to
implementation having inconsistent conversions between types, such as floats
and integers, etc. or having conversions to float but not int and getting
very hard to debug errors because of that. Also
Kris Craig kris.cr...@gmail.com writes:
Thanks for the update!
Quick question: As far as the branching model goes, are we going to stick
with the SVN-style of just having a branch for each release version and
dumping all the commits directly onto it, or do you plan on switching to a
more
19 matches
Mail list logo
