During the flattening process, is a copy made of the trait
code (or bytecode or whatever)?
...
Or is the code shared so the memory use will be roughly the same?
...
I realise the use cases for traits and inheritance are
different, and often the situation will dictate the design,
but sometimes
On 10/04/12 5:42 PM, Stefan Marr wrote:
Hi Ben:
On 10 Apr 2012, at 03:34, Ben Schmidt wrote:
During the flattening process, is a copy made of the trait code (or
bytecode or whatever)?
Thanks to Dmitry, the op_array, i.e., the methods op codes are not
copied but shared between the methods
Hi!
Just a quick question about traits.
During the flattening process, is a copy made of the trait code (or
bytecode or whatever)?
So, if I have
trait A {
// a bunch of methods
}
class B {
use A;
}
class C {
use A;
}
class D {
use A;
}
will I have four copies of A because it has b
On 11/05/11 2:33 PM, Rasmus Lerdorf wrote:
On May 10, 2011, at 21:01, Gabriel Sosa 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
-force_html -dump -nocolo
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. A
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 SIMPLEXML_D
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
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 fu
(I'm not familiar with the setup,
but if I think of something I'll post it).
Regards,
David
On Wed, Apr 27, 2011 at 10:29 PM, Ben Schmidt
wrote:
Just for the recordI didn't say popularity was a reason to use a DVCS.
I said the popularity of DVCSes might cause server stra
now
closed.
Perhaps a solution can be found to even open the door to Mercurial (that is
an excellent place to start with DVCSs because its simplicity and
straight-forwardness) in addition to git in such a way that doesn't stress
the server?.
Regards,
David
On Wed, Apr 27, 2011 at 9:40 PM, Dra
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 bec
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 element
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.
I would expect the children() method to return just the last two elements of
your input XML:
http://localhost/a"; xmlns:ns="http://localhost/a";>
as the last two elements are the only ones in the 'http://localhost/a'
namespace.
No, every element in the document is in the same namespace.
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 Samploniu
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
rray( 'key' => 42, 'other' => 'blablah' );
echo $_GET [ 'key' ];
and it's already available on you current instalation :)
Martin Scotta
On Fri, Apr 22, 2011 at 11:27 PM, Ben Schmidt
wrote:
On 21/04/11 9:56 AM, Arpad Ray wrote:
I must say that t
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 fr
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 doesn't
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 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
$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
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']),
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 i
if it really exist. If error
silencing would be used instead - other errors like file permission errors
could incorrectly be silenced - but $unset_defined specifically checks if
the file exist or not before access. So it could affect the read operation
itself - and I hope that explains why It's
always be people that has some other special
definition of "emptiness" like "array that contains a single null value" and
they
need to write the code that defines that particular comparison anyway.
You can't have a solution that makes everything easier for ever
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 a
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
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 ign
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. Offerin
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;
$
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) ? $x
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 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
$
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 ar
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 re
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
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) in
a short-ternary operation
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:
https://gist.github.c
> 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 'slic
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 not
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 se
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
quote)
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?
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 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 anno
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 i
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
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 eff
probably stay in line with what happens when a
type hint for a class 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
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 w
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é
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 o
On 13/02/11 9:15 PM, André Rømcke wrote:
On Thu, Feb 10, 2011 at 6:25 PM, Ben Schmidt
wrote:
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
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 us
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 si
tin Scotta [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
ly
changing my 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.
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;
't so important, it’s the consistency of the value that's
important. It’s the fact that I've chosen gopher wood and I know that even
though Wood::GOPHER really means "3", I don't have to remember what "3"
represents because I can specifically type that I want g
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.
http://msdn.micro
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 in
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 can
- 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 g
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 inc
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 su
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.
Fo
That is, the array below would have $a, foo, bar, baz, bob, narf, poink,
poink/narf = 8 ZVals? (That seems logical to me because each its its own
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
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 runtime
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
Contr
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 pr
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
ext
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.
I
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 and an
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 b
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
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 {
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-internals&m=129288735205036&w=2
Best regards
Stefan
OK, Stefan, I just got con
Hi, Stefan,
On 3/01/11 8:16 PM, Stefan Marr wrote:
On 03 Jan 2011, at 10:04, Ben Schmidt wrote:
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
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 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 trai
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 'horizo
83 matches
Mail list logo
