Kris Craig 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 modern Git-style
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 ma
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 wil
Stas,
On Sat, Mar 3, 2012 at 9:27 PM, Stas Malyshev 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
> operation your type
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 f
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
--
P
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 com
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
>
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 establish
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
On Sun, Mar 4, 2012 at 12:28 AM, Kris Craig 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
> proposals to be more exp
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 op
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 feat
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 requests
>
> 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. Noth
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 fun
On 29.02.2012 10:43, jpauli wrote:
On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joye wrote:
hi Bill,
On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
wrote:
On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
On 02/28/2012 02:44 PM, Christopher Jones wrote:
Build PHP with ZTS enabled by defa
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 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 pol
19 matches
Mail list logo
