Foo::__set_state(... I would think it'd be easy
enough to strip away the escapes.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AC to secure the data channel. Trivially done in userland.
The next best thing would be an unserialize that would simply fail if a non-whitelisted
class was found.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
AC during encryption of the session data.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
Much agreed. DateTimeImmutable is welcomed as a better design, but it is not a clean
substitute for a DataTime object.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3/21/13 7:37 AM, Derick Rethans wrote:
On Fri, 15 Mar 2013, Steve Clay wrote:
call_user_func() just seems so ugly now that we have nicer syntax in
so many other areas.
That doesn't mean we should just be ripping out functionality that works
perfectly fine.
I was not clear in my in
assume
that it would be supported like other callables...
Anyway, file under Would Be Nice Someday.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
like it.
I do need to use in case my $callable is an object callback.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
perty. The workaround
could be:
($obj->foo)();
call_user_func() just seems so ugly now that we have nicer syntax in so many
other areas.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3/14/13 12:26 PM, Rasmus Schultz wrote:
$user_type = typeof(User);
I missed this. We'll soon have User::class. This may resolve to, e.g.,
'Foo\User'.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
erwise:
class string {}
gettype(new string);
???
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3/14/13 10:31 AM, rene7705 wrote:
(ideally I would like to get a pointer)
PHP's environment is torn down after every request, so no matter what the mechanism you
generally can't store anything that can't be serialized.
See also https://www.google.com/search?q=php+share
On 3/6/13 4:10 PM, Bob Weinand wrote:
https://wiki.php.net/rfc/unset_bool
What's the return value of unset($setValue, $undefined) ?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ata should not be injected into existing vars.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
're sitting in any particular TZ.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to to implement
the damn thing...
Steve Clay
--
http://www.mrclay.org/
On 2/28/13 1:56 AM, Jens Riisom Schultz wrote:
* In response to the argument that php has no assembly concept:
I know this, but namespaces are as close as we get, and would effectively solve
this.
--
PHP Int
On 2/27/13 10:22 AM, Sebastian Krebs wrote:
2013/2/27 Steve Clay
phpDoc already supports "@access private" for items to be left out of
public documentation. An IDE could be configured to have these items appear
greyed or not to appear in autocomplete lists.
a) You misuse th
l access: embrace OOP and eliminate statically
accessible APIs (global vars/funcs and static props/methods) that you don't want people
calling. You don't actually need them. Although closures helped too, PHP gained true
information hiding in 5.0 with "private".
Steve Clay
--
ime served in PECL is essential, they can vote it down. If XCache would be
better, someone could submit an RFC...
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1/29/13 2:17 PM, Jordi Boggiano wrote:
Travis is still running 5.5.0-alpha1 that segfaults under some
conditions when using composer which makes a lot of builds fails for
nothing.
How Symfony deals with this:
matrix:
allow_failures:
- php: 5.5
Steve Clay
--
http://www.mrclay.org
ravis.yml
https://github.com/cakephp/cakephp/blob/master/.travis.yml
https://github.com/auraphp/Aura.Web/blob/develop/.travis.yml
https://github.com/EllisLab/CodeIgniter/blob/develop/.travis.yml
https://github.com/laravel/laravel/blob/master/.travis.yml
...
Steve Clay
--
http://www.mrclay.org/
-
ually handled the call,
the second would have the return value.
* Would it be possible to limit this behavior to a particular scope?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
anywhere
public Bar $bar;
// "read only"
protected Baz? $_baz;
public function get baz { return $this->_baz; }
}
Down the road we could further address how to shorten this syntax but while keeping it
clear that accessors are just functions and properties are just v
varying behavior (e.g.
direct prop read vs. getter call) *depending on the call stack*.
* Giving issetter/unsetter no direct access to the property limits functionality and leads
to weirdness like the example above.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
shows parse errors.
Enforcing syntax is a good thing; Javascript's auto semicolon insertion has led to a
staggering amount of wasted energy in bug fixing, understanding the feature, arguments
about it, and altering code between the two styles. It was a terrible, terrible idea.
Steve Cl
Why we must have parent property access at all? What's the use case and how do
other langs do it?
Am I right to say there is no "parent property", this would just call the
parent's [gs]etter using the same underlying property value?
Steve
--
http://www.mrclay.org/
On Jan 10, 2013, at 6:15 PM,
what we're trying to
do.
Could we not just make it obvious?:
public Foo|null $foo;
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
fields directly from the constructor without
going through property setters.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
rty can be set *back* to NULL (outside the setter).
We could just make the most common case the default behavior. Otherwise the author must
provide the signature of the setter with/without "= null".
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing
Allows "evil", like having reads affect the storage var.
* Allows authors to hang themselves with recursive accessor calls, BUT those
mistakes
would be apparent from looking at the code.
What functionality possible in the RFC would be lost by this?
Steve Clay
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
de.
What functionality possible in the RFC would be lost by this?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Would the following two be exactly functionally equivalent?
public Foo $foo;
public $foo {
get;
set(Foo $value) { $this->foo = $value; }
}
We should also consider how an author would allow type-hinted properties to
accept NULL as a new value, in both proposals.
Steve
--
http://www.mrc
verly complex properties (like
document.cookie) that should really be separate objects. Lets not do that.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
es is always proxied.
Accessors are not required to use the property value, but it always exists.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
mber that traditional syntax only useful for shadow prop.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.
Again, the problem is not shadowing (not even in use here) but really general information
hiding. You c
On Jan 2, 2013, at 10:24 PM, Clint Priest wrote:
> I've updated the Shadowing section of the RFC which I hope clears this up, it
> also includes a slightly modified version of your example at the bottom with
> comments.
Updated RFC really helps. The notion of $this->prop access semantics depend
der:
class Foo {
public $a {
get { $this->a = 1; return 2; }
}
public $b {
get { return $this->a; }
}
}
$foo = new Foo;
$foo->a; // 2 (but shadowed property is 1)
$foo->b; // 1 or 2?
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t;Hours);
$t->Hours; // null
isset($t->Hours); // false
Note these also work as expected when using the default get/set implementations. Of,
course, my implementations don't actually *work* because you can't call an accessor from
an accessor...
Steve Clay
--
http://www.mrcla
should not.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
method names like __setSeconds.
1. Are these names visible via get_class_methods() / method_exists() /
is_callable()?
2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as?
3. What happens if a class/subclass contains a regular method __setSeconds?
Steve Clay
--
http
ion avoids PHP's dilemma of distinguishing prop/method, but fails
because you can't execute an expression:
($o->func)();
Similarly if $a is a Closure, $a() works but ($a)() fails.
If these could be made to work, would it break BC? And *should* they be made to
work?
Steve Clay
--
h
ne writing *new* code will see that feedback immediately.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ethods are
*purposefully designed* to be implemented by the user, I expect users to try this and, if
it works, release code with it.
* I assume one could use them as regular methods?
* call_user_func([$foo, '__getpropName']);
* $foo->{"__get$propName"}
I apologize if these
On 10/20/12 10:45 AM, Rasmus Schultz wrote:
Just drop the idea of read-only altogether, please - it's so marginally
useful in the first place, unconventional compared to other languages, and
Read-only is perfect for value objects, where the alternative is a bunch of protected
props and getters
On 9/19/12 2:01 PM, Andrew Faulds wrote:
Some other ideas:
$cb = (callable) $obj->bar;
Ah, but (callable) that won't work for global functions, since (callable) is a
cast, and
(callable) is not usable as a cast (at least in 5.4.7):
$a = (callable)'str'; // Parse error: syntax error, unexpec
On 9/19/12 1:19 PM, Andrew Faulds wrote:
I completely agree. How about &function_name? Resembles C (function pointers!),
and unless
I'm getting confused, it isn't currently legal syntax for something else.
$cb = & Foo::doSomething;
$cb = & foo_doSomething;
$cb = & $obj->doSomething;
The last
On 9/19/12 9:26 AM, Ivan Enderlin @ Hoa wrote:
callable is already a reserved word (T_CALLABLE).
Oh, good. It's not listed here http://php.net/manual/en/tokens.php
Steve
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On 9/19/12 2:37 AM, Sebastian Krebs wrote:
2012/9/19 Steve Clay mailto:st...@mrclay.org>>
https://wiki.php.net/rfc/__alternative_callback_syntax
reason I like 'Classname::class' for classes) I don't like, that functions will
look like
classes with a static pro
ing
::keyword provided a better path to BC, and more attractive/meaningful syntax.
P.P.S. I'm unaware if it's customary to throttle the release of RFCs, so I apologize for
hogging any attention away from those under discussion.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - P
On 9/18/12 1:55 PM, Stas Malyshev wrote:
Again, nowhere it is said that you can not apply different filters to
different data or different context. Again, you narrow down definition
of filtering, to which I see no purpose unless you seek to arrive at
pre-determined conclusion that we need to dupl
On 9/18/12 7:30 AM, Pádraic Brady wrote:
That's all. The RFC should be self-explanatory and feel free to pepper
...
https://wiki.php.net/rfc/escaper
I like where this is going and agree that PHP officially embracing an API would be helpful
even for users stuck on old PHP versions.
First is
51 matches
Mail list logo
