I've been thinking about this RCF for a while now:
https://wiki.php.net/rfc/trailing-comma-function-args
It just doesn't seem necessary - the only time I've ever found something
like this to be necessary, is when a function takes closures or other very
long arguments, some of which are
This is a not a feature request, just a note on something that occurred to
me.
Since there is talk of native support for annotations again, it occurred to
me that part of the problem that every userland implementation and proposed
syntax deals with, along with native implementations in other
it here, and then we can discuss it...
Anthony
On Tue, Jan 29, 2013 at 8:03 AM, Rasmus Schultz ras...@mindplay.dk
wrote:
I just saw this RFC:
https://wiki.php.net/rfc/foreach-non-scalar-keys
By non-scalar, presumably we're talking about objects? In the numbers
that e.g. resources
. resources, but
you could put your resources in an object and address that (very exotic)
need.
Bottom line, I'm not in favor of this idea - it just doesn't seem necessary
or really even beneficial to me.
- Rasmus Schultz
yours, and that's not necessarily something we should need to
agree upon.
Is it really the responsibility of the language to deliver high-level
features that support patterns?
Or should it deliver simpler features that support the implementation of
those patterns?
- Rasmus Schultz
at 5:29 PM, Rasmus Schultz ras...@mindplay.dkwrote:
I hear a lot of interesting arguments in this big annotation discussion,
and now there's the ongoing vision discussion, which got me thinking.
It is true that there is broad community interest in annotations - part of
the problem here
I'm going to address these question in the proposal I'm working on - once
it's all in writing, I will post for debate.
On Wed, Jan 9, 2013 at 2:57 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
- Should we support nested annotations?
- How [Foo()] will be different from new
I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?
e.g. thinking of concrete
To summarize:
A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API, and
already goes as deep as it needs to - going beyond simply finding and
extracting the docblocks would make little sense, as every annotation
agree and
would like to work on a new RFC.
- Rasmus Schultz
Isn't this need basically covered by accessors?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
- Rasmus
On Sat, Dec 1, 2012 at 7:53 PM, internals-digest-h...@lists.php.net wrote:
From: Sebastian Krebs krebs@gmail.com
To: PHP internals list internals@lists.php.net
Cc:
I second getting rid of write-onle - the only real case I can think of, is
something like a password property on a user/account model-type, which gets
encrypted and thus can't be read, and as Amaury pointed out, that should be
a setPassword() method instead, perhaps even a separate
Since there's a heavy debate on the list about strong typing right now, I
just want to briefly share my point of view.
PHP is not and won't be a strongly typed language. What it can be (and is
on the way to be, with Clint's work) is a language that supports
type-checking. Not the same as strongly
There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't
seem to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;
public $hours {
get() { return
Just a couple of quick remarks.
Clint wrote:
I'm not even sure that automatic backing fields are even desired, I never
felt the need to have them in C# and the only reason they were included is
because they were a part of Dennis's original proposal.
Automatic backing fields are indeed
This looks great, and essentially has everything I had hoped for!
My only remaining comment is on the read-only and write-only keywords...
this seems really superfluous and strange to me - the syntax (using a
hyphenated keyword) and the feature itself, is way off the grid as compared
to other
Yeah, on that note - I've never understood what use this function is,
as it reuses object IDs... it will return the same hash for two
different objects during the same script execution - so it's unusable
as far as getting unique keys for objects... and I don't know what
else you could really use
the manual states, The implementation in SplObjectStorage returns the
same value as spl_object_hash() - so I don't know how this would
really work any better than a custom implementation.
perhaps safer would be to simply implement a collection-type that
requires the classes of elements in the
perhaps the worst case of misleading user comments to date... ;-)
On Sun, Oct 7, 2012 at 7:51 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
On Sun, Oct 7, 2012 at 7:12 PM, Rasmus Schultz ras...@mindplay.dk wrote:
the manual states, The implementation in SplObjectStorage returns the
same value
Since I was the one who started this discussion, I'd like to reply to
some of these points.
First off, let me say - as you pointed out, when the values are
unique, they are best represented
as keys... however, this of course applies only to value-types, which
isn't the problem, and not
why I
posting this for
debate.
Thanks,
Rasmus Schultz
Good point - I agree. Thanks for taking the time to think about this!
On Tue, Sep 18, 2012 at 12:22 PM, jpauli jpa...@php.net wrote:
On Tue, Sep 18, 2012 at 5:14 PM, Amaury Bouchard ama...@amaury.net
wrote:
Sounds to me like aspect-oriented programming, applied to object
construction.
Interesting technique:
http://ayende.com/blog/158721/rule-out-the-stupid-stuff-first-select-still-ainrsquo-t-broken
I wonder if this is applicable to PHP in any way? Would stream buffers
benefit from something like this?
Perhaps not, I just thought it was interesting enough to share - it's not
?
On Fri, Sep 7, 2012 at 1:12 AM, Pierre Joye pierre@gmail.com wrote:
On Fri, Sep 7, 2012 at 3:09 AM, Rasmus Schultz ras...@mindplay.dk wrote:
Jannik,
Thank you - this confirms I'm not crazy, or at least it's evidence to
support that theory ;-)
It may be OS specific - perhaps
I opened this bug report 2 years ago:
https://bugs.php.net/bug.php?id=52756
Is GD still actively maintained?
If it isn't, then perhaps it's time to start thinking about switching to a
graphics library that is maintained?
Perhaps something more modern with real drawing capabilities and a better
Jannik,
Thank you - this confirms I'm not crazy, or at least it's evidence to
support that theory ;-)
It may be OS specific - perhaps the Windows and OSX binaries are built
against a different build (or configuration) of FreeType?
Or it could be specific to 32 or 64 bit builds.
I have never
Having thought about this for a while, I think this is a bad idea - here's why:
$array = array(1001, 1002, 1003, 1004);
$number = $array[-1]; // = 1004
$number[-1] = 1005;
$number = $array[-1]; // =
Obviously, the last statement must return 1005, since otherwise that
Kovacs tyr...@gmail.com wrote:
On Fri, Aug 31, 2012 at 3:14 PM, Rasmus Schultz ras...@mindplay.dk wrote:
Having thought about this for a while, I think this is a bad idea - here's
why:
$array = array(1001, 1002, 1003, 1004);
$number = $array[-1]; // = 1004
$number[-1] = 1005
On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen pe...@likipe.se wrote:
I know very little about AOP and don't pretend to know a lot, but how
would we benefit
from directly adding it into core instead of taking the approach FLOW3 did?
as I see it, the problem with AOP in PHP is the same as
wrote:
That's why I thnk the extension is superior to all other solutions,
because it doesn't require code generation in userland. Also, it will be
possible to backtrace to the declaration of the aspects.
2012/8/26 Rasmus Schultz ras...@mindplay.dk
On Thu, Aug 23, 2012 at 7:36 AM, Peter
:
On 16.08.2012, at 0:18, Rasmus Schultz ras...@mindplay.dk wrote:
How come there is no straight-foward obvious way to simply remove a given
value from an array?
Well, this sounds like a reason for creating SplSet class
Absolutely, you're right. I have a tendency to get dragged into those.
I apologize.
On Fri, Aug 17, 2012 at 5:50 PM, Nikita Popov nikita@gmail.com wrote:
Could we please stop these pseudo-arguments?
I have a login (mindplay) but I do not have permission to post or edit
anything on the wiki...
On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch willfi...@php.net wrote:
Please let this die until someone is serious enough to come up with an
rfc. This has been nothing but counterproductive arguing.
/321ad9b4b8c4e1713488
On Mon, Aug 20, 2012 at 10:10 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
2012/8/21 Rasmus Schultz ras...@mindplay.dk:
I have a login (mindplay) but I do not have permission to post or edit
anything on the wiki...
I've created RFC for this
https://wiki.php.net
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
I disagree - this is (or should be) a simple, atomic operation...
yet, you've got a function-call, an intermediary variable, a boolean test,
and an unset statement repeating the
.
And it doesn't help make codebases more legible when people come up with 25
different ways to do it.
On Fri, Aug 17, 2012 at 5:23 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 08/17/2012 05:21 PM, Rasmus Schultz wrote:
if(($key = array_search($del_val, $messages)) !== false) {
unset
How come there is no straight-foward obvious way to simply remove a given
value from an array?
Just look at the number of horrible ways people solve this obvious problem:
http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key
Shouldn't we have something simple, like:
Is this all the documentation there is for the use-clause for
anonymous closures?
http://us2.php.net/manual/en/functions.anonymous.php
For one, it would be nice to have documentation that explains whether
the variables listed in the use-clause are copied/referenced at
declaration-time or at
Is this RFC outdated?
https://wiki.php.net/rfc/jsonable
We have JsonSerializable in 5.4 - this appears to be essentially the same thing?
(Should it be moved from draft to implemented, or should it just
be removed? It was not implemented with the names used in this RFC.)
I was also looking at
I was doing some work with the Reflection API, and I ran into something
missing from ReflectionParameter.
Turns out, there's no way to get the class-name of a parameter, short of
calling getClass() - the problem with that is, there's no way to get the
class-name of a parameter without causing the
using this particular version-numbering scheme, 1.01 is equal to 1.1 - I
don't think that's a bug, because the version-numbers in this
version-numbering scheme are integers, not decimals.
so I believe this is in fact as correct as it can be, since numbers like
01 should not really be used in this
writing their own...
- Rasmus Schultz
1.0.0 and 1.0 are different things.
I think the problem is, version numbers are different things to different
people - I guess the documentation maybe isn't clear enough on precisely
what version numbering scheme it's using. To most people, 1 and 1.0 are
the same thing, because they look like
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
?php
define('NUM_TESTS', 1000);
$before = memory_get_usage(true);
$test = array();
class Foo
{
public
Adding/removing properties at runtime is great if you want obscure,
unmaintainable code and don't think an IDE is useful.
So to make my previous statement more precise, dynamic properties are
not widely used in respectable modern codebases, and is generally
something a reputable developer would
Subject: Re: [PHP-DEV] memory usage ouchy
On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz ras...@mindplay.dk
wrote:
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
[snip]
The test-script contains
On Tue, Apr 24, 2012 at 10:10 PM, Anthony Ferrara ircmax...@gmail.com wrote:
There's already an __isset() magic method that does exactly this:
http://us2.php.net/manual/en/language.oop5.overloading.php#object.isset
I know.
In my opinion, that was a mistake, and if I catch anyone on my team
I agree, overloading isset() for properties is somewhat creepy - as
that would mean you can no longer rely on isset() to actually work the
way it works for any other value. I understand that's actually the
intent, but I think this would be confusing - isset() is supposed to
behave a certain way
On 04/10/2012 06:20 PM, Adir Kuhn wrote:
PHP Gotchas, how they came to be, and why we can't simply fix them
can't or won't?
It seems that the requirement for backward compatibility, as with most
software, stands in the way of any substantial leaps, and makes it
impossible to do away with
From: Arvids Godjuks arvids.godj...@gmail.com
To: Kris Craig kris.cr...@gmail.com
Cc: PHP internals list internals@lists.php.net, Yasuo Ohgaki
yohg...@ohgaki.net
Date: Fri, 13 Apr 2012 03:26:16 +0300
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
Well, I just
2012/4/5 Anthony Ferrara ircmax...@gmail.com:
Why not just do:
function foo(callable $callback) {
$a = 0;
$callback();
$a = 1;
$callback();
}
function bar() {
foo(function() { echo 1; });
}
It's functionally the same, but doesn't have the stack magic.
Now, it won't
, reeze reeze@gmail.com wrote:
If just for exception recovery how about implement ruby's retry ?
http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement
section.
在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：
I was just reading about the new async/await keywords in C# 5.0
I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...
What if you could resume execution after an exception was thrown?
Fictive example:
function test()
{
echo Begin Test!\n;
throw
Just a couple of quick notes...
I think that your proposal looks good, but I'd like to suggest a few
changes. First of all, I'd like to see the association with integers
removed. An enum instance shouldn't just be a name for an integer, it
should be more like a singleton instance of a special
A couple of quick comments...
Why can't the read-only and write-only keywords be implicit instead of
explicit? I've never seen another language where you have to explicitly
indicate what you're doing. At best, it acts an extra fail-safe to prevent
making errors - at worst, it just means more
On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest cpri...@zerocue.com wrote:
The read-only and write-only keywords act a little differently. Without
them, attempting a set on an accessor without a setter defined will cause
__set() to be called whereas with the read-only it will produce an error.
aspects of PHP that need attention...
2012/1/29 Johannes Schlüter johan...@schlueters.de
Hi,
On Sun, 2012-01-29 at 18:51 -0500, Rasmus Schultz wrote:
I realized the other day that ReflectionFile is missing from the
Reflection
API.
As is ReflectionNamespace and some others one might think
to implement this feature in different ways...
2012/1/30 Johannes Schlüter johan...@schlueters.de
On Mon, 2012-01-30 at 09:33 -0500, Rasmus Schultz wrote:
From my point of view, the concept of a file has become semantically
more
important, and increasingly relevant to Reflection
an
annotation. Neither approach is very elegant. This is addressed by the
language, by allowing you to import classes and interfaces - annotation
libraries could discover imported annotation types this way, but that
aspect of the source code is not exposed via Reflection.
Any thoughts?
- Rasmus
Hello Folks,
We're hosting an increasing number of Drupal (ick) sites on our servers,
and while going over the diagnostic screen for APC, we noticed that
identical files are being cached multiple times.
For example, user.module is cached 3 times for 3 sites.
I've seen other people asking this
You want to compare Mono performance to .NET performance - I'm sorry, but I
don't see how that's even relevant?
Your benchmark would be relevant if I was proposing you write a PHP
interpreter and run that on Mono.
What I'm proposing (and what Phalanger does) is to compile PHP code to CLR
understand the licensing may be an issue. It may be the argument that
outweighs everything else, but I'm curious to hear what else would keep you
from moving to Phalanger?
Thanks!
- Rasmus Schultz
identifying it as
an accessor I'm saying be creative - don't just implement something
halfway for the sake of getting it done.
On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote:
if we're attempting to get around __set/get, let's not replace them with
more method implementations
I
On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps christian.k...@mohiva.comwrote:
Hi,
I also find this syntax confusing and I think it has a huge WTF factor.
Some thoughts about the syntax:
- At the first glance, it isn't clear which visibility the getter or
setter has
- The extra
2011/12/4 Clint M Priest cpri...@zerocue.com:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the object and the system looks for those
functions and calls
who can hook me up with a login, so I can contribute to the documentation?
Here's a better example of something useful that actually works:
Assuming your example is OK, you could edit the doc and submit it as a
patch at https://edit.php.net.
will help us all better to understand
what the underlying issues/conceptual problems are we need to tackle,
either by improving the current implementation and/or documentation.
On 11 Nov 2011, at 17:00, Rasmus Schultz wrote:
class Cart
{
public static $instance;
# public function addItem
It seems to me, there's a couple of things related to traits that were
missed in this implementation.
Take the following example:
?php
header('Content-type: text/plain');
class Cart
{
public static $instance;
# public function addItem(CartBehavior $item, $amount=1) // = script
terminates
a thought - just throwing it out there for discussion, I'm not
submitting a complete RFC at this point :-)
/ Rasmus Schultz
On Sun, Aug 14, 2011 at 6:44 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Aug 15, 2011 at 12:11 AM, Rasmus Schultz ras...@mindplay.dk
wrote:
Instead of trying to figure
/dispatcher might need to
autoload action-filters, etc.
Just a thought :-)
/ Rasmus Schultz
,
Rasmus Schultz
201 - 271 of 271 matches
Mail list logo
