Re: [PHP-DEV] - True Annotations
Hi, I agree here, I think the above, if possible would be best. In my mind annotations should proabably be limited in scope to class declarations and thus only before a class keyword, before a property or method declaration. In none of those scopes would [ ] be a parsing issue I believe... The one case would be at the beginning of a class, but if simply added something such as: [:SomeAttribute(xyz,abc),SomeAttribute2] It could never be confused with short array syntax and is still brief. I think when implementing real annotations, then it should be possible to declare arrays in it. So I think the square brackets don't work. [Foo([1,2,3])] Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] - True Annotations
Am 09.01.2013 13:03, schrieb Yahav Gindi Bar: On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps christian.k...@mohiva.comwrote: Hi, I agree here, I think the above, if possible would be best. In my mind annotations should proabably be limited in scope to class declarations and thus only before a class keyword, before a property or method declaration. In none of those scopes would [ ] be a parsing issue I believe... The one case would be at the beginning of a class, but if simply added something such as: [:SomeAttribute(xyz,abc),**SomeAttribute2] It could never be confused with short array syntax and is still brief. I think when implementing real annotations, then it should be possible to declare arrays in it. So I think the square brackets don't work. [Foo([1,2,3])] Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php But the colon prefix won't cover this case? You can, as I've mentioned in my post at the doc-block parser discussion, use a keyword inside the brackets to symbolize annotation, for example [metadata: Key] [metadata: MaxLength(10)] [metadata: Relations([foo, bar, baz])] public $id; Then rather [@Foo([1,2,3])] if it's possible! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and type hinting
Hi
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
You are trying to take typing way beyond what PHP (or probably any
mainstream dynamic language that exists now) provides. There are
languages which provide static type systems capable of doing such
things, but PHP isn't one of them and I don't think it should be. PHP
has no static type control, and IMHO doing type safety validation at
runtime does not seem to be a good proposition for PHP.
I thought it would be a good idea to make the closure functionality
consistent with the rest of the language. Because closures are currently
implemented as class. And with classes it is possible to define static
type checks at runtime. The other thing is that I can define a static
type control for closures. It works only the other way around. Because
the caller can define the static type control and not the interface
designer.
$closure = function(Foo $foo, Bar $bar) {};
function execute(Closure $closure) {
$closure(1, 2);
}
execute($closure); // PHP Catchable fatal error: Argument 1 passed to
{closure}() must be an instance of Foo, integer given
Normally as interface designer I would like to define what a caller of
the interface should be passed to a certain method. Yes I know with
primitive types, this isn't possible in PHP. But with closure I have the
option to restrict the interface. Sure I can do this only for one type
of a closure. Quasi the the smallest common denominator. But it's possible.
So when we look at the above example then it throws an error, because
the caller passes the wrong type of a closure to the interface. But what
is wrong, I have passed a closure to the method! So it seems that the
interface lies. And for me this is the inconsistency in the
implementation. I cannot tell the caller, what type of closure he must
pass to the interface. And yes, for me a closure can be of a different
type. If closures have different parameter signatures than they are of a
different type.
But this is only my subjective opinion. And I'm guessing by the
reactions of my post that I'm all alone with it (o;
Cheers,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and type hinting
Am 12.10.2012 23:06, schrieb Nikita Popov:
On Fri, Oct 12, 2012 at 10:58 AM, Christian Kaps
christian.k...@mohiva.com wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request $request, Closure $onFound);
}
An implementation of the interface could be as follows:
class BrokerImpl implements Broker {
/**
* @var Service
*/
private $service = null;
public function scan(Request $request, Closure $onFound) {
if ($request-contains('some value')) {
$onFound($this-service);
}
}
}
The problem is that I can pass every closure to the scan method.
$broker = new BrokerImpl();
$broker-scan($request, function() { /* do something */ });
Sometimes I would like to restrict the closure passed to this method. So
that only closures of a certain type which has an argument Service
$service could be passed to this method.
$broker = new BrokerImpl();
$broker-scan($request, function(Service $service) { /* do something */ });
Would it not be possible to extend the Closure class and then define an
abstract method signature for the __invoke method.
class OnFoundClosure extends Closure {
public abstract function __invoke(Service $service);
}
And then you can define the interface as follows:
interface Broker {
public function scan(Request $request, OnFoundClosure $onFound);
}
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
Please also don't forget that PHP doesn't have strict function
signatures. E.g. you can write
function($foo) {
echo $foo;
}
but you could also write
function() {
$foo = func_get_arg(0);
echo $foo;
}
So I'm not sure just how much sense function signature checking makes in PHP ;)
Nikita
What did you mean with strict function signatures?
Is this not a strict function signature?
function(Foo $foo) {}
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closures and type hinting
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request $request, Closure $onFound);
}
An implementation of the interface could be as follows:
class BrokerImpl implements Broker {
/**
* @var Service
*/
private $service = null;
public function scan(Request $request, Closure $onFound) {
if ($request-contains('some value')) {
$onFound($this-service);
}
}
}
The problem is that I can pass every closure to the scan method.
$broker = new BrokerImpl();
$broker-scan($request, function() { /* do something */ });
Sometimes I would like to restrict the closure passed to this method.
So that only closures of a certain type which has an argument Service
$service could be passed to this method.
$broker = new BrokerImpl();
$broker-scan($request, function(Service $service) { /* do something */
});
Would it not be possible to extend the Closure class and then define an
abstract method signature for the __invoke method.
class OnFoundClosure extends Closure {
public abstract function __invoke(Service $service);
}
And then you can define the interface as follows:
interface Broker {
public function scan(Request $request, OnFoundClosure $onFound);
}
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi,
typehinting should definitely be available for this feature. But I have
another question. Why not go more consistent with the rest of the
language? I have mentioned this previously as the first proposal comes
up on the list. In my opinion the AS3 getter and setter
syntax(http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb)
fits more into the language as the proposed one.
Here are my concerns:
- I do not like the extra indentation level and it's ugly to document
(OK, this is a personal preference)
- It isn't possible to declare a private setter and a public getter, as
it is possible with methods
- If we ever get return type hinting/checks then we needn't consider
how the syntax has to look
- We must deal with two different syntaxes for the same thing, because
both are methods
- IDE's, documentation tools, static analyses tools or similar tools
have a huge effort to implement this syntax. With the method syntax it's
only a small effort
- We have to create new rules about how the documentation for this
syntax should look like
For me the following syntax seems more consistent with the rest of PHP:
public get hours() {}
public set hours(DateTime $dateTime) {}
public isset hours() {}
public unset hours() {}
Or:
public function get hours() {}
public function set hours(DateTime $dateTime) {}
public function isset hours() {}
public function unset hours() {}
Or:
public function get $hours() {}
public function set $hours(DateTime $dateTime) {}
public function isset $hours() {}
public function unset $hours() {}
Cheers,
Christian
Am 09.10.2012 05:08, schrieb Jazzer Dane:
While I understand your concern with set being the only keyword using
(),
and even agree it's a bit problematic, I see a big problem with using
$value.
Even if $value internally makes sense due to something along the
lines of *
__setHours($value)* {} being equal to *set {}*, I think using $value
without it ever being defined in the developer's code is not at all a
good
idea.
If I see $value in the code, I'll logically look for where it was
defined,
and when I don't see it anywhere else in the code, things are going
to very
quickly get confusing.
Our best option to combat this confusion is, in my eyes, putting a
note in
the documentation. That's not enough.
A similar alternative to using $value that I'd argue would be much
more
sensible would be to, as Denis mentioned, use either a magic constant
or a
superglobal.
As I mentioned previously, I would rather go with the set($value) {}
syntax.
Now, back to the part where I agree with you - the inconsistency
wherein
set has () that denote it is a method but get, isset, and unset do
not. I
see this inconsistency as something problematic enough to warrant a
solution.
We could go with the following:
public $Hours {
get() { ... }
set($value) { ... }
isset() { ... }
unset() { ... }
}
Yes, we now have a little bit more meat on the syntax, but in this
case, I
don't think that it's all that bad. Here's two reasons why:
1) Adding parenthesis denotes that they are all functions - which
they are!
If anything, adding parenthesis to all of them makes the
implementation *
more* sensible.
2) It's *only* two more characters per function. On top of that, in
my
opinion, this syntax is not ugly. In fact, as I just mentioned -
this
implementation is arguably *more* consistent with the rest of PHP.
On Mon, Oct 8, 2012 at 6:10 PM, Clint Priest cpri...@zerocue.com
wrote:
Seems a fair amount of people would like it with a definable
parameter
name, though the original RFC I based mine off of is more than 4
years old
(mine is over a year old already).
The $value is precisely chosen because it is exactly the way C#
operates
and the original author thought to keep it the same as another
well-known
language (why re-invent new syntax for no reason).
That being said, javascript does indeed allow it, my concern then
would be
would we have the parameterized syntax only for set() and not get,
isset or
unset?
If we do have them for all of them, it's a lot of extra characters
with no
real need.
I definitely favor set($value) over a magic $Hours for the $Hours
property, but I personally see no problem with the $value, it's not
magic
it's a locally defined variable.
Internally, this:
public $Hours {
get { ... }
set { ... }
}
Is implemented as standard functions, while they are hidden through
reflection, these functions exist (as a result of the above
example):
public __getHours() { ... }
public __setHours($value) { ... }
Lastly, with regards to JavaScript style getters/setters, I don't
think
I've ever cared what the variable name was, I typically just do
something
like:
set blah(x) { ... } -- x is fairly irrelevant and similarly the use
of
$value is fairly irrelevant. Thoughts?
-Original Message-
From: Jazzer Dane
Re: [PHP-DEV] Bug 55544
Hi, comments inline. Am 17.07.2012 18:57, schrieb Stas Malyshev: There's no version 5.4.4-1. The patch was 85a62e9086db7a8ddfcda4ab1279a2439935f8d5 merged but since then there were other changes to the code. Mike, could you please check if we have a regression there? OK, someone in the bug report refers to this version. Christian, if you are seeing the error again, please reopen the bug and add information about what you are seeing, with which code and on which OS, environment, etc. I'm not the original author of the bug report, so I can't reopen it. But there exists an open bug report for the same issue. So I will comment on this report. https://bugs.php.net/bug.php?id=62335 Thank you for your effort. Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug 55544
Hi, please can someone look into this issue. It seems that in version 5.4.4-1 the bug was fixed, but in newer versions this issue still exists. So please can someone merge the patch with the newer versions? https://bugs.php.net/bug.php?id=55544 Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
Am 18.04.2012 09:18, schrieb Ferenc Kovacs: On Wed, Apr 18, 2012 at 12:54 AM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); Implementation of it is here: https://github.com/smalyshev/php-src/tree/skip_params All things described in RFC seem to be working, please tell me if I forgot anything. If it's accepted I'll also add tests, etc. of course. I would prefer Named parameters, but this is still better than the current situation. Every time a new language construct is proposed, the first arguments against are: - This is confusing syntax - It is hard to read - And so one Stas, and I think you are one of the core developers which raises his voice as first, against new language constructs. And now you propose such a construct. But the best is you show the optimal solution(named parameters) for this problem in your post, and suggests this proposal as work around for it. So if this proposal gets implemented and maybe in the future named parameters gets also implemented. Have we then two solutions for this problem. Or does we revert your current proposal. Sorry, its not against you but for me it seems more as a quick shot. Just my 2 cents Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Am 09.03.2012 09:42, schrieb Gustavo Lopes: That said, I think we could move to a mild BC breaking change for php-next that would make zpp stricter (with or without user-land scalar type hinting/coercion). A big +1 from me for this change. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
Am 09.03.2012 09:41, schrieb Arvids Godjuks: Overall good job. I would prefer it a little stricter like people already mention, but it's a step forward definitively with witch I'm totally fine to live with. Same from me. Good job. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in
PHP. As a userland developer it would help me to write clean and more
robust code. But I think this proposal is only a workaround to get a
round the main problem. It's a try to push similar functionality into
PHP without breaking BC. I think it's the wrong way.
Anthony, You addressed one of the main issues in your last post.
Again, I personally see casting data-loss a bigger issue than just
parameter hinting, which should get its own RFC to clean up. That's
why I didn't include it here. On purpose...
Why not try to change this first?
I know there are more issues to solve. But I think only solving issue
piece by piece, regardless if BC breaks, brings a robust and clean
implementation of this feature. Not immediately, maybe in the next major
version.
Just my 2 cents.
Christian
Am 07.03.2012 08:31, schrieb Stas Malyshev:
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and
rather confusing, I really wouldn't like to have such syntax in PHP.
Also (int) $foo = “1” will generate an E_COMPILE_ERROR makes no
sense to me.
Also, this line:
function test((int) $intParam, (string) $strParam = foo, (array)
$array) {}
is not proper PHP code - it contains optional parameter and then
parameter with no default.
And can we please stop using word hinting?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion
But I don't see how there's any hinting involved.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP-FPM and max_execution_time
Hi, before I submit a Bug report I wanted to validate if it's a bug or not. I try to increase the max_execution_time for a test script. What I have done is to set php_admin_value[max_execution_time] = 100 in the config for my pool. The phpinfo() output shows this value for max_execution_time. But the scripts displays an Internal Server Error after 30 seconds. The Apache has no limit sets. Here is the simple script: ?php sleep(40); phpinfo(); The Apache logs prints: FastCGI: comm with server /home/christian.kaps/fcgi.sock aborted: idle timeout (30 sec) FastCGI: incomplete headers (0 bytes) received from server /home/christian.kaps/fcgi.sock Some settings: PHP 5.3.10 on Gentoo Linux request_terminate_timeout = 0 Are there any gotchas which I haven't observed? Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP-FPM and max_execution_time
Hi, Am 07.03.2012 13:32, schrieb Antony Dovgal: On 03/07/2012 03:47 PM, Christian Kaps wrote: The Apache logs prints: FastCGI: comm with server /home/christian.kaps/fcgi.sock aborted: idle timeout (30 sec) FastCGI: incomplete headers (0 bytes) received from server /home/christian.kaps/fcgi.sock http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidiotimeout ? The error in the *Apache* logs kinda means the Apache has hit a timeout, not PHP. offtopicUgh.. nice anchor/directive name, Apache guys./offtopic -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP Thanks, this points me in the right direction. The problem was the -idle-timeout property for the FastCgiExternalServer directive. http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Scalar Type Hint
Hi internals,
someone in the Return Type Hinting for Methods RFC thread had the idea
of a numeric type hint. I will capture this idea and propose a
scalar type hint. I understand the problem of the current discussion
about scalar type hints(int, float, string, double, ...). But there
should be a possibility to define a scalar type hint to restrict
arguments to scalar types.
function setName(scalar $name) {}
class Foo {
public function __toString() {}
}
setName(1) // pass
setName(true) //pass
setName('Christian') // pass
setName(new Foo) // pass
setName(array()) //fail
setName(new stdClass) //fail
Why this isn't possible?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Patch: getters/setters syntax Implementation
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 indentation level makes the code more unreadable
class Foo {
/**
*
*/
private $_bar;
/**
*
*/
public $bar{
/**
*
*/
set {
if ($bar) {
$this-_bar = $bar * 12;
} else {
$this-_bar = 0
}
}
/**
*
*/
private set {
if ($this-_bar === null) {
return 0;
}
return $this-_bar;
}
}
/**
*
*/
public function baz() {
}
}
- What about type hints?
I prefer a more AS3 like getter and setter syntax.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f30.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fcb
Have you read my previous mail http://news.php.net/php.internals/56762.
I think this syntax fits more to PHP because its similar to the already
existing(magic) getter and setter syntax.
What do you think?
Christian
Am 06.12.2011 04:23, schrieb Clint M Priest:
I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax
The first public would apply to either of the get/set which did not
have it further defined, for example:
public $Hours {
get { ... }
private set { ... }
}
Also, with automatic implementations (at present) the parent access
level controls the automatic property generation:
private $Hours {
public get;
public set;
}
Would define an internal variable of $__Hours as private. Perhaps it
should always be a private internal variable, it was not designated
in
the rfc and I made it this way to be the most flexible for the
author.
-Original Message-
From: Rasmus Schultz [mailto:ras...@mindplay.dk]
Sent: Monday, December 05, 2011 5:11 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: Patch: getters/setters syntax Implementation
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 them at the appropriate time.
Example:
class z {
public $Hours {
public get { return $this-_Hours; }
protected set { $this-_Hours = $value; }
}
}
Defines:
$o-__getHours();
$o-__setHours($value);
You forgot to declare the backing field z::$_Hours in this example.
From a semantic point of view, I find it misleading to first declare
$Hours as public, then lowering the bar by making the set-accessor
protected.
The most common use-case for accessors is public - so I would suggest
a syntax more along the lines of this:
class z {
private $_hours;
get $hours { // accessor is public by default
return $this-_hours;
}
protected set $hours {
$this-_hours = $hours; // local variable $hours is the new value
}
}
And perhaps a short form for added convenience, where the
backing-field is automatically added for you - e.g.:
class z {
get $hours { // accessor is public by default
return $value; // $value provides access to the backing field
(same way $this provides access to the object context)
}
protected set $hours {
$value = $hours; // local variable $hours is the new value,
$value references the backing field
}
}
thoughts?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: getters/setters syntax Implementation
Hi,
why not creating a more function like syntax for this feature. In my
opinion it looks more cleaner particularly when using more than one line
in a setter or getter. The other thing is that you can use type hints
with this syntax.
As example:
class Foo {
private $bar;
public set bar(Bar $bar) {
$this-bar = $bar;
}
public get bar() {
return $this-bar;
}
}
Christian
On 04.12.2011 15:09, Clint M Priest wrote:
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 them at the appropriate time.
Example:
class z {
public $Hours {
public get { return $this-_Hours; }
protected set { $this-_Hours = $value; }
}
}
Defines:
$o-__getHours();
$o-__setHours($value);
Standard __get()/__set() functionality checks for the more specifically defined
function name and calls them. I thought this would make the most sense since
it would allow us to leverage the existing inheritance functionality. This
comes out with respect to interfaces and traits in that only errors had to be
changed (for clarity) on interfaces and no changes to traits were necessary to
support the new functionality.
For the automatic get/set functionality, I essentially built the function body
myself within zend_do_end_accessor_declaration(). One point of contention here
is that internally it defines a __$Hours property which would be accessible
from various points. I believe the standard C# get/set does not allow any
access to the underlying data storage. In order to accomplish that there would
need to be some non-standard storage or a super-private level or something. I
did not explore that possibility as of yet.
I did add a couple of convenience functions that may already be available in
some other form I was not aware of, such as strcatalloc or MAKE_ZNODE().
--Clint
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, December 04, 2011 4:50 AM
To: Clint M Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation
hi Clint!
Thanks for your work so far!
On Sun, Dec 4, 2011 at 1:33 AM, Clint M Priestcpri...@zerocue.com wrote:
What are the next steps to get this added to some future release?
Let discuss the implementation and how it works, then you can move to the
voting phase. There is no need to hurry as the next release where this patch
could go in is next year.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.
Mike
Hi,
how would you bring your application in a consistent state after a
class couldn't be loaded. I do this by adding a try/catch block around
my code.
try {
new Application();
} catch (Exception) {
// collect data
// send mail
// redirect to maintenance page
}
An other question is, if the autoloader work silent and I write:
new NotExistingClass();
I think in this case the engine will also trigger a fatal error. So in
my eyes it is regardless of whether it trigger a fatal error in the
autoloader or the autoloader works silent. Both cases ends in a fatal
error. Or am i wrong here?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Am 25.11.2011 09:55, schrieb Sebastian Bergmann: Am 25.11.2011 09:06, schrieb Christian Kaps: Or am i wrong here? Yes you are. The idea is that you can have multiple autoload callbacks which are invoked in sequence. The first one that is able to load the requested class will end that sequence. If you throw exceptions in one autoloader that sequence will be interrupted prematurely. For this reason I have written the RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Hi,
comments inline.
Am 25.11.2011 09:56, schrieb Sebastian Krebs:
Hi,
Just to throw my 2 cent in: Im with Micheal. An application, that
tries to
access a class, that doesn't exists, is broken and a FATAL is valid.
This
application doesn't need try-catch, but a bugfix (and if it is
already
released: A better testing management).
How you will be informed about that the application breaks? OK, you can
do this with a good log management tool or a log server. But the easiest
way is to write a mail. An other problem is that the user sees mostly a
white page on a fatal error. An other advantage of the exception
approach is that you can collect data from session, from request or from
server and send this with the mail. With a fatal error this isn't
possible.
Your objection with the test management is valid. But I'd rather be
insured against all accidents.
The problem is that the engine allows to throw exceptions. So either we
need a solution to handle all cases or it shouldn't possible to throw
exceptions. The particular approaches shouldn't be the problems here.
On the other side an application, that makes use of dynamic class
names
should make use of class_exists() in any case. An exception after
calling
class_exists() is just bad, but the classloader cannot distinguish
between
the reasons, why it is called.
2011/11/25 Christian Kaps christian.k...@mohiva.com
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/**autoloader_error_handlinghttps://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.
Mike
Hi,
how would you bring your application in a consistent state after a
class
couldn't be loaded. I do this by adding a try/catch block around my
code.
try {
new Application();
} catch (Exception) {
// collect data
// send mail
// redirect to maintenance page
}
An other question is, if the autoloader work silent and I write:
new NotExistingClass();
I think in this case the engine will also trigger a fatal error. So
in my
eyes it is regardless of whether it trigger a fatal error in the
autoloader
or the autoloader works silent. Both cases ends in a fatal error. Or
am i
wrong here?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Am 25.11.2011 10:34, schrieb Rafael Kassner:
I think an autoloader can't be raise any kind of error. If the class
will be loaded by another autoloader on the stack and the first
throws
an Exception, this will be a wrong behavior.
Indeed, if autoloader can't include the class, PHP throws a fatal
error, and you can avoid it using class_exists function that calls
autoloader by its own.
You can do this, but the engine triggers still a fatal error. The call
new NotExistingClass(); triggers the autoloader. The autoloader sees
that the class doesn't exists and continues silent. And now the engine
tries to instantiate a not existing class, which ends in a fatal error.
On Fri, Nov 25, 2011 at 6:06 AM, Christian Kaps
christian.k...@mohiva.com wrote:
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.
Mike
Hi,
how would you bring your application in a consistent state after a
class
couldn't be loaded. I do this by adding a try/catch block around my
code.
try {
new Application();
} catch (Exception) {
// collect data
// send mail
// redirect to maintenance page
}
An other question is, if the autoloader work silent and I write:
new NotExistingClass();
I think in this case the engine will also trigger a fatal error. So
in my
eyes it is regardless of whether it trigger a fatal error in the
autoloader
or the autoloader works silent. Both cases ends in a fatal error. Or
am i
wrong here?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Atenciosamente,
Rafael Kassner
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.
But I use also similar calls to reformat error messages.
try {
$class = new ReflectionClass($annotationName);
} catch (ClassNotFoundException $e) {
$message = The annotation class `{$annotationName}` cannot be
found; ;
$message .= called in DocBlock for:
{$this-context-getLocation()}; ;
throw new ClassNotFoundException($message, null, $e);
}
How would you write the above example without the exceptions? Maybe
your solution is smarter then mine.
Am 25.11.2011 11:00, schrieb Rafael Kassner:
If your autoloader throws an exception, you need to try/catch entire
application. It doesn't sounds useful. On my view, if you want to be
mailed about an autoloader fail, this have to be coded inside of your
own single autoloader.
On Fri, Nov 25, 2011 at 7:46 AM, Christian Kaps
christian.k...@mohiva.com wrote:
Am 25.11.2011 10:34, schrieb Rafael Kassner:
I think an autoloader can't be raise any kind of error. If the
class
will be loaded by another autoloader on the stack and the first
throws
an Exception, this will be a wrong behavior.
Indeed, if autoloader can't include the class, PHP throws a fatal
error, and you can avoid it using class_exists function that calls
autoloader by its own.
You can do this, but the engine triggers still a fatal error. The
call new
NotExistingClass(); triggers the autoloader. The autoloader sees
that the
class doesn't exists and continues silent. And now the engine tries
to
instantiate a not existing class, which ends in a fatal error.
On Fri, Nov 25, 2011 at 6:06 AM, Christian Kaps
christian.k...@mohiva.com wrote:
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.
Mike
Hi,
how would you bring your application in a consistent state after a
class
couldn't be loaded. I do this by adding a try/catch block around
my code.
try {
new Application();
} catch (Exception) {
// collect data
// send mail
// redirect to maintenance page
}
An other question is, if the autoloader work silent and I write:
new NotExistingClass();
I think in this case the engine will also trigger a fatal error.
So in my
eyes it is regardless of whether it trigger a fatal error in the
autoloader
or the autoloader works silent. Both cases ends in a fatal error.
Or am i
wrong here?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Atenciosamente,
Rafael Kassner
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Atenciosamente,
Rafael Kassner
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Can we stay on topic please. At this time I count a vast number of
mails, but never has talked about the RFC.
Fact is that these three cases, how a autoloader terminates, exists in
PHP. If all these cases are useful is an other topic. Can we all agree
on this?
Am 25.11.2011 11:21, schrieb Sebastian Krebs:
2011/11/25 Ferenc Kovacs tyr...@gmail.com
The problem with fatal, that you have no way (by the standard means,
but
you can somehow manage it through the usage of output buffers or
register_shutdown_function, but thats ugly, and can change in the
future)
to intercept and gracefully terminate your application, which is an
often
needed feature.
AFAIK E_FATAL should be only used where the engine is left in an
unstable
state, which isn't really true here.
Trying to interact with a non-existing class is not an unstable
state?
there are two situations:
1. The application is broken, thus the FATAL is appropriate
2. The application tries to work with dynamic class names. If it
doesn't
use class_exists() before, its broken and FATAL is appropriate
So I think that E_RECOVERABLE_ERROR would be more appropriate here,
and in
general we use E_ERROR many places where E_RECOVERABLE_ERROR would
be more
suitable, but thats another topic.
For clarification: I'm talking about the E_FATAL which currently
will be
called if none of the registered autoloaders were able to load the
requested class.
On Fri, Nov 25, 2011 at 9:56 AM, Sebastian Krebs
krebs@googlemail.com
wrote:
Hi,
Just to throw my 2 cent in: Im with Micheal. An application, that
tries to
access a class, that doesn't exists, is broken and a FATAL is
valid. This
application doesn't need try-catch, but a bugfix (and if it is
already
released: A better testing management).
On the other side an application, that makes use of dynamic class
names
should make use of class_exists() in any case. An exception after
calling
class_exists() is just bad, but the classloader cannot distinguish
between
the reasons, why it is called.
2011/11/25 Christian Kaps christian.k...@mohiva.com
Am 25.11.2011 08:24, schrieb Michael Wallner:
On Thu, 24 Nov 2011 23:28:35 +0100, Christian Kaps wrote:
https://wiki.php.net/rfc/**autoloader_error_handling
https://wiki.php.net/rfc/autoloader_error_handling
Throwing an exception or fatal error in an autoloader
absolutely does not make any sense in my eyes.
Projects doing this should step back and think a
minute about what they dare.
Mike
Hi,
how would you bring your application in a consistent state after
a class
couldn't be loaded. I do this by adding a try/catch block around
my
code.
try {
new Application();
} catch (Exception) {
// collect data
// send mail
// redirect to maintenance page
}
An other question is, if the autoloader work silent and I write:
new NotExistingClass();
I think in this case the engine will also trigger a fatal error.
So in
my
eyes it is regardless of whether it trigger a fatal error in the
autoloader
or the autoloader works silent. Both cases ends in a fatal error.
Or am
i
wrong here?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
christian.k...@mohiva.comwrote:
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.
But I use also similar calls to reformat error messages.
try {
$class = new ReflectionClass($**annotationName);
} catch (ClassNotFoundException $e) {
$message = The annotation class `{$annotationName}` cannot be
found; ;
$message .= called in DocBlock for:
{$this-context-getLocation()**};
;
throw new ClassNotFoundException($**message, null, $e);
}
if(!class_exists('ReflectionClass')){
// call your error handler here or throw Exception as you like
}
else{
$class = new ReflectionClass($**annotationName);
}
Reflection class triggers also the autoloader, because it tries to load
the class $annotationName.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling
Am 25.11.2011 13:34, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 1:28 PM, Christian Kaps
christian.k...@mohiva.comwrote:
Am 25.11.2011 13:13, schrieb Ferenc Kovacs:
On Fri, Nov 25, 2011 at 12:56 PM, Christian Kaps
christian.k...@mohiva.com**wrote:
I surround my application with a try/catch block to catch uncaught
exceptions. An autoloader exception could be one of them.
But I use also similar calls to reformat error messages.
try {
$class = new ReflectionClass($annotationName);
} catch (ClassNotFoundException $e) {
$message = The annotation class `{$annotationName}` cannot be
found; ;
$message .= called in DocBlock for:
{$this-context-getLocation()**
**};
;
throw new ClassNotFoundException($message, null, $e);
}
if(!class_exists('**ReflectionClass')){
// call your error handler here or throw Exception as you like
}
else{
$class = new ReflectionClass($annotationName);
}
Reflection class triggers also the autoloader, because it tries to
load
the class $annotationName.
then class_exists($annotationName)?
Oh, my mistake. I have forgotten that class_exists triggers also the
autoloader. Yes, then your solution is as smart as mine.
btw. I think that ReflectionClass::__construct will throw a
LogicException
if the classname you passed couldn't be loaded.
so you don't need your special autoloader for handling that.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Autoloader Error Handling
Hi internals, I've written a RFC about the optimization of the autoloader error handling. Please take a moment to review the RFC and post any questions, suggestions or concerns here. https://wiki.php.net/rfc/autoloader_error_handling Cheers, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SPLClassLoader RFC Thoughts And Improvements
Hi .. snip .. Hm... so there should never have the normal available? I need to think over this again then. While I tend to agree with autoloader never triggering errors or exceptions, the debug mode is the unique way to notice if user during developer haven't done any mistake. Maybe we can only keep the RuntimeException and debug mode possibility, remove the normal and keep it always silent. What do you think? I think that an exception to this request could be made for the DEBUG mode (as the way you're doing it is pretty much the only way you could identify that). Perhaps changing the exception to a warning or notice (as you wouldn't want that in prod), but I could live with the error in debug mode as it shouldn't be used outside of testing and dev work. I was more referring to errors/exceptions in normal usage... Would it not be possible that the autoloader mechanism catch all exceptions made by any autoloader which fails to load a class. Only if none of the register autoloaders can load the requested class the autoloader mechanism throws an AutoloadException with all the catched exceptions. This behaviour should be controllable by the users environment. So if using an autoloader(e.g. from a library) which throws an exception, but the user doesn't use exceptions in his environment, he should be able to deactivate the exceptions thrown by the autoloader mechanism. I think this behaviour has the greatest advantages for both worlds. This one which needs exceptions to shut down the application in an ordered way, and for these relying on PHPs way to handle the autoloading error. Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
Hi,
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
1. The interface should be named SplClassLoader and the register and
unregister methods should be removed.
It should be possible to define class loader implementations without
registering them as autoloader because autoloading isn't the only way to
load classes. A class loader could as example return the ReflectionClass
instance for the loaded class. I think the current interface is to
restrictive in this case. As compromise it would be possible to define a
SplClassAutoloader interface too. This interface extends the
SplClassLoader interface and defines the methods register and
unregister.
interface SplClassAutoloader extends SplClassLoader {
public function register($prepend = false);
public function unregister();
}
As a side note, the two interfaces doesn't violate the Single
responsibility principle.
I know the reference implementation is named as SplClassLoader but this
should be renamed into SplDefaultAutoloader or SplPsrAutoloader if
implements the SplClassAutoloader or as SplPsrClassloader or
SplDefaultClassloader if implements the SplClassLoader interface.
2. The function spl_autoload_register() should accept all
SplClassLoader implementations.
I know it's already possible with the following syntax:
$classLoader = new MyCustomClassLoader();
spl_autoload_register(array($classLoader, 'load'));
But the following syntax seems more consistent to me:
$classLoader = new MyCustomClassLoader();
spl_autoload_register($classLoader);
Christian
Am 09.11.2011 02:23, schrieb guilhermebla...@gmail.com:
For all those interested, I implemented what I referred as item 2:
quote
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
/quote
RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.
On Tue, Nov 8, 2011 at 3:55 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not
yet 100%.
Some things I have either identified or people have reported.
1- Remove -register() and -unregister(), and make the
spl_autoload_register to support SplClassLoader.
I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.
2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then
defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php
What do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.
Cheers,
On Tue, Nov 8, 2011 at 3:39 PM, Nikita Popov
nikita@googlemail.com wrote:
On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or
an
APC lookup.
After your changes the RFC looks much more decent. I am still
opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.
Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
I know this topic has been discussed enough, but I think one argument was not brought up yet. The proposed solution has a bad OO design because it violates against the Single responsibility principle. Another issue is that the proposed class is only one possible solution to load PSR-0 conform classes. I have written a blog post about this issues. Maybe someone changes his mind after reading it. http://blog.mohiva.com/2011/11/discussion-about-psr-0-autolaoder-in.html Greetings, Christian Am 07.11.2011 14:41, schrieb David Coallier: Hey everyone, After lengthy discussions and various opinion, we believe this issue has been discussed at length and the PSR-0 has had this standard effective for the past 1.5 year. The SplClassLoader RFC has moved to voting stage. Please cast your votes at https://wiki.php.net/rfc/splclassloader/vote Thank you very much for all the interest showed so far, -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug with static property access
In addition, as I understand and would like to make you aware that static is not allowed in compile time class constants. Which is slightly unusual and perhaps could be changed because it seems that there is already runtime resolving taking place here. It's available since PHP 5.3. This feature is called late static binding. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Factory for Stream Wrappers
On Mon, 12 Sep 2011 14:43:33 +0100, Gustavo Lopes wrote: Em Mon, 12 Sep 2011 12:53:13 +0100, Sebastian Bergmann sebast...@php.net escreveu: Regarding state it is important to notice that PHP does *not* execute the constructor on all low level calls when instantiating the wrapper class - for whatever reason that is the case. Changing that behaviour would cause quite some side effects, with possible quite some BC breaks. This is a bit off-topic, but could you elaborate on this (possibly submitting a bug report)? I see user_wrapper_opener trying to call the constructor: http://lxr.php.net/opengrok/xref/PHP_5_3/main/streams/userspace.c#298 So any failure to do this would be a bug. Not sure if it's actual, but this behaviour is documented: http://de3.php.net/manual/en/streamwrapper.construct.php#94731 Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problems with the stream API
Hi,
I have some problems with the stream API. The methods stream_tell and
stream_seek works not as expected in some cases.
Before reading the next lines, please look at the short
gist(https://gist.github.com/1176641).
First example:
$fp = fopen('mfx://test1', 'w');
fwrite($fp, '12345678');
fseek($fp, -1, SEEK_CUR);
fclose($fp);
// stream_seek: $offset = 7
If you call fseek with the arguments (-1, SEEK_CUR) then the $offset
parameter in the method stream_seek is 7. It seems that the internal API
takes the written bytes returned by fwrite and then it subtracts the
argument (-1) from it before passing it to stream_seek. For the
constants SEEK_SET and SEEK_END, the passed value is the same as defined
for the fseek call.
---
The second example:
$fp = fopen('mfx://test2', 'w');
fwrite($fp, '12345678');
fread($fp, 2);
fseek($fp, 1, SEEK_CUR);
fclose($fp);
For this example the stream_seek method gets never be called. The
difference here is that fread is called before fseek.
---
The third example:
$fp = fopen('mfx://test3', 'w');
fwrite($fp, '12345678');
fread($fp, 3);
ftell($fp);
fclose($fp);
For this example the stream_tell method gets never be called. It is
documented(http://www.php.net/manual/en/streamwrapper.stream-tell.php)
that the stream_tell method is called in response to ftell(). But it
seems that this method is only be called internally by the stream API.
There exists a Bug report at https://bugs.php.net/bug.php?id=30157
In one of the comments Pierre says: There is no bug but a feature
request which seems to be very discutable.
So with these words, I start the discussion.
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with the stream API
Hi Gustavo,
thanks for your detailed explanation.
Nevertheless it might be useful to document these inconsistent(from the
userland point of view) behavior. Please see my comments inline.
Am 28.08.2011 17:22, schrieb Gustavo Lopes:
On Sun, 28 Aug 2011 14:29:28 +0100, Christian Kaps
christian.k...@mohiva.com wrote:
I have some problems with the stream API. The methods stream_tell and
stream_seek works not as expected in some cases.
Before reading the next lines, please look at the short
gist(https://gist.github.com/1176641).
First example:
$fp = fopen('mfx://test1', 'w');
fwrite($fp, '12345678');
fseek($fp, -1, SEEK_CUR);
fclose($fp);
// stream_seek: $offset = 7
If you call fseek with the arguments (-1, SEEK_CUR) then the $offset
parameter in the method stream_seek is 7. It seems that the internal API
takes the written bytes returned by fwrite and then it subtracts the
argument (-1) from it before passing it to stream_seek. For the
constants SEEK_SET and SEEK_END, the passed value is the same as defined
for the fseek call.
SEEK_CUR seeks are internally converted to SEEK_SET seeks. It's been
this way since at least 2002:
http://svn.php.net/viewvc/php/php-src/trunk/main/streams.c?annotate=96547pathrev=96547#l582
The first thing you should know is that PHP keeps track internally of
the position of the stream. That's why PHP knows how to convert SEEK_CUR
-1 to SEEK_SET 7.
The seek type conversion is an arguable decision, but changing this has
some risks. Consider that some some streams might not respond to
SEEK_CUR seeks or that they do so defectively. The only advantages I see
is that it could mitigate the problems of an inaccurate internal
position (though this happens mostly with internal code that casts the
stream into e.g. a FILE* and then manipulates the pointer); it would
also save stream implementations that only support SEEK_CUR from having
to reconvert the SEEK_SET to SEEK_CUR.
This behavior should be documented. The possible values for the whence
parameter of the stream_seek method should only be SEEK_SET and
SEEK_END. And there should be a hint that the SEEK_CUR seeks are
internally converted to SEEK_SET seeks.
The second example:
$fp = fopen('mfx://test2', 'w');
fwrite($fp, '12345678');
fread($fp, 2);
fseek($fp, 1, SEEK_CUR);
fclose($fp);
For this example the stream_seek method gets never be called. The
difference here is that fread is called before fseek.
No bug here. This is by design. PHP doesn't read only two bytes from the
stream, it reads an entire chunk. Once PHP has data buffered and you
tell it to skip one byte, it can just advance its internal pointer on
the buffered data; no need to actually call fseek.
It should be documented that, in some circumstances, the stream_seek
method isn't called in response to fseek.
The third example:
$fp = fopen('mfx://test3', 'w');
fwrite($fp, '12345678');
fread($fp, 3);
ftell($fp);
fclose($fp);
For this example the stream_tell method gets never be called. It is
documented(http://www.php.net/manual/en/streamwrapper.stream-tell.php)
that the stream_tell method is called in response to ftell(). But it
seems that this method is only be called internally by the stream API.
There exists a Bug report at https://bugs.php.net/bug.php?id=30157
In one of the comments Pierre says: There is no bug but a feature
request which seems to be very discutable.
Again, as the comment on the bug report says, this is by design. PHP
keeps track internally of the position, so it can just return the
information it has.
But yes, the documentation is wrong in this respect. stream_tell is only
called after a seek in order to determine where the seek ended up. In
the C standard library, you're allowed to seek past the end of the file
and then write, zeroing everything in between the end of the position
sought to (or failing to write). In PHP, this convention doesn't apply;
you're not always allowed to seek to any position.
The documentation for stream_tell is wrong. This method gets only be
called internally.
What do you think about my suggestions?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Issue with custom stream wrapper, include and APC
Hi! I have a problem with APC and a custom stream wrapper implementation. The wrapper is used to include generated PHP classes. If APC is enabled it seems that the include statement(used with different URL's), loads always the first included class from cache. The following code illustrates the issue a bit more. https://gist.github.com/1156717 If executing it with APC enabled, I get the following fatal error. Fatal error: include(): Cannot redeclare class test1 in ... on line 78 PHP Fatal error: include(): Cannot redeclare class test1 in ... on line 78 Is this a bug? Or do I miss something? Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Issue with custom stream wrapper, include and APC
Thanks for your fast feedback. I've tried it with the latest(3.1.9) version. Can someone who has the actual trunk compiled, give feedback for the snippet(https://gist.github.com/1156717)? Christian Am 19.08.2011 15:07, schrieb Pierre Joye: hi, Have you tried using the latest version of APC or using svn's trunk? If not please try it and report a bug at pecl.php.net/apc if it still occurs Thanks for your feedback! On Fri, Aug 19, 2011 at 2:54 PM, Christian Kaps christian.k...@mohiva.com wrote: Hi! I have a problem with APC and a custom stream wrapper implementation. The wrapper is used to include generated PHP classes. If APC is enabled it seems that the include statement(used with different URL's), loads always the first included class from cache. The following code illustrates the issue a bit more. https://gist.github.com/1156717 If executing it with APC enabled, I get the following fatal error. Fatal error: include(): Cannot redeclare class test1 in ... on line 78 PHP Fatal error: include(): Cannot redeclare class test1 in ... on line 78 Is this a bug? Or do I miss something? Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
Hi,
Hi all,
Reading our bug tracker I noticed a good feature request [1] from
2009 which
points to an interesting feature that I think makes sense for us,
since we
are now working with $f() using objects and strings, and the
array('class',
'method') is an old known for call_user_func()-like functions.
So, I wrote a patch [2] that allow such behavior to be consistent
with
arrays. See some examples:
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array('Hello','world');
var_dump($f('you'));
$f = array(new Hello, 'foo');
$f();
All such calls match with the call_user_func() behavior related to
magic
methods, static non-static methods.
The array to be a valid callback should be a 2-element array, and it
must be
for the first element object/string and for the second string only.
(just
like our zend_is_callable() check and opcodes related to init call)
Any thoughts?
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this-bar = array($this, 'baz');
$this-bar();
}
public function bar() {
echo 'bar';
}
public function baz() {
echo 'baz';
}
}
new Foo();
What is the output of this snippet?
Are there the same rules as for closures?
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, 8 Jun 2011 08:57:48 -0300, Felipe Pena wrote:
Hi,
2011/6/8 Christian Kaps christian.k...@mohiva.com
Hi,
what happens if I use this code.
class Foo {
public $bar;
public function __construct() {
$this-bar = array($this, 'baz');
$this-bar();
}
public function bar() {
echo 'bar';
}
public function baz() {
echo 'baz';
}
}
new Foo();
What is the output of this snippet?
Are there the same rules as for closures?
Christian
Yes, the same rules.
Hi,
I think for the sake of consistency it should be possible to use the
following code.
class Bar {
public function __construct($dispatcher) {
$dispatcher-addEventListener('onUpdate', $this-onUpdate);
}
public function onUpdate() {}
}
If a property $onUpdate exists then it will be ignored. The same rules
as for Closures or for array callbacks.
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, 8 Jun 2011 09:46:26 -0300, Felipe Pena wrote:
It works in the same way:
class foo {
public function __construct() {
$this-bar = function () { return 1; };
// $this-bar(); // error
$x = $this-bar;
$x(); // ok
$this-bar = array($this, 'baz');
// $this-bar(); // error
$x = $this-bar;
$x(); // ok
}
public function baz() {
echo 'baz';
}
}
OK, my mistake. I thought a property which holds a closure can be
called directly.
Thanks for clarification.
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $arr = array('Hello', 'world'); $arr();
On Wed, 8 Jun 2011 15:39:59 +0200, Jordi Boggiano wrote:
On Wed, Jun 8, 2011 at 2:46 PM, Felipe Pena felipe...@gmail.com
wrote:
class foo {
public function __construct() {
$this-bar = function () { return 1; };
// $this-bar(); // error
$x = $this-bar;
$x(); // ok
$this-bar = array($this, 'baz');
// $this-bar(); // error
$x = $this-bar;
$x(); // ok
}
public function baz() {
echo 'baz';
}
}
What he meant was passing an existing method as a callback if you
don't invoke it, i.e. passing $this-bar instead of array($this,
bar). I don't know how hard it'd be to achieve, but it sounds
pretty
awesome to me.
Cheers
Yep, just what I meant.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Final version, RFC release process
Am 02.06.2011 13:15, schrieb Peter Lind: Anyway, I'll stop it here, as I doubt I'll convince you of anything (and vice versa). Just one thing to add: thanks for the work on PHP :) Much appreciated. I think/hope that this RFC is a step in the right direction to make the release process clearer and more transparent for every interested userland developer. So from me a big THANK YOU to all involved. Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Full namespace support for the Reflection API
Hi, are they any plans to add full namespace support for the Reflection API in PHP 5.4. Until now there is only rudimentary support implemented. There would be a great benefit for userland annotation parsers, because it could access the use statements to get the FQN for an annotation. I think there are many other use cases for such feature. Maybe someone can help my to write an RFC, because My English isn't the best. Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies with constructors in SPL
Am 17.05.2011 um 02:22 schrieb Benjamin Dubois benjamin.dub...@gmail.com: Hi, Why not make all objects (maybe implicitly) extend a single root object, containing just skeleton ctor/dtor and implemented in the engine ? I don't know if it is actually possible in PHP, but that works for several other languages (java, objC - in that case, the root object is explicit-, C# AFAR) This would also bypass the error-level debate (no error would be thrown) +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Am 11.05.2011 13:31, schrieb Richard Quadling: On 11 May 2011 07:50, dukeofgaming dukeofgam...@gmail.com wrote: It is really troubling to read that statement. Seems there are still some that don't really have a clue of what annotations are, even when the RFC clearly links to them. Annotations ARE NOT documentation; in the case of PHP, documentation is being used as annotations because there is no language implementation, which exists in other languages (Java, .NET) and they are widely used. Also, some use annotations as documentation (e.g. store the class version), but again, annotations ARE NOT documentation. Don't let the @ notation shared with docblock fool you. Guilherme, I think its easy to assume that people already have some sense of what annotations are, but perhaps the wiki entry could be more educational about it?. The first time I read about annotations it was from this link: http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html; perhaps an intro like that could help to make the case for annotations crystal clear?. I'm guessing experience and interpretation is everything here. From reading the Oracle page, to me, it seems annotations ARE documentation. It just depends upon who or what is reading them. The first line of the page ... They have no direct effect on the operation of the code they annotate. In other words, annotations are just like comments. At least in terms of what I understand the compiler does and what the runtime processing does. They have no direct affect of the operation of the code they annotate, but they have affect of the code which runs the annotated code. So annotations are no comments. The use of the @ isn't a fooling (according to Oracle) ... The use of the @ symbol in both Javadoc comments and in annotations is not coincidental—they are related conceptually.. I think the usage of the @ is historical. Because Java annotations in the first implementation were DocBlock annotations parsed by XDocklet. Starting with version 5 of the Java specification, they implemented Annotations as part of the language. http://www.devx.com/Java/Article/27235 What I can't see from the link is _WHY_ annotations can't just be docblocks? Annotations and comments don't affect the code. Annotations and comments would need to be parsed to read them. I understand that caching of the annotation could be an issue. And this leads to a gap in my knowledge/understanding. Why does _this_ script need to know anything about its annotations? Especially as They have no direct effect on the operation of the code they annotate. It would seem wasteful to process dead data for no purpose in _this_ script. It only seems useful for some sort of external process reading the annotation/comment (say a documentor or a tool to build code for runtime operation). In those cases, these are one offs (ish), so caching would not seem to serve any real benefit here. Whilst I think the syntax of the annotation may be worth discussing, the annotation can surely only exist in a comment, at least with regard to PHP. And I'm guessing that the primary use of annotations within PHP would be in runtime processing, so is this really about the parsing of docblocks. I think using PHP code in a docblock (with the appropriate tag ... @annotation maybe) would cover the requirements. Possibly. Due to phpdocumentor not being updated to handle namespaces yet, annotations are also not going to work correctly there. Richard. Why not learning from Java and implement annotations in the way Guilherme proposed it? I think they had good reasons for the new implementation. Maybe someone has a link which points to such discussion. Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On Tue, 10 May 2011 15:13:32 +0200, Ferenc Kovacs wrote: so the problem is, that the userland is under-represented in the development, because they usually not present on the mailing list and on irc, where discussions and decisions happen, and they usually have different priorities and expectations about the PHP language than the core devs. to make things worse, they cannot write patches for the core, and the core devs rarely work on something which they don't particularly need or like. and I think that the only option where we can change that, is that us, the php userland devs has to be more active on the mailing lists, irc, bug tracking, writing RFCs etc. I'm a userland developer, reading the list since two years I think. And I must say I'm totally frustrated about the developing process itself. The actual proposal process is always the same: 1. Someone proposes a new feature. 2. As next there is a long discussion about the topic which ends up with more dissent than consensus. 3. A long time nothing about the topic. 4. Start new from first point. And I think in the near feature there will be no changes with the old structures. Greetings Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 again
On Tue, 10 May 2011 15:20:14 +0100, Alain Williams wrote: On Tue, May 10, 2011 at 03:55:26PM +0200, christian.k...@mohiva.com wrote: I'm a userland developer, reading the list since two years I think. And I must say I'm totally frustrated about the developing process itself. The actual proposal process is always the same: 1. Someone proposes a new feature. 2. As next there is a long discussion about the topic which ends up with more dissent than consensus. I think that part of the problem is that we come to the language from different perspectives and so have different needs and use PHP in different ways. PHP is a language that is used by a very wide variety of people, most of who would never think of going anywhere near a mail list like this one. This might mean that we have to accept that people will use PHP in ways that many of us might seem wrong. There is little point in telling them that they should be doing things differently because as far as they are concerned they are doing just fine. An example of this is the procedural/objects paradigm choice. OO is probably better for large projects and is favoured by many on this list. Many PHP users find objects and can probably use them, but almost certainly won't be able to write objects - the programs that they are writing are fine as procedural. So: rather than saying ''OO is the only way'', we need to make life easier for those who will never write OO code. Balanced against that is that you can't put everything into PHP. Yes, this is the point. In my opinion PHP has an identity problem. Is it an object oriented or a procedural language? I think the best from both worlds seems to be inoperative! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Access a temporary file created by SplTempFileObject by another file handle instance
Hi,
is there any reason why a temporary file created with SplTempFileObject
isn't accessible by another e.g. SplFileObject instance.
$temp = new SplTempFileObject();
$temp-fwrite('A string');
var_dump($temp-getPathname());
The var_dump call returns always the PHP stream URL php://temp. Why the
method getPathname doesn't return a unique ID in the
URL(php://temp/ertZ789) which references to this temporary file. So it
would be posible to access this temporary file by another e.g.
SplFileObject instance.
For testing purpose this would be a great benefit. With a
SplTempFileObject instance a test fixture could be created in RAM. It
would like a virtual file system for one file.
Greetings
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPLFileObject returns the content of a file after it was deleted
Hi, last week I wrote a bug report: http://bugs.php.net/bug.php?id=54570 Maybe someone can look into it, because no modifications were made since reporting. I am interested if it's a bug or If I should work around. Greetings Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
Am 03.01.2011 02:41, schrieb Enrico Weigelt: * Rasmus Lerdorf ras...@lerdorf.com wrote: Also, you said this happened between 5.3.2 and 5.3.3? Looking through the diff between those two versions we did not add any new deprecation warnings. We tend to not do that in a minor release. At least I don't recall the last time we did so. That's where I noticed it. Maybe several other things had to come together to make it show up now. I can just tell you my observation that the latest update suddenly brought up all these warnings to stdout. I suspect your issue comes down to your system somehow ending up with a new php.ini with different settings when you installed 5.3.3 and it has nothing to do with any code changes on our part at all. No, as usual on Gentoo, config files are never overwritten, but written to another place and tools like etc-update show you the differences. I've merged the configs manually, and I'm pretty sure I didn't add anything like error_reporting=On, etc. But I can't tell if these options had been previously set at all, so it's maybe a matter of built-in defaults. cu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
Am 03.01.2011 02:41, schrieb Enrico Weigelt: No, as usual on Gentoo, config files are never overwritten, but written to another place and tools like etc-update show you the differences. I've merged the configs manually, and I'm pretty sure I didn't add anything like error_reporting=On, etc. But I can't tell if these options had been previously set at all, so it's maybe a matter of built-in defaults. cu Hi, Sorry for the noise. Here is the correct answer. Since ebuild php-5.3.3 Gentoo introduced a set of new features. One of them is the PHP_INI_VERSION variable in the file /etc/make.conf. If you don't set this variable, Gentoo installs the development version of the php.ini file. I think this is your problem. For more informations you can visit the Blog from the PHP ebuild maintainer. olemarkus.org Greetings, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi,
I like the idea of the property get/set syntax, but in my opinion it
doesn't figure with PHP's syntax, because it breaks the readability. The
problem for me is the nesting of the inner set and get. How do you
document these syntax.
/**
*
*/
public $name {
/**
*
*/
get {
return $this-name;
}
/**
*
*/
set {
$this-name = htmlentities($value);
$this-name = strip_tags($this-name);
}
};
What I also miss is the lack of type hinting. As I see it, it isn't
possible with this syntax.
I would prefer the syntax from ActionScript. This is more like the
normal PHP function syntax with an additional set or get keyword.
/**
*
*/
public function set name(string $name) {
$this-name = htmlentities($name);
$this-name = strip_tags($this-name);
}
/**
*
*/
public function get name($name) {
return $this-name;
}
Greetings,
Christian
On Sun, 28 Nov 2010 18:18:40 -0500, presid...@basnetworks.net wrote:
Hello,
This is my first time using a mailing list, so please bear with me.
Some time back I suggested that PHP should have a property get/set
syntax
similar to that of Microsoft's C# language. One of the PHP
developers
suggested that if I were serious about it, I should write an RFC. I
have
done just that, and I would now like to present my RFC to everyone
here in
internals, in order to start a discussion on the topic.
The RFC:
Many modern languages have a special syntax for writing get/set
method
pairs. All that PHP currently supports is __get and __set, which
while
great for writing generic get/set methods is nearly useless when it
comes
to individual properties. Our only other choice is the age old
process of
writing custom class methods to make our get/set methods. Not only
does
this lack any kind of uniformity, but it also complicates the syntax
($foo-getBar() and $foo-setBar('baz') instead of $foo-bar and
$foo-bar='baz'). I believe that if PHP is going embrace modern
object-oriented design, including encapsulation, than it needs a
modern
solution to property getters and setters.
I wont add much more here, but rather let the RFC itself do the
talking.
It is fairly well fleshed out, and should explain everything clearly
enough.
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On how a little knowledge is completely useless.
On Fri, 17 Sep 2010 10:02:10 +0100, Richard Quadling rquadl...@gmail.com wrote: Hello all. In trying to follow the annotations threads currently running, I've come to realise just how little I understand a LOT of what I read here. But, then again, I don't need to, so hurrah for me. I try to follow, but, #fail most of the time. One thing that did come to mind is if we ignore all the issues and complexities of actually implementing annotations, are annotations useful to a significant number of userland developers. On the surface, (and this is probably where I'm going wrong), it would seem to only really be of use to framework developers, and whilst there are at least 2.5 frameworks per developer, the vast majority of userland developers are not framework developers. So are they useful enough to be included at all, or is it just serving a small minority and distracting the other core developers? This isn't right. At a first glance, yes it looks that only framework developers can have a benefit from annotations in the core. But the annotations extending the API of a framework so that all developers which using this frameworks have a great benefit of them. Lets take as dependency injection as example. If the framework implements this concept than the user of the framework make the usage of this. Or the bean validation framework. This is only for the framework users. Is this something that can just be an extension with its own evolution? Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
Hi, it's reserved for the error control operator(http://www.php.net/manual/en/language.operators.errorcontrol.php). Greetings, Christian On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov sapr...@gmail.com wrote: Hello all, Only today see that here is very intersting discussion. I have a question: why was choosed exactly this format (seems like c#-like, not java-like)? Simply [] is used for arrays. Why not use @ at annotation name? 2010/9/16 Pierre Joye pierre@gmail.com On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: P.S. Personally I would take the energy boiling in this thread and throw it at solving the windows biuld and PECL problem. Right now you can't install PHP 5.2 and apache on a Windows 7 - it just crashes totally. Where are the bugs report? Only 5.3 works, not to mention much of the PECL libs just don't have dll's (lucky if you find one in the Google). The same goes for the PECL dll's for 5.3 - all of them, excluding the standard once, mostly are missing and can't be found at all. What are you talking about? Not a real question, use bugs.php.net for php extensions, if something is broken or missing. Thanks to focus on the topic and not hi jack this thread with random rants. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] More formal feature request cycle
On Thu, 16 Sep 2010 10:10:21 +0200, Frederic Hardy frederic.ha...@mageekbox.net wrote: Hello ! This thought is brought on mainly by watching the annotations drama that is currently occupying internals, does anyone else agree it might be a good idea to have a slightly more formal procedure for requesting features and then recording votes pros, cons, side effects, etc. against it. It might do a fair bit to stop anecdotal talk of how many people actually want a feature, and stop the list retreading the same arguments over and over again. Have no idea just yet what this would look like, but an thinking something between launchpad and the current php wiki. Very huge +1 for that ! Best regards, Fred. -- Frédéric Hardy : Architecte d'application/Admin. système/Ergonome Status : En recherche d'emploi CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf Blog : http://blog.mageekbox.net Twitter : http://twitter.com/mageekguy The same from me. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
So the question to be answered is: Should PHP support Annotations? I'm +1. +1 Greetings, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
Am 16.09.2010 18:02, schrieb Matthew Weier O'Phinney:
in my mind there is a big mistake when using annotations in PHPDoc comments.
What is the mistake? You don't explain that anywhere in your reply -- you
simply
give code examples of how you feel they should work.
For me the mistake is that annotation classes must be defined with their
FQN or you must create an alias for the namespace. This alias must be
registered before using this annotations. Every framework I use uses its
own rules for defining annotatations, registering annotation namespaces
and so on. For me this is impractical. Registering the namespace with
the out of the box PHP use statement is for me the better way.
I thought this was clear from my comparison.
An other problem is that every framework use its one annotation syntax.
So it makes the framework end user more confusing as using a clear
unique syntax.
Actually, I see this as a _benefit_ or _feature_ of such an approach -- itwer
ist den dir auf den schlips getreten
allows developers to define their own annotations, which allows them to create
new approaches. We see this already in docblock annotations -- PHPUnit makes
use
of them (@expectedException, @group, etc.). Groups like the Framework Interop
Group can tackle standard use cases.
This isn't what I meant with different syntax. Different syntax for me is:
[Annotation([1, 2, 3])]
@Annotation({1, 2, 3})
%Annotation(array(1, 2, 3))
Have fun, using annotations from different frameworks for one and the
same method, property or class.
I think the PHP way should be as in the next example.
namespace my\project\models\dto;
use com\jsr303\validator\constraints\NotNull;
use com\jsr303\validator\constraints\Integer;
use com\jsr303\validator\constraints\Regexp;
use com\jsr303\validator\constraints\MinLength;
use com\jsr303\validator\constraints\MaxLength;
use my\project\validator\constraints\Zipcode;
class User {
[NotNull]
[Integer]
public $id;
This is entirely unclear to me. Will it type-cast to integers? will it throw
an
exception for null values? I actually don't know what this code will do --
which
brings me to my chief issue so far with this debate: annotations, since they
are
meant to be machine-readable (that's what all the proponents are saying,
anyways), introduce a huge WTF factor when debugging -- is it the code that
caused an exception? If not, was it an annotation? Which one? what input did
it
get? etc.
If an annotation throws an exception because of syntax errors you get an
stack trace. So it should not be a problem to localize this error.
In this example the annotations doesn't throw any exceptions.
$user = new User;
$user-id = 'only integers are allowed';
$validator = new Validator();
$results = $validator-validate($user);
The result contains a constraint violation message. For more you can
look at the Hibernate Validator page.
http://www.hibernate.org/subprojects/validator.html
With this out of the box PHP annotations it makes it possible to create
powerful frameworks which can used by a great range of developers
without learning a new syntax for it. Pleas do not argue about thy
syntax of the annotation because this isn't final.
Um, you're being contradictory here -- you're actually _suggesting_ a brand
new
syntax, which leads to the exact opposite of what you assert.
I meant that this developers who using this frameworks must not learn
different syntaxes but rather one.
Using existing
docblocks and adding an annotations parser to it would be using existing
syntax.
- How would you comment out an annotation in a doc block?
- How would you define annotations with namespaces?
- Parsing of annotations is slow. When using caching every framework
that I use implements other caching rules for its annotations.
There are many more reasons mentioned in all the mails.
You may excuse me because I am not an native English speaker so it can
be be the case the one or the other formulation isn't correct.
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] docBlock Parser RFC
Am 16.09.2010 22:56, schrieb Chad Fulton:
Hello,
Based on comments from the annotations thread, I have created a
docBlock parser RFC at http://wiki.php.net/rfc/docblockparser
This RFC does not deal with annotations per se, but only with the idea
of adding a function to the Reflection extension which would parse
docBlocks according to a set docBlock syntax into a simple associative
array containing three elements: short description, long description,
and an array of tags.
This is only meant to aid meta-data retrieval for classes and does not
automatically instantiate anything objects.
The RFC was meant to conform to existing convention on the formatting
of docBlocks - so one major way to improve it would be to note any
inconsistencies with accepted practice.
Feel free to improve in any other way as well, of course.
Thanks,
Chad
Hi Chad,
the RFC looks for me like a built-in PHPDocumentor parser. This can be
useful. The problem for me is that I cannot parse the file level doc
block. What is with tags like @Validator('blabla'). I cannot find an
example for this scenario.
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
smalys...@sugarcrm.com wrote:
Hi!
class User {
[NotNull]
[Integer]
public $id;
[NotNull]
[Regexp('/[a-z]*/i')]
[MinLength(2)]
[MaxLength(255)]
public $name;
[NotNull]
[Zipcode]
public $zipcode;
}
I'm not sure I understand - why can't you use normal data structure
to keep this information? Why it has to be in weird syntax with []s
that has to be accessed through reflection?
- Annotations are like enum fields, or a function headers. You can only
specify these values defined by the annotation. In normal data
structures like arrays you can define what you will.
- The meta information is defined on top of the property to which this
information belongs.
- To use this information by the validator you must make this
information public in the object model. This can be more work, or the
informations should not be accessible through the object.
- When I look at the code I can promptly see what validation rules are
used for this property.
- Metadata is a part of the property, method or class. This information
should not be described contextless.
There are other examples in which the information should be described
in context of the method, class or whatever. When using dependency
injection as example.
class Controller {
[Inject]
public function setRouter(Router $router) {
}
}
The dependency injection container must know the method on which the
router should be injected into the controller. Sure this information can
be defined anywhere in the class or a config file. But the config file
need also parsing time. And the information is quoted out of context.
Can you really not see the elegancy and the advantage for the users?
powerful frameworks which can used by a great range of developers
without learning a new syntax for it. Pleas do not argue about thy
syntax of the annotation because this isn't final.
Whatever syntax it is, it is definitely new.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev smalys...@sugarcrm.com wrote: Whatever syntax it is, it is definitely new. Yes, but this should not be an argument against it. So every new feature can have new syntax or should PHP freeze on the current state!? I can't honestly understand why developer shouldn't understand the new syntax. These developers which are familiar with annotations, I think have no problem. This users which are new to annotations must learn the new syntax like any other new syntax too. Where is the problem? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Wed, 15 Sep 2010 10:12:43 +0200, Zeev Suraski z...@zend.com wrote: At 09:37 15/09/2010, Christian Kaps wrote: On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev smalys...@sugarcrm.com wrote: Whatever syntax it is, it is definitely new. Yes, but this should not be an argument against it. So every new feature can have new syntax or should PHP freeze on the current state!? I can't honestly understand why developer shouldn't understand the new syntax. These developers which are familiar with annotations, I think have no problem. This users which are new to annotations must learn the new syntax like any other new syntax too. Where is the problem? Christian, Introducing large amounts of new syntax is by itself a very strong negative when weighing the pros and cons of a new proposed feature. Does it mean that 'every new feature that has new syntax' should not be considered? No - but it certainly means that features introducing new syntax, especially large amounts of it, should have extremely compelling advantages and cater to a very large audience. If there's already another way of reaching the same goal, even if it's not a perfect-fit but a good-enough fit, that is also a strong argument against the introduction of a new syntax. And I honestly don't think that syntax is the only issue here. It's the introduction of yet another new entity, another concept into the language. How difficult can it be to understand? - probably not very, but every new concept introduced to the language makes it a bit more difficult to understand, a bit less intuitive, a bit more complex. There won't be a flashing red light warning us when we're about to cross the line to making PHP 'too complicated'. In terms of language-level features, I don't think it's bad at all if PHP went into a mode that most of the other mature languages went into - where syntax changes or introduction of new language level features are pretty rare. Out of all of the mature languages out there, I think PHP has by far the most new syntax-introducing features per version, and personally I don't think that's a good thing. Most of the new features should come from new extensions, new libraries and frameworks - not syntax changes. Zeev Zeev and Stas, I can understand your mind and I can only repeat again that in my opinion annotations are a great feature which can help to produce better software in a simpler way. And I think I am not alone. My last question is, if it makes sense to argue more or is the decision already been made against annotations. Because personally, I have no arguments anymore for implementing annotations in PHP. Greetings, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
On Wed, 15 Sep 2010 10:46:45 +0200, Pierre Joye pierre@gmail.com wrote: The only difference in PHP is the complete lack of clear road map and the chaotic way of deciding things. Yes, I personally see here a huge problem too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
Am 14.09.2010 22:12, schrieb Stas Malyshev:
I think we _already_ have metadata in PHP, albeit done through
phpdocs. So the question is kind of moot :) We should see if it's
enough for us or we want to add/change/extend it and if so, how.
Hi,
in my mind there is a big mistake when using annotations in PHPDoc comments.
As example let as use a JSR 303 - Bean Validator like Hibernate
Validator for PHP.
namespace my\project\models\dto;
class User {
/**
* @com\jsr303\validator\constraints\NotNull
* @com\jsr303\validator\constraints\Integer
*/
public $id;
/**
* @com\jsr303\validator\constraints\NotNull
* @com\jsr303\validator\constraints\Regexp('/[a-z]*/i')
* @com\jsr303\validator\constraints\MinLength(2)
* @com\jsr303\validator\constraints\MaxLength(255)
*/
public $name;
/**
* @com\jsr303\validator\constraints\NotNull
* @my\project\validator\constraints\Zipcode
*/
public $zipcode;
}
It is possible to use this type of annotations but it is impracticable.
An other problem is that every framework use its one annotation syntax.
So it makes the framework end user more confusing as using a clear
unique syntax.
I think the PHP way should be as in the next example.
namespace my\project\models\dto;
use com\jsr303\validator\constraints\NotNull;
use com\jsr303\validator\constraints\Integer;
use com\jsr303\validator\constraints\Regexp;
use com\jsr303\validator\constraints\MinLength;
use com\jsr303\validator\constraints\MaxLength;
use my\project\validator\constraints\Zipcode;
class User {
[NotNull]
[Integer]
public $id;
[NotNull]
[Regexp('/[a-z]*/i')]
[MinLength(2)]
[MaxLength(255)]
public $name;
[NotNull]
[Zipcode]
public $zipcode;
}
With this out of the box PHP annotations it makes it possible to create
powerful frameworks which can used by a great range of developers
without learning a new syntax for it. Pleas do not argue about thy
syntax of the annotation because this isn't final.
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
On Sun, 12 Sep 2010 11:55:16 -0700, Stas Malyshev
smalys...@sugarcrm.com wrote:
Hi!
1. In Java annotations are a special type of an interface. But due the
lack of type hinting for scalar values we cannot use this construct,
because we cannot put some validation logic in an interface. My proposal
I'm not sure I understand - what scalar type hints have to do with it?
Anyway, annotation can't be interface since you'd have to instantiate
it to get the values. Interface can't have values.
In Java I create an annotation as a special type of an interface.
@Target( { METHOD, FIELD, ANNOTATION_TYPE })
@Retention(RUNTIME)
@Constraint(validatedBy = CheckCaseValidator.class)
@Documented
public @interface CheckCase {
String message() default {com.mycompany.constraints.checkcase};
Class?[] groups() default {};
Class? extends Payload[] payload() default {};
CaseMode value();
}
I cannot say how this construct will be handled in the core but I think
an internal class will be automatically created which implements this
interface.
Due the strict typing in Java I cannot pass a string as value to the
annotation. An error will be caused.
If we had also type hinting or strict typing we could use the same
construct, because we must not check if a string and not an array was
given as annotation parameter. But since this is not the case we need a
construct similar to a class, so we can put the validation logic in it.
is to create a new annotation type. This type should have the same
rules as a class and should contain all features proposed in the
ReflectionAnnotation class. With this construct it should be possible to
use named or unnamed parameters for an annotation.
I think this is very bad idea - to have language construct that is
exactly like class but has different set of features. If named
parameters are needed in PHP, let's add named parameters in PHP. But
if we decide they are not needed in PHP, they shouldn't be in one
particular corner of a particular syntax construct and nowhere else.
This makes the language hard to learn and hard to understand - you
never know what surprise the next syntax construct will bring you. I'm
very strongly against only one construct in the language having named
parameters syntax while other places don't.
2. The syntax for arrays should be the same as in PHP. So we can use the
[] as annotation separator. When we allow expressions in the form
Annotation(array('value' = 4 %2)) or Annotation(array('value' =
!MY_CONSTANT)) which I think is a valid construct, then we cannot use
the ! or % as annotation separator.
Where this expression would be evaluated, in which context? Where
would the variable values be stored? What happens if they change?
I don't know. That was a question on my part.
I think with this changes we have a separate language construct like
traits, which does allow a new syntax.
Separate language construct doesn't mean separate rules. We are still
in the same language, so we can't just randomly put arbitrary set of
features together and call it a new construct. There should be some
commonality between different language constructs within the same
language.
That is not what I have said. I am of your opinion. The parameter list
of an annotation should have the same rules as the rest of the language
because it uses the same constructs. The only changes should be the
annotation construct which allows an instantiating other as a class
and named parameters as a part of the PHP core.
What is your idea to solve this problem? How would you create
annotations in PHP?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
Hi Benjamin, I agree with you 100 percent. Greetings, Christian On Mon, 13 Sep 2010 17:38:37 +0200, Benjamin Eberlei kont...@beberlei.de wrote: I strongly disagree! PHPDocs are for what their name suggests, for comments, not for runtime code information. They allow arbitrary characters, their intent is for human-readible documentation only. Yet they are used for service description (Zend_Soap_Autodiscover, Zend_XmlRpc), metadata mapping or phpunits annotations, just because there is nothing better suited. Primary difference of Annotations, they are not only human- but also enforced to be machine-readable. Annotations are runtime configuration or metadata, throwing compile time parse errors when not followed correctly. That has nothing to do with documentation, it is an very elegant way to extend classes, methods and properties with metadata information, configuration and code right next to each other. The primary target for annotations are framework and library integrations: validation, forms, metadata mapping, static mvc configuration such as routing, view selection or acls. Why do these features not exist with current php libraries yet? Because developers see php doc blocks for what they are: Comments! With Doctrine2 and Symfony2 we see some early experiments with annotations in PHP Docs, but they only highlight the drawbacks: 1. Developers should expect to be able to delete a comment/docblock without altering the code-path. 2. Errors in the Doc-Blocks expected formatting are left for the userland developer to detect. IDEs or the PHP Parser simply don't care. 3. There is no real difference for a human only readable doclbock starting with /** or /*, however PHP just doesnt publish the /* docblocks to the userland, leading to countless errors when that single star is missing. 4. every IDE or code-highlighting prints them in light grey, making them sort of invisible. That is why annotations are needed, they make metadata a language level construct, not a hack that is possible, because Reflection allows us to access the comments of methods, functions, classes, ... greetings, Benjamin On Mon, 13 Sep 2010 15:05:57 +0200, Zeev Suraski z...@zend.com wrote: At 20:24 11/09/2010, Pierre Joye wrote: On Sat, Sep 11, 2010 at 8:19 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The separator never was a problem... but I definately don't want to see another 6 months just to define what would the separator be. If we need to drop [] in favor of array support, I vote for ! as separator. The separator is not a problem (even though 1-char one produces much less clutter). The cryptic syntax is. It seems that there is a misunderstanding about the goals of the annotations. They are not meant to be read by human being (javadoc/phpdoc/etc. are) but to be parsed automatically to be used for services. In that sense, to have a syntax closed to one of the best (or less worst, if you are on the opposed side ;-) syntax out there (c#/.net) may be a good thing to do, instead of re einventing the php wheel. I'm not sure we've seen a good reason to add annotations instead of using PHPDoc. Sure, PHPDoc isn't a perfect fit for certain purposes, but I think it certainly falls in the good-enough fit for most purposes. It's also both machine and human readable, and best of all - it's already there. There should be overwhelmingly strong reasons to add a whole new branch of syntax to PHP, I for one don't see the huge gain annotations bring on top of PHPDoc. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
Hi Stas,
this type of annotations cannot be used as PHPDoc annotations due its
different syntax. In other languages like Java, C# or AS3 annotations
are an independent language construct and I think in PHP it should be
the same. I dont know how many non-performant user-land
implementations(hacks), with different syntaxes and concepts, exists in
the meantime. So I think it is time for a consistent syntax in the PHP
core.
I see your concerns about the inconsistency in the syntax, so here are
my thoughts how we can avoid this.
1. In Java annotations are a special type of an interface. But due the
lack of type hinting for scalar values we cannot use this construct,
because we cannot put some validation logic in an interface. My proposal
is to create a new annotation type. This type should have the same
rules as a class and should contain all features proposed in the
ReflectionAnnotation class. With this construct it should be possible to
use named or unnamed parameters for an annotation.
annotation URL {
public $url;
public $title;
public $target;
public function __construct($url, $title, $target = 'self') {
}
}
[URL('http://www.php.net', http://www.php.net%27, 'PHP', 'blank')] or
[URL('http://www.php.net', http://www.php.net%27, 'PHP')] or
[URL('url' = 'http://www.php.net', http://www.php.net%27, 'name' = 'PHP',
'target' = 'blank')]
With this new type there exists a new language construct which doesn't
overlap with the class construct. So it is possible to use its own
instantiation syntax.
2. The syntax for arrays should be the same as in PHP. So we can use the
[] as annotation separator. When we allow expressions in the form
Annotation(array('value' = 4 %2)) or Annotation(array('value' =
!MY_CONSTANT)) which I think is a valid construct, then we cannot use
the ! or % as annotation separator.
3. For the consistency with named parameters there exists 2
possibilities. Either we implement named parameters in the PHP core or
named parameters are an exception for annotations.
I think with this changes we have a separate language construct like
traits, which does allow a new syntax.
Greetings,
Christian
Am 12.09.2010 00:48, schrieb Stas Malyshev:
Hi!
It seems that there is a misunderstanding about the goals of the
annotations. They are not meant to be read by human being
(javadoc/phpdoc/etc. are) but to be parsed automatically to be used
for services.
If it's for services/phpdoc, why can't it be part of phpdoc?
I see here a whole new language syntax being invented, complete with
nested constructs, new instantiation syntax, new argument parsing
rules and what not. All that while tiniest attempts on introducing
syntax sugar were consistently rejected. But here we have sub-section
of language with totally different rules - PHP has no named
parameters, but annotations have them, PHP has no array/instantiation
shortcut syntax, but annotations have it, etc. Please understand, I'm
not objecting to a particular detail of syntax - I'm objecting to the
fact that the design of the language appears to be guided by a random
whim.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
Hi,
%Annotation(%Email(checkMX = true));
at first I thought what for an ugly syntax. But after a time I think it
is regardless of whether the % or @(from Java, which I prefer over all,
if it were possible) syntax is used. It looks very similar. So I prefer
the % syntax so we can use the [] for defining arrays in annotations. Is
it possible to define objects from type stdClass in the form
%Annotation({key: 'value'})?
An other question. Is it necessary to terminate an annotation with a
semicolon, like in your example?
class Compiler {
/**
* Compile a node into plain PHP.
*
* @param Node $node The node to compile.
*/
%Annotation(%Email(checkMX = true))
%ResourceParameter(['key' = 'name', 'value' = 'annotation'])
%Inject('\my\name\space\Class')
%Test
%Annotation({key: 'value'})
public function compile(Node $node) {
}
}
Greetings,
Christian
Am 11.09.2010 02:23, schrieb Pierrick Charron:
Hi Stas,
Annotations is a new concept in PHP (even if some framework already
use an user space implementation of them) and I think it is normal
that people will have to read a little bit about this eventually new
feature before using it. This is the same thing for traits, if you
don't know what is a trait you will not know how to use them. But once
you know the concept it's really easy to understand what is an
annotation class, parameter etc...
Is it really the [] Syntax that you don't like for annotations ? I was
personally not against the [] array syntax and I understand that this
annotation syntax will make the future implementation of this [] array
syntax impossible. So I could change it to the syntax proposed by
Etienne in the first thread :
%Annotation(%Email(checkMX = true));
I'm not against any other proposal of syntax so if you have one to
proposition do not hesitate.
Regards,
Pierrick
2010/9/10 Stas Malyshev smalys...@sugarcrm.com:
Hi!
[Validation(Email(checkMX=true))] looks better.
Even here it's not clear what is happening. What is Validation, what is
Email, what is checkMX (are they all classes? or only some of them?),
what is happening to them (are these classes being instantiated? when? what
is passed as parameters? What is the scope of that? etc). Why can we have
now two ways to instantiate classes, complete with mix of []s and ()s, but
having array syntax using [] is still too complex?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation RFC + Patch
On Thu, 26 Aug 2010 11:17:33 +0200, Benjamin Eberlei kont...@beberlei.de
wrote:
Hey,
3.
Ok that point may be relevant, but there is also a semantically nice and
simple solution:
array('JoinTable' = array(
'name' = 'users_phonenumbers',
'joinColumns' = array(
0 = array('JoinColumn' = array('name' = 'user_id',
'referencedColumnName = 'id')),
1 = array('JoinColumn' = array('name' = 'user_id',
'referencedColumnName = 'id')),
)
));
[JoinTable(
name=users_phonenumbers,
joinColumns={
{JoinColumn={name=user_id, referencedColumnName=id}},
{JoinColumn={name=user_id, referencedColumnName=id}}
}
)]
I think this gives you the same array structure as in your example but it
uses no nested annotations.
5. You already mentioned further extensions with aliasing class names to
shorten
the annotations specification. However i see several problems with that:
a.) It adds more code
b.) Classes/Methods/Functions/Properties that have annotations of
multiple
annotation libraries
will cause pain with loading or autoloading of the necessary annotation
classes.
c.) What happens if an annotation has no corresponding class?
You write that the developers should implement her complex class based
solution in userland. How would you handle aliasing for classes there?
Anywhere I must define the alias or the namespace of the annotation class,
otherwise I must register all annotations(annotation name = fully
qualified class name) used in my application before using them. Using
annotations from different frameworks with the same name makes this a pain.
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation RFC + Patch
On Thu, 26 Aug 2010 13:56:09 +0200 (CEST), Etienne Kneuss col...@php.net
wrote:
I don't understand why aliasing of class names suddenly becomes an
issue,
we now have namespaces which allow aliases.
use NS\To\MyAnnotation as MyAnnot;
[MyAnnot]
class Foo {
}
there is no need to have this aliasing mechanism at runtime as it will
only add more inconsistency to the plate.
Best,
This was one of the questions I asked in my first mail, but nobody has
answered them.
I think this is the best solution for aliasing annotations.
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Annotation RFC + Patch
Hi,
I love this RFC. But I have a view questions.
1.
Since php does not support named parameter the __construct is called
with an array as parameter
[Foo(bar, baz=baz)]
will call __construct(array(value = bar, baz = baz));
I am a absolute C noob but I have implemented named and unnamed
exceptions in userland. So it should also be possible in C, or not!? Are
the names from the constructor parameters not available through the
reflection API? This may be a little bit more overhead but I think
unnamed annotations are very useful.
[URL('http://www.php.net', 'PHP', 'blank')] or
[URL('http://www.php.net', 'PHP')] or
[URL('url' = 'http://www.php.net', 'name' = 'PHP', 'target' = 'blank')]
class URL extends ReflectionAnnotation {
public function __construct($url, $name, $target = 'self') {
}
}
instead of
[URL('url' = 'http://www.php.net', 'name' = 'PHP', 'target' = 'blank')]
class URL extends ReflectionAnnotation {
public $url;
public $title;
public $target = 'self';
public function __construct($params) {
}
}
For me an additional point for providing unnamed annotations is the
possibility to use type hinting. So it isn't possible to pass an integer
when an array is expected. I know I can validate the parameters in the
constructor. But this is additional work.
2. Is it possible to use nested annotations and what is the syntax?
3.
AliasedName is not implemented yet, but I added in RFC as one of the
first enhancements to be done.
The purpose of it is to reduce the over-typing needed to instantiate
namespaced classes.
Here is the first idea:
ReflectionAnnotation::addNamespaceAlias('Doctrine', 'Doctrine\ORM\Mapping');
[Doctrine:Entity]
would be the same to
[\Doctrine\ORM\Mapping\Entity]
Is it possible to define a use statement for an annotation instead of
defining the namespace alias over the reflection API?
namespace com\mohiva\framework\cache;
use com\mohiva\framework\annotations\File;
[File('/path/to/the/file')]
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespace separator constant
Hi, is there any reason why no namespace separator constant exists in PHP. I have many cases where I concatenate strings to a namespace. This ends up with many class constants like const NS_SEPARATOR = '\\'. A default PHP constant would be a better way to handle such cases. Greetings, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace separator constant
Am 10.08.2010 22:07, schrieb Brian Moon: On 8/10/10 3:03 PM, Ferenc Kovacs wrote: like DIRECTORY_SEPARATOR I guess Tyrael but, DIRECTORY_SEPARATOR is system dependent. The namespace separator is not. It is is always \. OK. This is clear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
I would like to see this in the next major/minor release, together with the traits and the type-hint implementation. This would be a great language improvement. From my end-developer standpoint a big +++ On Wed, 28 Jul 2010 22:49:03 -0300, Felipe Pena felipe...@gmail.com wrote: Hi all, I've updated the patch and the RFC that proposes the return type-hint implementation (Engine + Reflection). The proposed implementation is working just like the last changes in the parameter type-hint (in trunk). i.e. working with the scalar and numeric pseudo-types. http://wiki.php.net/rfc/returntypehint Thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org Sure, you can create an empty interface for this scenario but only for self defined classes. All PHP classes can't used with this interface. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi, I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? What is the next step to get type hinting in the next PHP release, regardless of whether strict or weak? Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Am 17.06.2010 21:14, schrieb Stas Malyshev: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. My view layer accepts only presentation model objects. So every object with public properties can be passed to the the view. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
- trigger_error OR exceptions? (we said, that exceptions shouldn't be allowed inside the core, so maybe this can be only impelemted through spl) I think the exception discussion should be omitted. There exists some other RFCs to fix this issue. http://wiki.php.net/rfc/enhanced_error_handling http://wiki.php.net/rfc/errors_as_exceptions Best regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Traits
A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits
That sounds good and I hope it will be included in the next release. Best regards, Christian Hi: On 04 Jun 2010, at 13:46, Christian Kaps wrote: A short while ago there was a discussion about implementing Traits in the next PHP version. How is the status of this? The code is committed to trunk, and thanks to the community there have already been some improvements and fixes for corner cases. We even got some basic reflection capabilities, too. So, it is there. Now it is just a matter of defining a release and either including it or not... Best regards Stefan PS: Snapshots are here http://snaps.php.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
