It would theoretically be:
$fn = MyController::myAction(...);
It currently errors:
Fatal error: Uncaught Error: Non-static method MyController::myAction() cannot
be called statically
I would be okay with allowing this, as long as it's bound before it's called.
Could we do this
It would theoretically be:
$fn = MyController::myAction(...);
It currently errors:
Fatal error: Uncaught Error: Non-static method MyController::myAction() cannot
be called statically
I would be okay with allowing this, as long as it's bound before it's called.
One other question
This RFC uses a syntax that is forward-compatible with partial function
application. Should it not be accepted, I'll explore alternative syntax
possibilities.
Given the choice of syntax in this proposal (which I do like)... Is the
following (potentially future) use case precluded by the
If you want to ignore arguments in excess, your function may have a rest
parameter collecting them. The following will run without error:
```php
function foo($c, $a, ...$unused) {
var_dump($a, $c);
}
$args = [
'a' => 'the a value'
, 'b' => 'the b value'
, 'c' => 'the c
What I don't understand is what the issue with that is?
You can already build up a named array and splat it into a function call to
pass by name. It's a really neat trick. It doesn't need a dedicated function.
About a month ago, I went through all of TYPO3 and removed all remaining
(Jump to bottom for alternative suggestion that achieves same goals)
Just to make sure I got this right: call_user_func_map() is the same as
call_user_func_array(), but a) only accepts named params
Yes, only accepts named parameters (associative array),
and b) silently ignores unknown
The short proposal:
Make a variation of this work (notice parameter order and 'b' is goes
unused):
call_user_func_map(
fn ($c, $a) => var_dump($a, $c),
[
'a' => 'the a value',
'b' => 'the b value',
'c' => 'the c value'
]
);
// string(11)
d this get to
the voting phase.
I have reasons for why I chose my initial path, but its worth mentioning
I favor the optional value at the end maybe 65% to 35% where the value
is after the initial keyword.
Thanks for taking the time!
-ralph schindler
--
PHP Internals - PHP Runtime Developmen
iate the
aesthetics and clarity of intent of code,.. and having seen this is some
places in the wild already I feel are successful, I personally feel its
a good thing to perhaps to run through the RFC process for inclusion in 8.
Thanks!
Ralph Schindler
--
PHP Internals - PHP Runtime Development Mailing
which is definitely
arguable. But we do have multiple ways of achieving this.
Of course all of these things should be discussed, I think sub-votes
(should this PR make it that far) could be considered.
The PR is located here:
https://github.com/php/php-src/pull/5552
As mentioned, some discussio
just return $string, to be consistent with usual behavior of
"::CONST_NAME", which allows objects and class names on the left hand side.
Having given it more thought, it seems like like $string::class should
be more aligned with get_class($string), which at current throws a PHP
Warning
Along those lines, is there any consideration of adding ::interface and
::trait, where applicable?
How would this be applicable?
In the context of variables, an object can be only of a single class
type, whereas it can be an *instanceof* multiple interfaces (or an
extension of other
Another small RFC, to allow $object::class syntax:
https://wiki.php.net/rfc/class_name_literal_on_object
Hi Nikita,
Glad to see enhancements to ::class. Open questions, given:
class Foo {}
$foo = new Foo;
echo $foo::class; // Foo
$fooClass = Foo::class;
echo
Hi all,
I was hoping someone with considerable pctnl authority/knowledge might
be able to help shepherd this bug fix along. In short, I came across
this bug combining the technologies of Laravel's job worker
infrastructure (uses signals) along with using the Microsoft provided
SqlServer
On 6/25/18 9:13 AM, Johannes Schlüter wrote:
On Mo, 2018-06-25 at 12:30 +, Zeev Suraski wrote:
3. Foreign Function Interface support.
Related to this on a non-PHP-code and strategic matter I would like to
rethink PECL. Currently maintenance and installing extensions using it
is a pita.
On 3/8/16 11:59 AM, Midori Kocak wrote:
Remember my question?
$this->request->data['comments']['user_id'] =
$this->request->data['comments']['user_id'] ?? ‘value’;
I want to check if some var is null and if the same var is null set the same
var to ‘value’.
Hence I am repeating the same
Stas + Tjerk,
is called, it's in isset expression context somewhere upstream?
While it may be nice in theory, in practice I'm not sure it's doable -
or worth making doable.
Thanks for your input, I suspected there was a certain complexity I was
not immediately seeing.
-ralph
--
PHP
Hi all,
I am conflicted as per if what I experience in this code should be
throwing a notice in E_STRICT:
http://3v4l.org/srm5f
?php
error_reporting(E_ALL);
$foo = ['bar' = ['baz' = 5]];
$bar = ['box' = 'baz'];
// this will Notice: Undefined index: boom
?php
namespace foo;
function bar(){}
var_dump(bar::class); // string(7) foo\bar
?
This was not explained in the RFC at all, and had I known this I would
have voted against it personally.
How would you suggest it be different, if not a compile-time name
expansion for classes?
On a
2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
I'll grant you the consistency argument. I'm all for consistency, but
that's the ONLY valid reason you've stated.
Even then I think this part of the argument is fairly weak. In
Bar::class, the context of Bar is
About $php_errormsg , we have error_get_last().
About $http_response_headers, we have no replacement.
Why not get rid of both ?
I agree. Magically appearing variables are bad design and if we can get
rid of them, PHP 7 is the time.
--
Stas Malyshev
smalys...@gmail.com
did we miss the
I recently stumbled over that issue, too; thanks for looking into it.
Looking at the patch, it seems, that some handling for bzip2 archives is
missing; I think if there are special cases for .tar, .tgz and .zip,
there should also be a case for .tbz2 (.tar.bz2).
Yep, I discussed this with a
hi all,
Phar::convertTo*() methods have a design flaw such that phar files can't
be successfully converted and retain the proper file suffix at the same
time when the base name contains dots. An expression of this is
attempting to convert something-v3.0.0.phar to say a tar.gz via
1. We aimed for maximum readability. The block syntax delimited with
bracket `{` ... `}` pairs is definitely easier to keep track in
comparison with a colon and semicolon `:`...`;`
2. A block delimited by a double colon and a semicolon `:` `;` is NOT
yet part of any structure from the PHP.
You could very well argue that this is what relative syntax is for:
use PhpParser\NodeVisitorAbstract;
use PhpParser\Error;
use PhpParser\Node;
use PhpParser\Node\Stmt;
use PhpParser\Node\Expr;
then foo(Expr\New_ $expr)
That is even more readable and cleaner to read.
+1
The current
On 2/3/15 3:33 AM, Julien Pauli wrote:
On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs tyr...@gmail.com wrote:
About $php_errormsg , we have error_get_last().
About $http_response_headers, we have no replacement.
Well, we sort of do. You can get header information from the http
context
without perhaps conjuring magic variables into the beloved local scope?
Thoughts?
Ralph Schindler
PS Also, do we have any other local-scope variables like this?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?
PUT /url
Content-type: application/x-www-form-urlencoded
parse_str (file_get_contents(‘php://input'), $_POST) // Ok
PUT /url
Content-type: multipart/mixed; boundary=
Hi!
On 5 August 2014 18:01, Ralph Schindler ra...@ralphschindler.com
wrote: At the risk of stating the obvious, can’t you just use
$f-bar-__invoke()?
Actually, it was not immediately obvious that __invoke() was a
method from the docs as it is a side-note and not in the class
signature
() {
echo 'hi'; return function () {
echo ' world';
};
});
$f-bar-call();
// if you must change context:
$f-bar-bindCall($otherContext);
Thanks,
Ralph Schindler
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
At the risk of stating the obvious, can’t you just use $f-bar-__invoke()?
Actually, it was not immediately obvious that __invoke() was a method
from the docs as it is a side-note and not in the class signature
breakout. Oops! ;)
http://php.net/manual/en/class.closure.php
That said, call()
This works as expected for 99% of applications.
Or you could say that it fails for 1%
I was that 1% for a long time without any indication of what was wrong,
and its a very un-googleable problem. I even bugged the Console2
development folks, they had no answer for me as everything
http://news.php.net/php.internals/23254
-ralph
On 9/16/13 7:53 AM, Bob Weinand wrote:
Hi!
This is the (official) RFC thread for the patch proposed in
http://php.markmail.org/message/7rn4mbwkbytqa3ig
https://wiki.php.net/rfc/keywords_as_identifiers
Any feedback about the RFC or 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
...
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
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.
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
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 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)
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.
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
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.
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
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 =
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
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
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
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
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:
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
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.
-
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:
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
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
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
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
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 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 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
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
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
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
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,
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 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
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
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:
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
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
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 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
. 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 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
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 Kiall,
An optional argument to the built in web server can be a php based
router. If the router returns false, it will attempt to return the
resource as-it-is on disk.
Your command line looks like this:
php -S localhost:8000 -t ./path/to/docroot routing.php
routing.php can be one of
1 - 100 of 151 matches
Mail list logo
