On Sun, Jul 15, 2012 at 6:21 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/15/2012 06:03 PM, Anthony Ferrara wrote:
Additionally, DateTime is a class in core. Do any functions throw
exceptions?
Nope, and note that if you call those same DateTime functions
procedurally they don't use
When Adobe moved from Actionscript 2 to Actionscript 3 they placed all
existing functions into a legacy namespace. Similarly, I believe that
may be PHP's best shot for smoothing out the API.
Basically, the current function library is moved to the legacy
namespace. The default setting is
On Sun, 15 Jul 2012 20:59:10 +0100, Paul Dragoonis wrote:
The 4th param to str_replace is a by-ref param, so you can't just
skip
over it, can you ?
I don't think so, but we could make it so that you could by using
optional passing by reference.
--
Gustavo Lopes
--
PHP Internals - PHP
Hi all,
I'm a strict follower of this list and havent posted (as of yet) due to
the fact that i'd like to be in the loop, but am not a C developer... :)
But on this discussion i'd like to give my 2c: As a PHP developer i'd
regret to see yet another function added to the language instead of
Thanks for the comments guys, I like your idea about skipping the
by-ref count parameter.
If the 'default' keyword were to be added in, then you could skip the
4th parameter and add your 5th 'limit' option.
$str = str_replace($search, $replace, $subject, default, 5);
Does anyone have any
On Sat, Jul 14, 2012 at 11:48 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Having the functions to get the images sounds like a good idea, some
sites may want to use them to display the logos. However, I don't think
we should use the same function, as then deciding what the function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
1. Change the error handling system from the current E_* system to
typed exceptions for everything but advisory errors (E_STRICT,
E_NOTICE, E_DEPRECATED). Why? Because the current error system
encourages ignoring or not checking what the error
On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson ww.ga...@gmail.com wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
The ugliest aspects of this idea are the requirement for another function
Yeah, we could do something like Java: primitive typed and OOP wrapped
types.
On Jul 16, 2012 10:25 AM, Ralf Lang l...@b1-systems.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
1. Change the error handling system from the current E_* system to
typed exceptions for everything but
http://morepypy.blogspot.com/2012/07/hello-everyone.html
and the comments
http://news.ycombinator.com/item?id=4241921
http://en.reddit.com/r/programming/comments/wipf2/prototype_php_interpreter_using_the_pypy/
On Mon, Jul 16, 2012 at 12:04 PM, marius adrian popa map...@gmail.comwrote:
http://morepypy.blogspot.com/2012/07/hello-everyone.html
and the comments
http://news.ycombinator.com/item?id=4241921
http://en.reddit.com/r/programming/comments/wipf2/prototype_php_interpreter_using_the_pypy/
On Mon, Jul 16, 2012 at 6:19 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 16, 2012 at 12:04 PM, marius adrian popa map...@gmail.comwrote:
http://morepypy.blogspot.com/2012/07/hello-everyone.html
and the comments
http://news.ycombinator.com/item?id=4241921
To help us in this, there's the PHP Native Interface RFC. It might be
difficult to improve the Zend engine until extensions aren't so
tightly coupled with the Zend API.
On 16 July 2012 11:19, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 16, 2012 at 12:04 PM, marius adrian popa
On 07/16/2012 10:29 AM, Paul Dragoonis wrote:
Thanks for the comments guys, I like your idea about skipping the
by-ref count parameter.
If the 'default' keyword were to be added in, then you could skip the
4th parameter and add your 5th 'limit' option.
$str = str_replace($search,
On Mon, Jul 16, 2012 at 12:23 PM, Florian Anderiasch
flor...@anderiasch.de wrote:
On 07/16/2012 10:29 AM, Paul Dragoonis wrote:
Thanks for the comments guys, I like your idea about skipping the
by-ref count parameter.
If the 'default' keyword were to be added in, then you could skip the
4th
Hi,
The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting the final keywords for
properties as it would provide an easy way for read-only attributes (const
would be a better choice in performance wise, but then you
C# does this with the readonly keyword, sounds like a good idea.
On 16 July 2012 13:25, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting the final keywords for
Ferenc,
On Mon, Jul 16, 2012 at 8:25 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
The recent
http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting the final keywords for
properties as it would provide an easy way for
On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard ama...@amaury.net wrote:
Hi,
Here is an RFC proposal about a syntax extension for PHP. The purpose is to
manage precisely the visbiliy of attributes, by separating reading and
writing access.
First of all, I know there is already an RFC about
An ugly, confusion-causing syntax.
On 16 July 2012 14:11, Nikita Popov nikita@gmail.com wrote:
On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard ama...@amaury.net wrote:
Hi,
Here is an RFC proposal about a syntax extension for PHP. The purpose is to
manage precisely the visbiliy of
On Mon, Jul 16, 2012 at 2:59 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Ferenc,
On Mon, Jul 16, 2012 at 8:25 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
The recent
http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not
On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting the final keywords for
properties as it would provide an easy way for read-only
Hi Anthony,
Sorry, I'm really off topic here. What I suggest here is just to think
about new ways to make PHP more secure - and I think how to work with
errors is an important thing in this case.
It's here, because the password-rfc is just a good example for
security. :) It's not critic to the
hi,
On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs tyr...@gmail.com wrote:
The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting the final keywords for
properties as it would provide an easy way for read-only
In that case, we should use what C# calls it, readonly. Writable
only once by the constructor.
On 16 July 2012 14:35, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
The recent
We shouldn't neuter the language because some stupid people might do
stupid people. Use appropriate error handling, not inappropriate error
handling because it might catch someone out who has a poorly
configured server.
On 16 July 2012 14:40, Alex Aulbach alex.aulb...@gmail.com wrote:
Hi
It could be useful (given the example of Java usage).
But still, if the goal is to have read-only attributes, I think my proposal
(separate reading and writing visibilities) is more precise and powerful.
2012/7/16 Ferenc Kovacs tyr...@gmail.com
Hi,
The recent
On Mon, Jul 16, 2012 at 3:42 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs tyr...@gmail.com wrote:
The recent
http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting
Hi all,
I just want to throw a quick thought in here:
The password API proposal includes a function called
password_make_salt(), that basically creates a random string, either
in raw binary form, or in the bcrypt salt format. Personally I don't
see much use for the function in the salt context
This sounds very useful. To make it easier to use, why not also add
some string constants, something like CHARS_HEX, CHARS_BASE64,
CHARS_DECIMAL, etc? Then you could just do `random_string(24,
CHARS_HEX);` to get a 24-char hex string.
On 16 July 2012 14:54, Nikita Popov nikita@gmail.com
2012/7/16 Galen Wright-Watson ww.ga...@gmail.com:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
I think it makes things more complicated instead of less. For security
simpleness is important.
--
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson ww.ga...@gmail.com
wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw
PHP6 may have exceptions everywhere, but for the moment, do things
like other functions. E_WARNING.
On 16 July 2012 15:05, Anthony Ferrara ircmax...@gmail.com wrote:
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 16, 2012 at 8:04 AM, Galen
I like the concept in principle. But implementing it is non trivial.
First, you need a base-conversion function that will allow you to convert
between arbitrary bases (base_convert() won't work, because it only works
on fixed bases, and on numbers INT_MAX)... Here's a utility class that
does
2012/7/16 Andrew Faulds ajf...@googlemail.com:
We shouldn't neuter the language because some stupid people might do
stupid people. Use appropriate error handling, not inappropriate error
handling because it might catch someone out who has a poorly
configured server.
I think it's not
On 16/07/12 08:04, Galen Wright-Watson wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
The ugliest aspects of this idea are the requirement for another function
(password_set_option?) and hidden
On 16/07/12 16:21, Anthony Ferrara wrote:
If this is something that's desired, I can update the password
implementation to include this change (since it depends on a function like
this internally)...
Anthony
Looks good.
--
PHP Internals - PHP Runtime Development Mailing List
To
2012/7/16 Nikita Popov nikita@gmail.com
I'm not sure I really understand what this adds over the existing
getter/setter proposal. read-only and write-only should cover the most
common cases. If you do need visibility control, it is possible too:
public $property {
get { ... }
You already have the read-only/write-only option proposed on that RFC
- by not defining set and vice-versa for write only - or by inserting
new keywords (not sure if this is needed/optimal).
And nowhere in PHP do we have the syntax you propose as A:B, and I
even recall a short array [a:1, b:2]
How much syntactic sugar do we really need? Why add two ways to do something?
On 16 July 2012 16:24, Amaury Bouchard ama...@amaury.net wrote:
2012/7/16 Nikita Popov nikita@gmail.com
I'm not sure I really understand what this adds over the existing
getter/setter proposal. read-only and
On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard ama...@amaury.net wrote:
Yes, but only if you have to write an accessor.
If you just want an attribute that is:
- readable from everywhere
- writable from the current class only
With my syntax:
public:private $a; (read it aloud public
If you just want an attribute that is:
- readable from everywhere
- writable from the current class only
I believe the RFC sugests:
public $a {
private set;
}
Would be enough, if I understand correctly...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I like it. I've looked in some code and found about 8
password-generation-functions. 4 of them have more or less the same
idea behind.
The rest generates more complicated password. E.g. minimum one
digit, First letter must be alphabetic. This is easy to implement.
Some generate passwords from
My point is not to add two ways to do the same thing.
What I'm humbly suggesting to do is to keep the core idea of the existing
RFC (make things easier when you have to write getters/setters), and think
about another syntax for managing reading and writing visibilities.
2012/7/16 Andrew Faulds
On Mon, Jul 16, 2012 at 4:31 PM, Amaury Bouchard ama...@amaury.net wrote:
My point is not to add two ways to do the same thing.
What I'm humbly suggesting to do is to keep the core idea of the existing
RFC (make things easier when you have to write getters/setters), and think
about another
Are you sure that this mix of distributed visibilities (sometimes before
the attribute, sometimes before a get or set keyword) and new keywords
(read-only and write-only, between the initial visibility and the
attribute itself; but what is an initial visibility exactly?) is really
more clear?
On 16 July 2012 16:32, Alex Aulbach alex.aulb...@gmail.com wrote:
I like it. I've looked in some code and found about 8
password-generation-functions. 4 of them have more or less the same
idea behind.
The rest generates more complicated password. E.g. minimum one
digit, First letter must be
That is already accounted for, both the visibility (what's inside
limits what's before the variable) as well as changing the
write-only/read-only options. If you read the RFC, when extending a
class and adding set method to a member that was read-only, you
overload the read-only setting...
Hence
Hi!
interesting, but am I the only one that we could also boost the performance
of the Zend Engine, if we would throw out everything, except the PHP 1.0
features: functions, arrays, ints, floats and strings
not that we should do that, I just think that the numbers are somehow
misleading.
On 16/07/12 17:32, Alex Aulbach wrote:
I like it. I've looked in some code and found about 8
password-generation-functions. 4 of them have more or less the same
idea behind.
The rest generates more complicated password. E.g. minimum one
digit, First letter must be alphabetic. This is easy to
Hi all,
Has array access been considered for properties? I can see a good use
for this for cross-referencing objects.
class Parent
{
private $_children = array();
public $children {
offsetSet { $value-parent = $this; $this-_children[$key] = $value; }
offsetUnset {
Hi there,
Through its history, PHP has slowly become more object-oriented. PHP
today has classes, interfaces, objects, namespaces, and so on.
However, much of the language's core functionality is entirely
procedural, composed of functions and constants, much of which are
badly organised and
On Tue, Jul 17, 2012 at 1:27 AM, Andrew Faulds ajf...@googlemail.comwrote:
Hi there,
Through its history, PHP has slowly become more object-oriented. PHP
today has classes, interfaces, objects, namespaces, and so on.
However, much of the language's core functionality is entirely
procedural,
On Mon, Jul 16, 2012 at 7:27 PM, Andrew Faulds ajf...@googlemail.com wrote:
Through its history, PHP has slowly become more object-oriented.
While PHP has become more capable for OOP, it has also become more
capable for FP, too. And, procedural programming is still a very
strong influence.
I
Em Tue, 17 Jul 2012 01:27:10 +0200, Andrew Faulds ajf...@googlemail.com
escreveu:
Through its history, PHP has slowly become more object-oriented. PHP
today has classes, interfaces, objects, namespaces, and so on.
However, much of the language's core functionality is entirely
procedural,
On 14/07/12 01:33, Anthony Ferrara wrote:
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a conversation around what 6.0 would
look
Raymond
On Mon, Jul 16, 2012 at 9:30 PM, Raymond Irving xwis...@gmail.com wrote:
Hi Anthony,
Thanks for the feedback. I do get your point about escaping for JavaScript
but the example shown was just to highlight the entity substitution issue
which could lead to unexpected results. In this
Great Idea, would love to see current standard library in a legacy
namespace and a new standard library implemented as methods of
primitive types.
$string = Hello, World;
echo $strong-toUpper(); // HELLO, WORLD
$int = 3;
echo $int-round(2); // 3.0
While still preserving
On Mon, Jul 16, 2012 at 10:25 PM, Anthony Ferrara ircmax...@gmail.com wrote:
This is standard and expected behavior. Since has no special meaning
within a document (outside of an attribute declaration), there is no
requirement to escape it. And the standard practice when parsing XML/HTML
59 matches
Mail list logo
