I find this somewhat conflicting.
If it's experimental, and will likely be removed because nobody will
maintain it, why is anything being added to it at all?
This simply makes it easier for people to build a dependance on a feature
that will ultimately cease to exist in the next major version.
发自我的 iPhone
在 2013-4-4，16:36，Leigh lei...@gmail.com 写道：
I find this somewhat conflicting.
If it's experimental, and will likely be removed because nobody will
maintain it, why is anything being added to it at all?
Maintaining it.
This simply makes it easier for people to build a dependance
On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins krak...@php.net wrote:
Hi Sara,
A logical extension of this idea would be to drop _array_ and cover
objects too, one uniform everything API is very appealing, and way easier
to document properly.
Something alone the lines of:
static inline
The idea was to avoid treating the object as an array of properties
where there is another option. Where there isn't an option the objects
properties have to be accessed as an array dont they?
On 4/4/13, Nikita Popov nikita@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins
IMO , we should remove that feature from 5.5.
If Laruence is OK to maintain it, then we keep it, but Laruence, please,
improve it so.
We keep it if Laruence can make it stable for 5.5 final. If he cant , or
doesn't want to work on it any more while in betas ; then we should remove
curlwrapper
Hello everybody,
Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.
Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the runtime PHP the code is
beeing run on.
We already
I'm having a hard time seeing production use cases for this.
While it is a very good suggestion, and probably not too hard to implement,
what benefit does it help you in an actual application outside the
development stage?
I'm in favor though, would probably have some uses during the development
On Thu, 2013-04-04 at 16:18 +0200, Julien Pauli wrote:
Then , I remembered I once proposed to add a new function that could
return
every ./configure options used to compile the runtime PHP the code is
beeing run on.
What's the purpose of this? What problems should be solved by that? - We
I think creating easy processable output from phpinfo() is a good idea in
theory, but as Madara says, I'm also not sure about any other production
uses for this aside from the issue at hand with curlwrappers.
Are there many use cases except for the config options that this would be
useful for?
I've been pondering this issue for a while now, and I keep reaching the
same conclusion, so I'm going to just briefly share what I think.
In my opinion, the real issue is not poor design of the DateTime class - it
works as you would expect classes and objects to work, in the sense that
when you
-- Forwarded message --
From: dor.tchi...@gmail.com
Date: Apr 4, 2013 6:19 PM
Subject: Re: [PHP-DEV] a couple of thoughts on the DateTime type debate
To: Rasmus Schultz ras...@mindplay.dk
Cc:
I really don't understand the problem. You have a DateTime instance, you
manipulate it as
On Thu, 04 Apr 2013 19:13:54 +0400, Rasmus Schultz ras...@mindplay.dk
wrote:
I've been pondering this issue for a while now, and I keep reaching the
same conclusion, so I'm going to just briefly share what I think.
In my opinion, the real issue is not poor design of the DateTime class -
it
Hi
2013/4/4 Julien Pauli jpa...@php.net:
As you can see, it is rather simple but would need some work as it is
better for the Configure Command to return an array with the options
instead of a big string ; easier to parse.
Thoughts ?
As Johannes already said, we got Reflection, and we
On 04/04/2013 03:18 PM, Julien Pauli wrote:
Hello everybody,
Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.
Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the
Is it a really big feature if it's just syntactic sugar and internally
stored as an array? say:
struct Color
{
public $r = 1.0;
public $g = 1.0;
public $b = 1.0;
}
Stored internally this might be something like:
array('__type'='Color', 'r'=1.0, 'g'=1.0, 'b'=1.0)
Have you worked
Joe Watkins krak...@php.net wrote:
Something that hasn't been mentioned, installation of software like
wordpress or whatever, might be able to offer advice to the end user
based on the configuration defaults, regardless of ini settings.
Le me repeat what I said in this thread using other
OOP is not a beginner's concept. I don't want to sacrifice good coding
practices for a better learning curve.
Also, a glance on the manual would reveal that the method returns the same
instance for chaining (which is also debatable, why do we even do that?)
On Apr 4, 2013 7:46 PM, Rasmus Schultz
On 04/04/2013 05:53 PM, Johannes Schlüter wrote:
Joe Watkins krak...@php.net wrote:
Something that hasn't been mentioned, installation of software like
wordpress or whatever, might be able to offer advice to the end user
based on the configuration defaults, regardless of ini settings.
Le
Joe Watkins krak...@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options, which is
better than not being able to expose those options by any reasonable
means.
Then those extensions should expose the
On 04/04/2013 06:30 PM, Johannes Schlüter wrote:
Joe Watkins krak...@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options, which is
better than not being able to expose those options by any
2013/4/4 Madara Uchiha dor.tchi...@gmail.com
OOP is not a beginner's concept. I don't want to sacrifice good coding
practices for a better learning curve.
This is interesting. Best practices from other languages, including C#,
Scala etc, have shown that some things are better represented by
On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins krak...@php.net wrote:
On 04/04/2013 06:30 PM, Johannes Schlüter wrote:
Joe Watkins krak...@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options,
On 04/04/2013 07:04 PM, Kris Craig wrote:
On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins krak...@php.net wrote:
On 04/04/2013 06:30 PM, Johannes Schlüter wrote:
Joe Watkins krak...@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured,
Hi
I don't think we should remove curlwrappers from 5.5. I do agree that this
is not yet stable and ready to push as non experimental, but since we plan
to release 5.5 soon I don't think removing it right now is worth it.
I started some time ago to maintain the curl extension. I focused mainly
On Thu, Apr 4, 2013 at 11:27 AM, Pierrick Charron pierr...@adoy.net wrote:
Hi
I don't think we should remove curlwrappers from 5.5. I do agree that this
is not yet stable and ready to push as non experimental, but since we plan
to release 5.5 soon I don't think removing it right now is worth
The main use case was the topic about --with-curlwrappers from Laruence few
days ago.
Actually, for this use case , there is no way to detect if PHP's been
compiled with --with-curlwrappers or not.
The only way to detect this at runtime is to open a socket, then
stream_get_metadata() onto it.
2013/4/4 Hannes Magnusson hannes.magnus...@gmail.com:
stream_wrapper_unregister(http);
stream_wrapper_register(http, CurlStreamWrapper);
and then stream_wrapper_restore(http) to go back to the core streams.
If we alter curlwrappers to work like that, then it could stay, and
since this is an
You're right, struct isn't the right word - value is probably more
accurate.
value Color
{
public $r = 1.0;
public $g = 1.0;
public $b = 1.0;
public function __construct($r, $g, $b)
{
$this-r = $r;
$this-g = $g;
$this-b = $b;
}
public function
28 matches
Mail list logo
