On Mon, Jul 16, 2012 at 10:25 PM, Anthony Ferrara 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
> using a dom based p
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 $legacy.strTopUpper($
Raymond
On Mon, Jul 16, 2012 at 9:30 PM, Raymond Irving 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 case a develop
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 like
Em Tue, 17 Jul 2012 01:27:10 +0200, Andrew Faulds
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, composed of functions and
On Mon, Jul 16, 2012 at 7:27 PM, Andrew Faulds 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 think PHP could benef
On Tue, Jul 17, 2012 at 1:27 AM, Andrew Faulds wrote:
> 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 fun
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 incons
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 { $valu
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 i
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
> misleadin
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
On 16 July 2012 16: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". T
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 cl
On Mon, Jul 16, 2012 at 4:31 PM, Amaury Bouchard 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 syntax for managi
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
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
> 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:
On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard 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 reading, pri
How much syntactic sugar do we really need? Why add two ways to do something?
On 16 July 2012 16:24, Amaury Bouchard wrote:
> 2012/7/16 Nikita Popov
>
>> 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
>>
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] syn
2012/7/16 Nikita Popov
> 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 { ... }
> protected set {
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 unsubsc
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 hid
2012/7/16 Andrew Faulds :
> 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 neutering, it's extending t
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 jus
PHP6 may have exceptions everywhere, but for the moment, do things
like other functions. E_WARNING.
On 16 July 2012 15:05, Anthony Ferrara wrote:
> Nikita,
>
> On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov wrote:
>
>> On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson
>> wrote:
>> > What abou
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov wrote:
> On Mon, Jul 16, 2012 at 8:04 AM, 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 aspec
2012/7/16 Galen Wright-Watson :
> 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.
--
Alex Aulbach
--
PH
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 wrote:
> Hi all,
>
> I jus
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 as
On Mon, Jul 16, 2012 at 3:42 PM, Pierre Joye wrote:
> hi,
>
> On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs 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
> > p
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
> Hi,
>
> The recent
> http://www.mail-archive.com/internals@lists.p
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 wrote:
> Hi Anthony,
>
> Sorry, I'm reall
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 wrote:
> On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs wrote:
>> Hi,
>>
>> The recent http://www.mail-archive.com/internals@lists.php.net/msg59301.html
>> discuss
hi,
On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs 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 attributes (co
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 RFC
On Mon, Jul 16, 2012 at 2:25 PM, Ferenc Kovacs 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 attributes (
On Mon, Jul 16, 2012 at 2:59 PM, Anthony Ferrara wrote:
> Ferenc,
>
> On Mon, Jul 16, 2012 at 8:25 AM, Ferenc Kovacs 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 key
An ugly, confusion-causing syntax.
On 16 July 2012 14:11, Nikita Popov wrote:
> On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard 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 a
On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard 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 attributes
Ferenc,
On Mon, Jul 16, 2012 at 8:25 AM, Ferenc Kovacs 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
C# does this with the readonly keyword, sounds like a good idea.
On 16 July 2012 13:25, Ferenc Kovacs 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
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
On Mon, Jul 16, 2012 at 12:23 PM, Florian Anderiasch
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 parameter a
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, $r
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 wrote:
> On Mon, Jul 16, 2012 at 12:04 PM, marius adrian popa wrote:
>
>> http://morepypy.b
On Mon, Jul 16, 2012 at 6:19 PM, Ferenc Kovacs wrote:
> On Mon, Jul 16, 2012 at 12:04 PM, marius adrian popa wrote:
>
>> 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/commen
On Mon, Jul 16, 2012 at 12:04 PM, marius adrian popa wrote:
> 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/
>
Hi,
intere
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/
Yeah, we could do something like Java: primitive typed and OOP wrapped
types.
On Jul 16, 2012 10:25 AM, "Ralf Lang" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > 1. Change the error handling system from the current E_* system to
> > typed exceptions for everything but advisory er
On Mon, Jul 16, 2012 at 8:04 AM, 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_o
-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 Sat, Jul 14, 2012 at 11:48 PM, Stas Malyshev 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
> actually does is complicat
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 objecti
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
a
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 Runt
57 matches
Mail list logo
