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.
I
发自我的 iPhone
在 2013-4-4，16:36，Leigh 写道：
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 a feature
that
On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins 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
> zend_bool
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 wrote:
> On Wed, Apr 3, 2013 at 9:43 PM, Joe Watkins wrote:
>
>> Hi Sara,
>>
>>
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 from
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? -
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?
If
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 ma
-- 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
Cc:
I really don't understand the problem. You have a DateTime instance, you
manipulate it as you see fit, and o
On Thu, 04 Apr 2013 19:13:54 +0400, Rasmus Schultz
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
works as you woul
Hi
2013/4/4 Julien Pauli :
> 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 should stick
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 runti
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 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 words:
No, it c
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 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
Joe Watkins 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 required in
On 04/04/2013 06:30 PM, Johannes Schlüter wrote:
Joe Watkins 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.
Th
2013/4/4 Madara Uchiha
> 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 value
types. Even i
On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins wrote:
> On 04/04/2013 06:30 PM, Johannes Schlüter wrote:
>
>>
>>
>> Joe Watkins 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
>>> bett
On 04/04/2013 07:04 PM, Kris Craig wrote:
On Thu, Apr 4, 2013 at 10:40 AM, Joe Watkins wrote:
On 04/04/2013 06:30 PM, Johannes Schlüter wrote:
Joe Watkins wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose tho
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
On Thu, Apr 4, 2013 at 11:27 AM, Pierrick Charron 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 it.
>
> I sta
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.
Som
2013/4/4 Hannes Magnusson :
> 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 experimental featu
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 func
On Thu, Apr 4, 2013 at 9:52 PM, Hannes Magnusson
wrote:
> Its not only about maintaining it.
> This experiment failed a long time ago. Overwriting the core streams
> has proven itself to be the wrong way.
I cannot agree more.
> If there was a way for userspace to say "overload with curl" then t
29 matches
Mail list logo
