On 11/05/11 2:33 PM, Rasmus Lerdorf wrote:
On May 10, 2011, at 21:01, Gabriel Sosasosagabr...@gmail.com wrote:
I'm basically using lynx to convert some html into plain text
basically replicating the following command:
*lynx -pseudo_inlines=off -hiddenlinks=merge -reload -cache=0 -notitle
Again, xmlns= puts an element in no namespace. That already works in
SimpleXML. There is no issue here that needs fixing.
IIUC, the OP doesn't want the element to be in no namespace, but wants
it to be in the default namespace, but unprefixed.
I have already laid out my reasons for believing
While I think this would make SimpleXML more stupid, not less, as it
seems braindead to me to allow users to create documents ambiguously
and/or which essentially violate the XML namespace spec, I think the
way to do
Allowing child elements to be unqualified is neither braindead or
ambiguous.
FWIW, I don't see much point in this either, as far as error reporting is
concerned. I think type checking for parameters can provide cheap and useful
validation, as parameters passed in are outside the function's control. But return
values? They are within the function's control, and in most
On 29/04/11 2:10 AM, Alain Williams wrote:
On Fri, Apr 29, 2011 at 01:58:02AM +1000, Ben Schmidt wrote:
If PHP were compiled, not interpreted, i.e. less dynamic, there could be
some benefits, as compile-time optimisations could perhaps be built in, and
validations skipped if they were provably
While I think this would make SimpleXML more stupid, not less, as it seems
braindead to me to allow users to create documents ambiguously and/or which
essentially violate the XML namespace spec, I think the way to do this would be to
define a magic constant and use that. E.g.
const
problem for me, as I have an XML schema that specifies that the
child elements must not namespace qualified.
Is this possible in an XML schema? I don't know much about schemas,
but
...
Absolutely, if the XML schema has the elementFormDefault attribute
set to unqualified, the child elements
Hi!
I realise that at least for now, PHP is sticking with SVN. No problems.
However...I find it much easier to work in Mercurial to put together
patches, find bugs, etc.. And in fact, I find SVN really awkward--I was
on the verge of switching back to CVS when DVCSes such as Mercurial and
Git
I think I agree with all that.
My only thought so far about the load issue is that the load is less the fewer
changesets have to be queried each 'poll', so perhaps it would be good to have a
commit hook in SVN that sends a quick request (without even waiting for a reply)
to Hg/Git scripts
A similar problem regarding attributes, that got classified as a doc bug, but I
don't think is one: http://bugs.php.net/42083
If you're fishing around that area of the code, though, perhaps it is quite
obvious to you where/how a patch should be made?
Ben.
On 27/04/11 9:23 AM, Tom
I would expect the children() method to return just the last two elements of
your input XML:
root xmlns=http://localhost/a; xmlns:ns=http://localhost/a;
elem attr=abc/
elem ns:attr=abc/
ns:elem attr=abc/
ns:elem ns:attr=abc/
/root
as the last two elements are the only ones in the
Looking at this in more detail...I don't think there's a bug here, or a
patch required.
It is not possible to use SimpleXML to add a child element without a
namespace prefix to a parent element that has a namespace element.
Instead, the child element inherits the namespace prefix of the
parent.
Back in PHP4 it was the only way to simulate an static call, but
nowadays it really don't make sense at all.
class Foo {
static function toString(Bar $bar) {
return 'Foo::toString($bar)';
}
function toString() {
return '$this-toString()';
}
}
$foo =
yeah you are right, passing arguments by reference doesn't trigger the
notice, but I'm not sure that it is applicable in our case.
Yeah, it wouldn't help. For instance, 42 or default can't be passed by
reference, so you couldn't actually provide a default value to
coalesce() if you implemented
On 21/04/11 9:56 AM, Arpad Ray wrote:
I must say that the prospect of yet more new syntax is scary. It
really looks like Perl, and I wouldn't have the slightest clue what it
meant if I'd missed the release notes.
I agree it looks a little bit strange. I think that's partly a benefit:
it
What does coalesce() do?
If I'm guessing correctly, would proposal #2 that Rune Kaagaard put up
solve that for you?
https://gist.github.com/909711
Rune's proposal #2, extending func_get_arg(), is impossible to
implement/would not work.
His proposal #3, which is more like coalesce(), suffers
It's good for some situations, but there are plenty more where it doesn't cut it,
e.g. $_GET[?'foo'] $:= get_default_from_db('foo') $: hard-coded.
Ben.
On 23/04/11 12:54 PM, Martin Scotta wrote:
what about something like this?
$_GET += array( 'key' = 42, 'other' = 'blablah' );
echo
On 17/04/11 9:14 AM, Ángel González wrote:
Ben Schmidt wrote:
$var = $arr['key'] ?? : 'empty';
Also note this is possible with the recent proposal Hannes and I were
discussing. It simply looks like
$var = $arr?['key'] ?: 'empty';
The ?[ avoids notices and the ?: works as it always has.
Ben
I believe describing nullness checking as a main issue is a rather
strong assessment.
I don't think so, obviously. :-)
$var = (isset($arr['key'])) ? $arr['key'] : 'empty';
Nullness checking is half of what that code does, isn't it? Otherwise it
would be (isset($arr['key']) $arr['key']),
$var = $arr['key'] ?? : 'empty';
Also note this is possible with the recent proposal Hannes and I were
discussing. It simply looks like
$var = $arr?['key'] ?: 'empty';
The ?[ avoids notices and the ?: works as it always has.
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To
That sounds fine to me, and the extension to ArrayAccess is really
clever. I agree that 'take more care' is a better way to view the array
access. It means both the array access should be more careful (to check
and avoid errors, rather than just proceed), and also the 'caller'
should be more
There was also my suggestion of a checked ternary operator [see my
previous email in this thread.] Backwards compatible, practical, and simple.
It doesn't address the main issues of code duplication and nullness
checking, IMHO, so isn't a contender. Even though it's simple and
compatible, it is
1. Suppression of notice. I agree, it is best done only for array
keys. It's not hard to initialise a variable with $var=null at the
beginning of a code block to avoid such a notice, and that is the
appropriate way to do it for variables.
2. Offering a shortcut for the common idiom isset($x) ?
On 14/04/11 10:08 PM, Jordi Boggiano wrote:
On 14.04.2011 13:58, Ben Schmidt wrote:
I have many, many uses for this. E.g. patterns like this:
class Foo {
private $defaultBar;
public function foobar(Bar $bar=null) {
$bar = isset($bar) ? $bar : $this-defaultBar;
$bar
There are two issues here.
1. Suppression of notice. I agree, it is best done only for array
keys. It's not hard to initialise a variable with $var=null at the
beginning of a code block to avoid such a notice, and that is the
appropriate way to do it for variables.
2.
I cry whenever I see code with @ in it...
I don't like @ either. The whole point of this proposal though is to
offer a safe alternative, a way to suppress only those notices which are
being accounted for by the programmer and no more, without messing
around making a custom error handler that
that you need to refactor your code for a different datatype.
If you cannot change the array, you always can wrap it.
With good data abstractions the usage of array_key_exists/isset/empty is barely
reduced to the minimum.
Martin Scotta
On Thu, Apr 14, 2011 at 10:12 AM, Ben Schmidt
On 15/04/11 12:05 AM, Hannes Landeholm wrote:
Trying to summarize this discussion... I think we can all agree that the
main problem is code duplication for array access when parameters are
possibly not existing.
For me the problem is 'code duplication when a value might be null'
(whether an
for everyone so let's
solve
one thing at a time and start with the most generic problem specifically and not
all minor problems that happens to partially intersect that one.
~Hannes
On 14 April 2011 16:26, Ben Schmidt mail_ben_schm...@yahoo.com.au
mailto:mail_ben_schm...@yahoo.com.au wrote
I think these shortcuts could be really useful for array elements, but
for other variables I am really sceptical and I think they would do
more harm than good. Generally I do not really see any reason why a
variable should not be 'instanciated' before use.
So
+1 if this shortcut is implemented
I think another problem with using @ is that it is done by the caller,
not the callee, so it doesn't allow functions like issetor() to be
implemented in userland without expecting every caller to do pass the
variable while silencing errors.
I also don't think the inconvenience is restricted to
If doing the suppression of undefined notices be better if the ? was put after
the
opening square bracket, thereby removing the ambiguity (which I think would be
more troublesome than you think)? $array[?foo]
I suppose a non-array-specific version would be to put it after the $.
$?variable
On 9/04/11 12:45 AM, Martin Scotta wrote:
I just feels that !empty($arr['key']) or isset($arr['key']) do not express
the real meaning, instead I would choose to write array_key_exists('key',
$arr). It may be slower but it clearly express what I meant.
I don't like this. array_key_exists will
On 8/04/11 4:41 AM, Rasmus Lerdorf wrote:
On 4/7/11 2:30 PM, Rafael Dohms wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au wrote:
On 1/04/11 3:29 AM, David Coallier wrote:
Hey there,
I've been working on a little patch that will allow variables ($1
Good idea. Have you considered how Xdebug does this kind of thing (through
configuration directives, IIRC--I know it uses such things for var_dump) and
whether that might suggest a better or more future-proof approach?
Ben.
On 5/04/11 1:22 AM, Sebastian Bergmann wrote:
string substr( string $string, int $start [, int $second [, int $flag =
SUBSTR_LENGTH ]])
I think this just makes code ugly.
I think a new function with something like 'slice' in it is pretty unambiguous and
unconfusing.
(I also like the current substr() semantics. Actually, I think
On 1/04/11 3:29 AM, David Coallier wrote:
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go through an implicit isset
(zend_do_isset_or_isempty) check so that the average use-case for the
short-ternary operator doesn't yield in a
static $re = '/(^|[^])\'/';
Did no one see why the regex was wrong?
I saw what the regex was. I didn't think like you that it was 'wrong'.
Once you unescape the characters in the PHP single-quoted string above
(where two backslashes count as one, and backslash-quote counts as a
Now, here is a pattern which actually means a quote which doesn't
already have a backslash before it which is achieved by means of a
lookbehind assertion, which, even when searching the string after the
first match, 'str, still 'looks back' on the earlier part of the
string to recognise the
On 15/03/11 2:18 AM, Martin Scotta wrote:
I chose the simplest example to show the preg_replace behavior,
You've GOT to be kidding. The SIMPLEST?!
How about an example that doesn't require escaping ALL the interesting
characters involved?
Here's a modified version that I think it quite a bit
On 15/03/11 5:38 AM, Ben Schmidt wrote:
On 15/03/11 2:18 AM, Martin Scotta wrote:
I chose the simplest example to show the preg_replace behavior,
You've GOT to be kidding. The SIMPLEST?!
How about an example that doesn't require escaping ALL the interesting
characters involved?
Here's
On 14/03/11 8:47 AM, Marcelo Gornstein wrote:
it has already been discussed with length. Please take a look at:
http://wiki.php.net/rfc/annotations
Thank you for the link. That is actually pretty much what I intended
to do. The only difference with my own version lies in the possibility
to
public function Killjoy(MyEnum $x)
What would be the purpose of such code? What would it do if 5 is passed as
$x?
Are you suggesting this as an enum member function, or just a regular
function in any old class?
If 'in an enum', I think by analogy with the stuff somebody linked to on
the MS
Are you suggesting this as an enum member function, or just a regular
function in any old class?
Enum member funcion? How much it should be like a class before you
call it a class?
Exactly. It's crazy. If you want a 'member function' use a class, not an
enum.
use the function: you would
On 13/02/11 9:15 PM, André Rømcke wrote:
On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
On 11/02/11 3:37 AM, Philip Olson wrote:
You now have rights to the wiki rfc namespace.
Thanks a lot, Philip.
I have now made an RFC based on the most recent
That might seem odd but it's not inheritance.
Yeah. And that's my main concern with it. It seems like inheritance (and
is described like inheritance in the RFC at present--which is a
documentation issue that will need to be addressed in the manual
eventually), but it isn't. I feel it should be
http://wiki.php.net/rfc/traitsmodifications
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like 'final'
could also do something special.
André
why not supporting methods for enum values?
developers will need that, and by providing type hinting, they will just
create the logic somewhere else...
why would developers need this? can you elaborate with some real-life
scenario?
I thought enums are just strong-typed constants
I think this
is broken.
-Original Message-
From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
Sent: Wednesday, February 23, 2011 9:01 AM
To: Martin Scotta
Cc: Alexey Zakhlestin; Stas Malyshev; Jarrod Nettles; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Clarification on the Enum language
On 24/02/11 8:33 AM, Stas Malyshev wrote:
Hi!
use the function: you would usually be expected to pass in a true enum
constant of the MyEnum type.
That works wonders in dynamic languages, without any means of really
ensuring it.
No, I believe you can ensure it, and you can even ensure it
I also suggest when type-hinting, if the type is integer or string where
an enum is expected, PHP attempts a cast before failing, to make this
more convenient.
O, and if this cast (or any cast to enum) fails, IMHO, it should replace
it with null. When type-hinting, this means that if null is an
Don't your arguments work equally well against type hinting for objects?
You have the same problems: if you screw something up in user code and
pass the wrong type, it fails at runtime. You also get 'random' failures
if you deserialise/read from config an object whose internal type
changed since
mind and agreeing with the earlier point that methods for enums can
be useful.
What is everyone's opinion on enums as type hinted parameters? Being able to
do...
public function Killjoy(MyEnum $x)
-Original Message-
From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
Sent: Friday
[mailto:martinsco...@gmail.com]
Sent: Tuesday, February 22, 2011 10:25 AM
To: Ben Schmidt
Cc: Jarrod Nettles; Thomas Gutbier; internals@lists.php.net; Stas Malyshev
Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure
I just don't get why no type hinting, I thought that was one
I did some research on methods in enums and discovered that there is
some usefulness to the idea - I wouldn't go so far as to say that they
would be needed, but C#, for example, allows you to create extension
methods for enums and MSDN has a decent real-world example of its use.
.
-Original Message-
From: Ben Schmidt [mailto:mail_ben_schm...@yahoo.com.au]
Sent: Thursday, February 17, 2011 4:52 PM
To: Martin Scotta
Cc: Jarrod Nettles; Thomas Gutbier; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: Clarification on the Enum language structure
Also, I feel like it should
class Grade {
enum {
A_PLUS,
A,
B_PLUS,
B,
...,
FAIL,
NOT_AVAILABLE,
}
public static function passing($grade) {
return $grade=self::D;
}
}
$grade=Grade::B;
echo Grade::passing($grade)?passing:not passing;
Shouldn't that be:
public static function passing($grade) {
-return $grade=self::D;
Also, I feel like it should be restricted to integral types only, and
defaults to a zero-based incrementing integer. This is more in line with
other programming languages that already implement enums and will present
expected behavior for people moving over to PHP.
for me that's a plain old
On 11/02/11 3:37 AM, Philip Olson wrote:
You now have rights to the wiki rfc namespace.
Thanks a lot, Philip.
I have now made an RFC based on the most recent discussions:
http://wiki.php.net/rfc/traitsmodifications
I think this is a more solid proposal than my original one, and I hope
we
- Don't write long e-mails to a mailing list, write an RFC
http://wiki.php.net/rfc?do=register
OK. I tried to do this. I got an account (username:isfs), but it seems
it is nothing more than an unprivileged account--I don't seem to be able
to edit or add pages at all. What do I need to do to be
Yes, I think it's dangerous to change the default display precision
lest we have a ton of applications that currently show 0.2 showing
0.20001.
Exactly. And remember, PHP output is not necessarily just for web pages
for humans to read. Other apps may rely on parsing this data, etc.,
On 4/02/11 3:30 PM, Chris Stockton wrote:
Hello,
I haven't seen a magic method proposed in a while so I am not sure how
people feel about them, obviously adding them can break BC (although
it is recommended people should not use __). I'm sure a good amount of
use/desire needs to be shown for
On 30/01/11 4:11 AM, Adi Mutu wrote:
I have looked at the sources, but i'm only at the begining of
analyzing the php sources.i've understand how to write extensions
for example, but this memory manager seems more complicated to me.
Yes, it is. Memory management is a low-level and
On 20/01/11 6:05 AM, la...@garfieldtech.com wrote:
So it sounds like the general answer is that if you pass a complex array to a
function by value and mess with it, data is duplicated for every item you modify
and its direct ancestors up to the root variable but not for the rest of the
tree.
Strongly second this. PHP is not a toy language restricted to beginners. If it has
advanced features, beginners simply don't need to use them.
If anything, I would argue that PHP is a language unsuited to beginners (and other
scripting languages), as it is so flexible it doesn't enforce good
On 19/01/11 3:51 PM, Stas Malyshev wrote:
Hi!
If anything, I would argue that PHP is a language unsuited to beginners (and
other
scripting languages), as it is so flexible it doesn't enforce good programming
practice. Java is much more a 'beginner language' because it has much stricter
It does the whole of $b. It has to, because when you change 'baz', a reference in
'bar' needs to change to point to the newly copied 'baz', so 'bar' is
written...and likewise 'foo' is written.
Ben.
On 19/01/11 5:45 PM, Larry Garfield wrote:
Hi folks. I have a question about the PHP
variable that just happens to be an array, but I want to be sure.)
--Larry Garfield
On Wednesday, January 19, 2011 1:01:44 am Ben Schmidt wrote:
It does the whole of $b. It has to, because when you change 'baz', a
reference in 'bar' needs to change to point to the newly copied 'baz', so
'bar
I think doing something like this is a good idea for classes and
interfaces.
Ben.
On 7/01/11 1:16 AM, Martin Scotta wrote:
Yes, my intention was to only add a magic constant with the class, similar
to this
namespace Bar {
class Foo {
const KLASS = __CLASS__;
}
}
namespace Buzz {
Hi, Jonathan,
On 7/01/11 4:42 AM, Jonathan Bond-Caron wrote:
- New ideas are always welcome
That's great to hear!
- Don't write long e-mails to a mailing list, write an RFC
http://wiki.php.net/rfc?do=register
Sure. Once I've digested and responded to Stefan's replies, I'll work on
putting
Hi, Stefan,
Thanks for considering my ideas so carefully and for your detailed
replies.
The reason to go with insteadof is that the assignment syntax hides
changes that might cause problems.
Thus, when you change any of the traits participating in a composition
in a way that a conflict would
Hi again, Stefan,
Continuing the conversation.
On 7/01/11 10:18 AM, Stefan Marr wrote:
On 02 Jan 2011, at 13:16, Ben Schmidt wrote:
Extension
- - - - -
I suggest these two problems can be simply solved by introducing two
additional uses of the trait keyword: as a scoping keyword
Hi, Stefan,
I think if the other stuff goes ahead, we can probably scrap what I
originally proposed here. But perhaps something else would be helpful. I
won't comment very specifically on aspects of my original proposal, but
will just raise some new ideas for consideration and further thought.
In fact, this is so nice, could I suggest it would be nice to allow
other delegation-like forwarding to be done like this? You could have
'use' without a trait even, just like this:
use {
$queue-add as addToQueue;
}
Since the properties' object wouldn't be available at compile time, this
Hi, Stefan,
Sorry, I do not understand.
Haha. Now we are both confused!
In this email thread you seemed to be saying that properties defined in
traits are completely ignored, but in the RFC and svn it seems to be
saying that properties in traits are not ignored, but are merged into
the class
On 3/01/11 8:57 PM, Stefan Marr wrote:
Hi Ben:
On 03 Jan 2011, at 10:35, Ben Schmidt wrote:
OK. So this comment from your email is outdated?:
Yes, outdated since this email:
http://marc.info/?l=php-internalsm=129288735205036w=2
Best regards
Stefan
OK, Stefan, I just got confused
Hello, PHP developers,
I'm new to the list, but have been using PHP for a number of years, have
done a little hacking in the source code, and have an interest in the
development of the language.
Particularly recently I have been reading with a good deal of excitement
Stefan Marr's RFC on
On 3/01/11 2:24 PM, David Muir wrote:
On 12/12/10 01:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a
78 matches
Mail list logo
