Hey Rasmus,
You looking for help to build that out? That project looks like
TONS-OF-FUN (r), and I'd be interested in helping out with it. I think
it would be great to see people on there and all the projects they are
associated with, kinda like a socialcoder project ;)
-ralph
Rasmus
Since everyone is in the namespace frame of mind, is there a
possibility of a namespace access modifier?
The way I envision this working is that if for example:
namespace Foo;
class Bar {
nsprotected $_someProperty = null;
}
(or some other equivalent grammer)
Would allow the property
Jeff Moore wrote:
I don't think properties are the appropriate level to specify namespace
based access modifiers. I do think that a coarse-grained access
restriction on a class by class basis might be.
Perhaps you are right, but I was using that as an example. I actually
see great value in
Take this file:
?xml version=1.0 encoding=utf-8 ?
foo
? echo bar; ?
/foo
and run it through xmllint.
Can we now stop this discussion and revert this patch?
Take this file:
?xml version=1.0 encoding=utf-8 ?
foo
?php echo bar; ?
/foo
and run it through your xmllint.
Passes right? Does
(...), then it
should be allowed that the public call to that method be disallowed, but
still allow the magic functionality (b/c of the presence of that magic
function.)
Without getting too long winded, ill just put code and warnings below.
Cheers,
Ralph Schindler
script.php
?php
class SomeMagic
I have to agree here. Is the book already closed on core extensions in 5.3?
-ralph
Cristian Rodríguez wrote:
Michael Wallner escribió:
Hi,
I wonder what the general opinion is on adding pecl/http to the main PHP
distribution? Many people have poked me in the past, so I guessed it's
time to
Mike,
I have a few questions about the API and target use cases. What is the
best medium to ask these questions and document them? This thread
certainly is not the best place im sure of.
Thanks,
Ralph
Michael Wallner wrote:
Jani Taskinen wrote:
So pecl/http is actually ext/curl with OO
While overall solid, I have 1 api critique that may or may not influence
inclusion..
The naming's seem slightly awkward for HttpResponse. Seemingly,
HttpResponse is the compliment to HttpRequest given their namings. But
looking at the api (the fact that its all static methods), it leads me
Hi all,
I'd like to confirm something as a bug and/or design issue.
Currently, its difficult to extend RecursiveFilterIterator() with
additional __construct() arguments (for configuring its behavior). The
reason its difficult is b/c when getChildren() is called, a new instance
of the RFI is
,
Ralph Schindler
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IIRC, Sara created this as a proof of concept to a reoccurring question
of why filesystem functions don't have an include include_path argument.
Many members argued (and for good merit), that any fs operations
should not include the include_path. It was put into trunk and
forgotten about,
to
check for the existence of a relative to include_path location
regardless of autoloading consequences, and that is what sara attempted
with stream_resolve_include_path, even though I'm not fond of the name.
Regards,
Ralph Schindler
Lukas Kahwe Smith wrote:
Ahoi,
I have written an RFC
Bump.
I really think we need to think about this problem that Lukas has
brought up.
Now that the magic words have come up ('counting stat calls'), can we
get someone to weight in on the possibility of both having some kind of
include_path resolver in the 5.3 branch, and it's impact of stat
var_dump(PHP_INT_MAX+1024 PHP_INT_MAX);
bool(false)
~# php -r var_dump(PHP_INT_MAX+1025 PHP_INT_MAX);
bool(true)
Any information would be great.
Thanks,
Ralph Schindler
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Is it still the position of internals that reserved words cannot be used
as method names or class names?
I need this to work
?
class Case
{
/* methods and properties **/
}
but PHP refuses to allow it.
Please tell me someone is listening.
-ralph
--
PHP Internals - PHP Runtime
Stanislav Malyshev wrote:
Is it still the position of internals that reserved words cannot be
used as method names or class names?
Why allow it? It would probably require substantial change in the
parser, and what for?
I guess so that we can have a language that will be able to model real
Instead of reopening a bug report, I figured I'll post it here to get
better exposure. Myself (and a few others at Zend) feel like
http://bugs.php.net/bug.php?id=41253 is most definitely a bug in the
engine as it relates to ext/session.
What is trying to be accomplished is the following: If
Marcus Boerger wrote:
yes
I will submit it to bugs.php.net
in the same manner i guess it makes no sense tocommunicate further? :-)
this is a general consideration, people should stop sending these non
applicable message stubs. They render open source unuseable.
Yeah, as much as I
I've run into this before.. essentially, you can't do that ;)
http://us2.php.net/language.oop5.decon (second note)
Nor, can you throw exceptions anytime after the engine starts shutting down.
-ralph
Jakob Buchgraber wrote:
Okay, I can now reproduce the problem. Here is the code:
?php
class
After all that has been said and done since this post:
http://marc.info/?l=php-devm=118355320225178w=2
Is it safe to say that this functionality laid out is still
representative of what is involved in the namespace patch?
Or, is there a wiki / proposal page somewhere that would better
Stanislav Malyshev wrote:
If PHP team release in the news:
PHP has namespace support!
OR
PHP has package support!
PHP has namespaced package support.
Which, is what the implementation is.
Or worked with different ones enough to understand that packages is
used for a zillion of different
Stanislav Malyshev wrote:
Wikipedia also define the term MVC. But alas, that is a conceptual
definition, not blueprints for implementation.
Who cares about the implementation? It's still MVC. So let's implement
MVC and call it distributed enterprise messaging and then let's spend
next 2
Stas,
Namespace implementations for languages have been around for decades
in one form or another. People use the languages they are used to
developing in to demonstrate their points on how it should work, and
what it should be called when it works a certain way. Its 2007. Given
that we
Hey David Lucas,
I brought this up a year ago on the list here:
http://marc.info/?t=11472819373r=1w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications
---
$class=new class;
with($class)
{
do_something();
do_more();
do();
}
What more value does this hold over implementing fluent interfaces which
are already possible?
Assuming
class Foo {
public function doSomething() { /**code**/ return $this; }
In general, I think it would be nice to have something that does this
for you, but I am not necessarily a fan of changing the meaning of
instanceof.
That's a lot of boilerplate for each possible iteration. This is one reason
people like traits so much, as it's easier to just do automated
Well, I like it at first glance. There are two main problems that I see
with it:
1. It still requires a separate decorator class for every combination of
interfaces you want to decorate. So, for example if you wanted to
decorate a Foo interface, but sometimes it's used with Iterator as well.
Hey Anthony,
There's a lot here, so I'm only going to address a few things.
It sounds to me like you haven't tried to use decorators for any complex
logic. Making it type equivalent leads to very vebose code. And a PITA
I actually have used both Decorators and Proxies (it's cousin) a number
I've started using this extension on a personal project. So far, I
really love it. If the performance aspects of it remain minimal, and
the syntax remains simple/non-complex, I can see this as a component
that would benefit many by being included in core.
-ralph
On 8/23/12 11:16 AM, Pierre
In addition, I think that the hook syntax has to be changed into the
call_user_func one (instead of... $obj-foo() do array($obj, 'foo') )
I think the current syntax is fine. Keep in mind, you can use wildcards
in that syntax, I do in my application, for example:
// before all controller
On 8/26/12 7:21 PM, Rasmus Schultz wrote:
But AOP is just one of many popular techniques that require code
generation. And for that matter, there is an endless number of different
I'm failing to see what code generation you talking about. Could you
elaborate about how AOP and code generation
Hey Stas, et. al.,
I think I've addressed some of your concerns and completed this
feature/patch.
https://github.com/php/php-src/pull/187
More inline ...
But yes, I agree that runtime resolution only duplicates existing
behavior, so it isn't really necessary (you could argue thought that
What I find absolutely confusing is the use of Class vs. CLASS vs. class for
constant names. Let’s limit the translation to FQCN.
I will clean up the proposal make the examples more consistent (all lower
case). It's worth noting though, that this is reusing the reserved keyword
class which
Hi internals!
The ::class resolution proposal had significant discussion in April and
I've updated the patch to address issues that came up then. At this
point, I've gotten some positive feedback from various places and feel
its time to open it up for a vote to internals.
RFC:
I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).
I am not a big fan of the syntax class(ShortClass\Name) as to me it
looks like a function call.
Personally, I like drawing parallels from the same languages that I
think helped shaped
On 9/13/12 3:36 AM, Lars Strojny wrote:
Hi Simon,
Am 13.09.2012 um 10:34 schrieb Simon J Welsh si...@simon.geek.nz:
[...]
I would expect $variable::class to work (like late static bindings).
[...]
Than better try the patch, as it doesn’t work now :)
But it is a good point indeed. @Ralph:
, parent::class not in a class definition
- self, static, parent::class in a method signature
- self, static, parent::class in a method body
- if static parent are runtime, do we return false on misses?
-ralph
On 9/11/12 9:39 AM, Ralph Schindler wrote:
Hi internals!
The ::class resolution
Perhaps get_class_fqn(string:ClassName) ?
Do you propose a function? Because I don't see how it can work as
function - namespace resolution is compile-time.
I personally think we should keep resolutions as much to compile time as
possible.
Your suggestion implies that we now have either a
Hey Stas,
* Here are the edge cases / implementation details that need a decision:
- $variable::class (should it even be supported?)
I don't see it doing anything useful.
I generally agree.
In the current patch, this does not work and would need another run in
the parser.
-
I somewhat agree; using __CLASS__ would make it more obvious that it's
compile-time rather than runtime, IMO.
It's not always going to be compile-time.
For self::class and Foo::class, it will be compile time every time. For
static:class and parent::class, that has to be done at runtime as
,
On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Hi internals!
The ::class resolution proposal had significant discussion in April and I've
updated the patch to address issues that came up then. At this point, I've
gotten some positive feedback from various places
This is one of the main use cases of AOP. Demonstrated by this script:
?php
class Bar {}
class Foo {
public function __construct(Bar $b) {
echo 'instance of ' . get_class($b);
}
}
function doDi($joinpoint) {
// do smart stuff, then call:
Hey all,
An odd problem has cropped up that I think can be solved at the PHP
level. Basically, on Ubuntu (and other distributions), using ssl stream
context with verify_peer = true could potentially fail. This is due to
the fact that OpenSSL, seemingly, only has a compile-time value for
Hey all,
After reading this post (
http://www.reddit.com/r/PHP/comments/13uwgk/phar_performance/ ), and
having my own curiosity of the current state of things, I wanted to dig
in an see what the performance of APC with phar files was.
I've found some oddities in performance, and I am hoping
Hi Steve,
2. C# has no issetter/unsetter.
IMO customizing these functions is completely unneeded for the vast
majority of use cases and could be replaced by simpler logic:
isset($this-prop) calls the getter and compares to NULL;
unset($this-prop) passes NULL to the setter.
I tend to agree
absolutely path
with __DIR__) performs the same as phar (autoloader as stub using
include 'phar://' . __FILE__ . '/' . $fileInPhar).
-ralph
On 11/30/12 8:54 AM, Ralph Schindler wrote:
Hey all,
After reading this post (
http://www.reddit.com/r/PHP/comments/13uwgk/phar_performance/ ), and
having
PHP 5.4 added support for expressions of the kind (new Foo)-bar(), (new
Foo)-bar and (new Foo)['bar'].
I'd like to extend this support to any expression instead of just new.
I like it, we discussed this 2 years ago, could you address my original
use case? Would it work:
$value = ($obj =
I'd missed the significance of the initial thread but the problems of
now documenting these sorts of 'changes' to language does need to be
addressed? HOPEFULLY without forcing 'annotation' on us when there is
I am still working on docs for this, perhaps if docs were not in SVN,
things would
could you ellaborate?
I fail to see why would the choice of vcs would matter in this.
or maybe you are referring to the docbook format?
I'm just out of practice with both SVN and docbook, as such, it's more
of a chore to sit down and write/format/compile documentation than with
I missed this. We'll soon have User::class. This may resolve to, e.g.,
'Foo\User'.
Right, and since the literal/string version of the class is as 1st
class citizen as it could possibly get, it makes it easier for tools
like Studio/Storm/phpunit/etc to do better static analysis of class names.
Hi all,
I'd like to get some closure on this PR:
https://github.com/php/php-src/pull/297
which fixes:
https://bugs.php.net/bug.php?id=60953
I've discussed it in brief with both cjones and lawerence. I don't have
commit karma for the phar extension, so someone will have to merge this
for
Well, since I was the one who posted it
(https://twitter.com/ralphschindler/status/327084619507855361), I'll
further explain it. I realized it was doing this when actually running
this kind of snippet:
http://3v4l.org/ZkE6B
I must have left the public in there when I posted it to twitter.
I think we should look at swapping out the parser for something more
context aware before we start adding more generic keywords that have
global symbol ramifications and has name BC implications.
There is some code (lots?) out there that has:
class SomeClass {
public function resume() {
So, in this example, if, say, bar() throws a SomeException , the code
would then resume and execute baz() after the catch block.
Just presenting the idea here, no RFC actually , I'm collecting
thoughts and notices.
It seems like you want application specific flow control (caller
specific)
While UTC is not *ideal*, I am failing to see why its not a reasonable
default. After all, according to
http://us3.php.net/manual/en/function.date-default-timezone-get.php
If none of the above succeed, date_default_timezone_get() will return a
default timezone of UTC.
If people care about
I've asked previously
(http://marc.info/?l=php-internalsm=132096254304189w=2), but have not
given commit karma for the phar extension. I've fixed a couple of bugs,
and the last one has been sitting in the PR queue for months.
https://github.com/php/php-src/pull/297
I've had a couple of
Anthony,
I like it. The one thing that is lacking in the PHP ecosystem is some
kind of support for a Gentleman's Agreement when it comes to APIs. I
am very much opposed to central bodies of code and/or shared interfaces
(like the PSR-3's et. al.) for seemingly simple and cross-cutting APIs.
...
group of people are mostly solved already). The average framework core-dev
(like Symfony or ZF) isn't going to get *much* benefit out of this either
(it can help in some areas, and they will use it, but it's not solving
major problems). The Drupals, Magentos and Fuel CMS's of the world. The
Well, if he's still up to it I think we should list him as a maintainer.
Ralph?
Yes, I am ready to get back on this horse.
Stas, I will address your questions on my original PR this week, perhaps
we can get it to a place where you can close it out.
-ralph
--
PHP Internals - PHP Runtime
Hi Jean-Sebastien,
I'd say this is a harder-to-grasp concept and leads to this common
misconception.
Have a look here, particularly at my reply in the comments section:
http://devzone.zend.com/article/15273
In a nutshell, ctors (constructors) are not subject to LSP (liskov sub.
principle)
Hey all,
I've spent a bunch of time tracking down this issue (which was
intermittent at best) and have identified the problem and have a patch
for the solution.
Details here: https://bugs.php.net/bug.php?id=60164
The attached patch is against trunk, PHP_5_4, PHP_5_3.
Seeing as though I've
time, I'll request an account.
Thanks!
Ralph
On 11/10/11 1:51 PM, Rasmus Lerdorf wrote:
On 11/10/2011 11:44 AM, Ralph Schindler wrote:
Hey all,
I've spent a bunch of time tracking down this issue (which was
intermittent at best) and have identified the problem and have a patch
for the solution
Maintenance of the Phar extension (bug fixing, documentation fixes, etc)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. Not only is it a BC break, it doesn't
make sense in the context of PHP.
Thoughts?
Thanks,
Ralph Schindler
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Inline...
Honestly, I think __construct should behave like any other method when
specified abstract or via an interface.
Which is not fair to say because constructors are not like instance
methods, they are in fact special, and not just inside PHP (more on
that below).
I know you're
One point that was missed, that I'd like to reiterate is that:
Again, CTOR is not special b/c it's a PHP magic
method its special because it is shares qualities
of being a static method as well as an instance method.
That said, the constructor is not just another instance method.
Hey Pierre,
My perspective and expectations are framed by all sorts of existing
literature as well as the discussions on this list. It saddens me that
you did not address any of the points I've brought up. And, I simply
cannot tell what basis you have for your interpretation and opinion. It
Internals:
Time to summarize.
It is clear to me that internals is divided on this issue. I don't
think it's a large enough issue to drag on, even when I disagree with it
- both theoretically and in practice.
For most OO developer, putting ctors as an abstract or in an interface
would not
Hey all (Filipe),
This was brought up in the thread New dereferencing syntaxes in 5.4.
I too think this would be beneficial:
$value = ($obj = new Foo)-produceAValue();
but the current parser (branch 5.4) doesn't have a rule for this. I've
attached a quick/working patch, but I don't fully
this kind of (expr)- syntax, then it should really
accept *any* expr. But I am not quite sure whether this will work out
easily because in this case we can't be sue that expr is an object
(but maybe it'll be simple, I just don't know).
Nikita
On Wed, Nov 30, 2011 at 7:09 PM, Ralph Schindler
ra
*is* useful for cases like (new
ReflectionClass($class))-implementsInterface('Foo'), where you need
only one single bit of information from a class.
Nikita
On Wed, Nov 30, 2011 at 8:02 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Nikita,
You're completely right about the expanded expressions
I'll respond to all at once ;)
On 11/30/11 1:58 PM, Will Fitch wrote:
If that's the case, then why not just add whatever $options is as a
parameter to your constructor. I'm not totally against this concept,
but this use is moot.
I'm simply trying to find usefulness in the new feature of
At first glance, this is technically impossible, with regards to our
current resolution rules:
http://php.net/manual/en/language.namespaces.rules.php
Assuming you have an un-namespaced:
class Db {
public function __construct() {
$this-conn = new PDO(..);
}
}
and you require this as:
Hey Tom,
An idea, why not overload require/include with a second parameter that
simply enforces an include mode. For example
// in some autoloader (include, requires, and *_onces)
include $pathToFile, INCLUDE_MODE_PHP_ONLY;
This would tell the parser/executor to start in PHP mode and never
autoloaders (as is typical in almost any project that would be
interested in .phpc files in the first place) rather than repeatedly
I am partial to file.p btw.
PHP without the HP, or Hypertext Pre-Processing- whatever that is! ;)
In fact, it could mean PHP without the Html Passthrough. You get
I too am on the fence, but lean more towards not liking it. Here's why:
I'm on the fence about use ((expression) as $foo) -- I fully like the
idea of aliasing closure variables, but still thinking on the expression
syntax. It would be _inconsistent_ with how it works with namespaces
(which
For variables, it's not very useful. For expressions, might allow to
avoid some boilerplate code - for the same reason we allow expressions
in function calls - we might ban that, and have people assign
expressions to variables and then use variables for function calls, but
we recognize it is
I have an account on wiki.php.net (I don't remember signing up on
docuwiki, only the svn account page, but its there already and linked to
my email address on this list.) I can't seem to reset my password.
When I get the email for the password reset, the wiki.php.net page tells me:
*
Hi all,
There are many different use cases were in code we expect classes names
as arguments to functions as fully qualified names. We do this in ZF a
lot with our Service Location and DI components, but also with our code
reflection API, etc. A more interesting use case I would like to
I used to implement `public static function getClass() { return
get_called_class(); }`, so I really like this one, makes it also easier
for IDEs when refactoring code :)
Oh completely, that is one of the major benefits. My current workflow
for refactoring is to refactor with the built-in
One thing I personally dislike in this implementation is the
difference between CLASS and class ... One with and one without
namespaces ...
I am not quite following. There is no functional difference between
class, CLASS, or Class. The parser is case insensitive with
regards to keywords,
Hey Simon,
As the class-definition for Moo is missing, I think it's an empty
class (like Baz) on the root-level defined somewhere else, right?
Otherwise this should do something else than guessing the class-name.
If you look at the patch, this feature is not doing anything PHP doesn't
So, at current, is this small enough for just a pull request, or does
this deserve its own RFC?
-ralph
On 4/14/12 2:50 PM, Ralph Schindler wrote:
Hi all,
There are many different use cases were in code we expect classes names
as arguments to functions as fully qualified names. We do
May I suggest using foo::__CLASS__ instead of foo::class ? It's longer,
but closer to what already exists for this semantic (class name as
string), don't you think ?
As Marco suggested, I think using __CLASS__ would be confusing to some.
__CLASS__ generally means, where you see this,
Hi Nikita,
A quick note on the patch: As the class name is compile-time
resolvable it should in my eyes also be available as a
`static_scalar`, so that it can be used in initialization lists:
public function doFoo($withClass = ABC::class) {
new $withClass; // or whatever
}
var_dump is Moo::CLASS but the symbol Moo does not exist yet, only the
class Foo\Bar\Baz was declared at this point.
It could exist. It could be a class name handled by an autoloader
somewhere else.
This method of class name resolving operates in the spirit of how our
namespace
How would static::class behave ? is it handled by the current patch?
Maybe the test case could be extended to reflect this, and also for
self::class?
Fantastic question. I am unsure how to handle this. Currently, it will
simply resolve those names against the rules (I am sure this is the
Would changing the definition for class_name_scalar be sufficient?
class_name_scalar:
class_name { zend_resolve_class_name($1, ZEND_FETCH_CLASS_GLOBAL,
1 TSRMLS_CC); $$ = $1; }
;
To my eye, this is the least surprising syntax.
As far as I can tell, this rule will not
class won't collide anyways, as it's already a keyword, and you can't use it
in your constant or function names. __CLASS__ has bad connotations for me, as it
resolves to the declaring class normally, not the class invoked.
I tend to agree. __CLASS__ to me belongs to the family of constants
The term 'column' makes a lot of sense for PDO working with database
columns, but there is no concept of a 'column' in the array structure or
PHP as a whole, outside of database related functions.
Actually, while perhaps most of the time a value from a column is what
people retrieving from a
I need to address Stas's concerns.
Is there a particular time frame I should be aware of?
-ralph
On 6/19/12 12:19 PM, Nikita Popov wrote:
On Tue, Apr 17, 2012 at 4:54 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
I've also added an RFC page, any thoughts on improving the RFC
Is there any reason why session_start should be sending a new
Set-Cookie: name=id on each and every session_start call? It seems to
me the original functionality of this function would only send a
set-cookie if a valid session didn't already existed and/or was not
provided by the client.
Is it not possible to run the show create table __ via PDO? I swear I
was able to do this in the past, and for some reason this is not
working. Am I doing something wrong, is this a bug, or is this planned?
Pasted below is the mysql command and result expected, test code, and
its result.
Architectural restrictions aside, is it far off to ask if something like
this could be possible in PHP6:
?
class TestReservedKeywordMethods
{
public $value = 2;
public function isset()
{
if (is_null($this-value))
return false;
else
return
Dovgal wrote:
__isset() and __unset() methods are what you're looking for.
They are available since 5.1.0.
See http://www.php.net/manual/en/language.oop5.overloading.php
On 10.05.2006 21:28, Ralph Schindler wrote:
Architectural restrictions aside, is it far off to ask if something
like
In case you miss it, this discussion is about breakages within the
same major version.
I am talking strictly from a Major Release standpoint, which is why I
titled it PHP6 compiler features...
...
My understanding is that this type of change would be slightly massive
undertaking to the
I have not dug super deep into this problem but it seems as though if I
try to call session_regenerate_id() after having set session.save_path
with custom values, i get an error. My guess is that
session_regenerate_id() is having issues with the save_path var.
This is my test script:
file:
The following script produces a seg fault:
?
$class = new MyClass();
class MyClass
{
public function __construct()
{
$this-_start();
}
public function _start()
{
$this-_myCall();
}
public function _myCall()
{
$this-_start();
}
In the spirit of fopen's optional [, bool use_include_path].. is this
something that can be added to is_readable?
ie:
bool is_readable ( string filename [, bool use_include_path] )
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Sara Golemon wrote:
bool is_readable ( string filename [, bool use_include_path] )
we can always dream ..
I prefer the word mature instead of dream ;)
How about something which will save having to resolve that path twice?
$realpath = stream_resolve_include_path($relativepath);
if
1 - 100 of 151 matches
Mail list logo
