Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Mon, Jun 6, 2011 at 12:27 PM, dukeofgaming dukeofgam...@gmail.com wrote: I have a little proposition here. I'm not —at least currently— known for any app or framework, but I'd like my voice to count, that is, if and only if the rest of the community thinks I make sane arguments that are worth considering. I'm perfectly aware that the fame one could gain from taking production code to visible success should be an indicator of an educated opinion, however, I think this might lead to a closed group who can vote, and I like the openness of this community, even if the general process is chaotic, it still gets the warm and fuzzy feeling of an open source community. OTOH, if a completely open group's votes were all considered, the final decision could just end up being a matter of numbers outnumbering other numbers. If I get it right, this is the current problem. So my proposal is that the voting privilege could be given on the basis of a *web of trust*, and if I'm not mistaken this is a little like what the concept of karma works here (I'm fairly new here). Not sure if there should be a voting to elect voters or if it could/should be something more lax, but I don't think the requirement to vote should be fame. I'm similarly placed (as are many here I think), in the sense that I have not done any internals work and I am not one of the lead devs for a well-known project. Much as I think my opinions are great, I don't believe we should have a vote or, if we do, that it shouldn't count for as much as others', for the following reasons: - Long-term commitment: we want people voting who (1) know the history of past PHP discussions on topics and why they were rejected or postponed, (2) understand the PHP way, and (3) have shown commitment to *maintaining* PHP - Perspective: developing *with* PHP is not the same as developing *for* PHP internals. Feasibility, interoperability, maintenance concerns, and more are things that, as long as I've read the list, are often misunderstood or downplayed by people who develop *with* PHP and want a shiny new feature (including me). - Unified vision: we want people who are taking the whole PHP picture into account to be the ones doing the voting. Much of the volume on the list is very narrowly focused - this is a good thing for discussion of specific features, but a bad thing for picking which features to include in PHP. So, I would advocate a white list of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that public opinion can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. Chad Fulton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Mon, May 9, 2011 at 10:46 PM, Lester Caine les...@lsces.co.uk wrote: *IS* it clear by now that the majority of users want this? For what it's worth, I still oppose Annotations. And the argument that 'You don't have to use it' does not wash either since once it has been pushed in, some of the libraries we are using are going to start requiring it simply because those developers do like the idea, but it does not necessarily mean that THE CURRENT PROPOSAL is the right way of doing it? I especially oppose the complexity of the current proposal. One of the reasons I prefer PHPDoc to the proposed Annotations is because they're a simple key=value syntax. I'm already doing my coding in PHP - why do I have to code in a new sub-language when all I want is a litte bit of meta-data? My main question is: Why do we need more than key=value? When you say that everyone supports annotations (if that is true), are you sure they actually want more than key=value? Discussion of this does not seem to appear in your Why do we need Class Metadata? section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
On Tue, May 10, 2011 at 12:35 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi all, Based on an extensive chat with Matthew, I think we reached some consensus. I'll write another RFC related to Annotations in docblocks, then we can chat until reach some standardization and availability. I'll keep the old one for history purposes. It seems that none from core php devs accepted it, so I'll move it to rejected. As I told you previously, all I wanted was some good feedback to give a north and that's what I had. As soon as I finish the new RFC, I'll open another thread here for fine-grain the support and discuss architecture. I'll keep Stas comments in mind when creating it, so it would help in discussions. It seems we still have 2 weeks to discuss the new idea and less than 2 months to get it ready if everyone agreed. Please first take a look at the current RFC regarding parsing docblocks: https://wiki.php.net/rfc/docblockparser . Even if you want to put up a competing RFC, at least you can use it as a point of reference. Chad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
Hello! While I personally like PHP's substr() an awful lot and doubt I would use the str_slice() method, I thought I'd mention that I think what you're proposing is much like the string.substring(from, to) method in Javascript (and PHP's current substr() function is an awful lot like Javascript's string.substr(start, end) method). With that in mind, if this function was to be implemented, I think that naming it substring() instead of str_slice() might make it easier for people to pick up out of the box, since PHP developers often have quite a bit of overlap with Javascript. Chad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Access Modifiers
Hello,
On Wed, Mar 9, 2011 at 10:02 AM, Jarrod Nettles jnett...@inccrra.org wrote:
Interesting question. My gut tells me not (as does three years of C#
experience). I’m sure that everyone will have a different opinion on this but
to me it seems taboo that a child class override the visibility of the parent
class. For example, PHP currently does not allow you to override a method
with a lower or higher visibility than the parent – I can’t go from protected
to public or vice versa. Visibility must be maintained throughout the class
hierarchy.
Actually, class properties and methods can have a higher visibility
than their parents, just not a lower one.
E.g.:
?php
error_reporting(E_ALL | E_STRICT);
class foo {
protected function bar() {
}
}
class baz extends foo {
public function bar() {
}
}
class foobar extends baz {
protected function bar () {
}
}
?
You get the following error:
Fatal error: Access level to foobar::bar() must be public (as in class
baz) in ...
---
That said, I wouldn't think that visibility modifiers on classes need
to follow the same pattern. In the case of properties and methods, I
think the rationale is that child classes should be compatible from an
interface standpoint with their parents. That same logic may not
transfer to class visibility modifiers.
I am certainly no expert, but I'm curious what the use case is for
class visibility modifiers?
On Wed, Mar 9, 2011 at 7:11 AM, Hannes Landeholm landeh...@gmail.com wrote:
Currently I'm forced to use huge internal classes for my framework because
dividing them into smaller classes would expose internal behavior to the
outside... the application layer.
This doesn't necessarily make sense to me. Isn't it the
end-developer's problem if they start instantiating classes in weird
ways?
It doesn't seem the same as having a private method, since in that
case the end-developer presumably already has an object instance, and
you want to guide them to the correct interface for interacting with
it, whereas in an application, one would think that the end-developer
wouldn't simply be instantiating classes by themselves all over the
place.
Chad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: about class names as values
Take this with a grain of salt, but: On Thu, Jan 13, 2011 at 7:22 AM, Martin Scotta martinsco...@gmail.com wrote: Hi all, I don't know how the internal development process of PHP works. First at all: was this feature approved? From my experience, don't consider something approved until it's in SVN, and even then maybe not (e.g. type hinting...), regardless of how many people say I think that sounds like a good idea. if that is a yes... is this feature going to be scheduled for some release? See below. Is it supposed that I will submit a patch? Mostly, the burden is on the person requesting a feature to submit a patch, if for no other reason than that everyone is busy and that, as the requester, you probably have the most interest in getting the feature implemented. Once a patch is out there, you're going to need to convince at least one core dev to get behind your idea, since they are in the position of getting it into SVN, and they have the best big picture view of PHP. The core devs do often seem happy to help improve patches, if they think they're worthwhile. Then, perhaps it will get into SVN if a core dev likes it and no core devs oppose it too much. Then, perhaps it will be scheduled for a release. Thanks you all, Martin Scotta -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com wrote: On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com wrote: First i have to say that I am not a PHP internals developer, but as a user I think it would maybe be better to just let the trait use the implements keyword, and copy that to the classes utilizing the trait? This is actually in the RFC as a rejected proposal http://wiki.php.net/rfc/traits#rejected_features But what I'm talking about is something different. We're not trying to say 'these are the methods implemented in the trait', rather, 'this trait expects a class it is used with to be of a certain type or implement a certain interface' for the trait to do its job. -nathan Shouldn't the burden be on the programmer to make sure the trait works with the class using it rather than on the compiler? If they try to use a trait that requires methods that don't exist, it will error out anyway, so it won't be difficult to debug. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 10:39 AM, Nathan Nobbe quickshif...@gmail.com wrote:
On Fri, Dec 10, 2010 at 11:04 AM, Chad Fulton chadful...@gmail.com wrote:
On Fri, Dec 10, 2010 at 9:29 AM, Nathan Nobbe quickshif...@gmail.com
wrote:
On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.com
wrote:
First i have to say that I am not a PHP internals developer, but as a
user
I think it would maybe be better to just let the trait use the
implements
keyword, and copy that to the classes utilizing the trait?
This is actually in the RFC as a rejected proposal
http://wiki.php.net/rfc/traits#rejected_features
But what I'm talking about is something different. We're not trying to
say
'these are the methods implemented in the trait', rather, 'this trait
expects a class it is used with to be of a certain type or implement a
certain interface' for the trait to do its job.
-nathan
Shouldn't the burden be on the programmer to make sure the trait works
with the class using it rather than on the compiler? If they try to
use a trait that requires methods that don't exist, it will error out
anyway, so it won't be difficult to debug.
Well I know PHP is a dynamic language but what about all the compile time
features that have come along over the years. The abstract keyword for
example vs. the PHP4 way of implementing an 'abstract' method which was
triggering an error in the default implementation in a base class.
One of the main things a lot of PHP programmers I've worked with hate is
waiting for code to hit production and encountering a runtime error w/
something that could have been caught at compile time. I know the notion of
compile time in a scripting language like PHP is much less removed from that
of C++, Java etc, however there is a notion of it there, obviously.
Also, I would suggest this feature be optional, so there is no need to use
it if you don't like it. But for those of us who would like to defer as
much type checking to the compiler as possible so we don't need runtime
checks all over our code or prayers that we've tested every line before
production, it would certainly be nice.
Lastly, you may know that traits will allow PHP programmers to move away
from the delegate pattern which is a common workaround to multiple
inheritance at this point. However, in speaking with a colleague over the
concept I'm proposing yesterday we discovered the delegate model actually
does allow you to specify which class/interface the delegate is used w/, it
would be sad not to see comparable support in the trait feature which will
mostly eliminate the need for the delegate pattern, see my quick example.
?php
class MainClass {
private $_oDelegate = null;
function addDelegate() {
$this-_oDelegate = new Delegate($this);
}
}
class Delegate {
private function $_oMain = null;
/// delegate gets to say what it can be used with via type hinting
function __construct(MainClass $oMainClass)
{
$this-_oMain = $oMainClass;
}
}
?
Imagine how much cleaner this could be w/ traits, yet just as expressive
?php
class MainClass {
use Delegate;
}
trait Delegate require MainClass {
...
}
?
-nathan
As a note, I'm not strongly opposed to this proposal, since I don't
think it would do any harm. It just seems to me like a kitchen sink
feature.
The issue for me is that traits, as I understand them, are there
primarily for horizontal code re-use via compile-time copy/paste.
With that in mind, I feel like the developer is responsible for making
sure the methods they copy into their classes make sense, just as they
would have to do if they physically copied and pasted them.
I think your example above isn't quite what you meant to show, since
you're requiring a specific class and not an interface (since PHP only
allows one class definition for a class name, you're not gaining
anything via traits, since the trait could only be used for that
specific class, in which case why not just have the code in the class
in the first place?).
If we take your example in a more general case using interfaces, I
still can't see what the benefit is. All it does is provide a more
explicit and immediate error message for developers (e.g. instead of
method not found error when the bad method call is made at runtime,
you get a classes using trait trait must implement interface at
compile time).
Again, I'm not against it, but maybe be too much hand holding, since
the developer should make sure using the trait makes sense first?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
On Fri, Dec 10, 2010 at 1:00 PM, Nathan Nobbe quickshif...@gmail.com wrote: As a note, I'm not strongly opposed to this proposal, since I don't think it would do any harm. It just seems to me like a kitchen sink feature. The issue for me is that traits, as I understand them, are there primarily for horizontal code re-use via compile-time copy/paste. With that in mind, I feel like the developer is responsible for making sure the methods they copy into their classes make sense, just as they would have to do if they physically copied and pasted them. Copy paste itself leads to duplicated unmaintainable code, so traits are introduced (among other reasons) to prohibit this practice. Why not take it a step further and let a trait definition be as expressive as possible, eliminating ambiguity, right out of the gate? I think your example above isn't quite what you meant to show, since you're requiring a specific class and not an interface (since PHP only allows one class definition for a class name, you're not gaining anything via traits, since the trait could only be used for that specific class, in which case why not just have the code in the class in the first place?). In retrospect Chad, that's a good point, and perhaps there is no reason to allow marking of classes as required by traits. If we take your example in a more general case using interfaces, I still can't see what the benefit is. All it does is provide a more explicit and immediate error message for developers (e.g. instead of method not found error when the bad method call is made at runtime, you get a classes using trait trait must implement interface at compile time). Exactly, catch it at compile time rather than runtime, that's all it is really, just like the benefit of discovering a given subclass doesn't implement a given abstract method so that I don't go any further and run code guaranteed not to work. Again, I'm not against it, but maybe be too much hand holding, since the developer should make sure using the trait makes sense first? Couldn't the same be said for a developer extending an abstract class, or implementing an interface? And also, a developer is to look through the entire definition of a trait to know which methods it's going to depend on? I know abstract is there as Stefan showed, but as we've both observed that approach can get messy quickly. -nathan I think that you make a convincing argument. Thinking more about your Iterator example, this idea makes a lot of sense and could be quite useful. Also, I was wrong about requiring a class. It could be very useful, especially if it is an internal class (e.g. ArrayObject) which might have many children, and of course in this case the parent can't be changed. I think the require keyword works well. -- 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
Having thought a bit about this, there are a couple of initial
problems I see, and, more importantly, I'm not convinced that the
stated problem (encapsulation) requires the addition of a new language
construct (i.e. a property as distinct from a class member). In
fact, I think it is better implemented in another way (see below).
First of all from a confusion point of view, PHP already has defined
property in a way that opposes your RFC's definition:
property_exists() checks for the existence of what you call a class
member. So, at least, it seems to me you would have to find new
terminology if you wanted to pursue this avenue of a new construct.
In my opinion, however, there should not be a new construct, and
property and class member should remain interchangeable
descriptions of the same class construct. I think we can do this and
still fix the encapsulation problem.
(Note: this is a long e-mail, and probably best represented in a new
RFC. I have also written this up more completely in the form of an
RFC, but I don't want to clutter up the wiki's RFC page unless other
people like this idea as well, so I'll add the RFC if it looks like it
will be useful).
For example, we could do:
class Time {
protected $time;
// note that $seconds, $minutes, and $hours are, in this
// implementation, dummies, since they will never hold
// a value, because their set functions only set the $time
// class member.
public $seconds;
public $minutes;
public $hours;
public function issetTime($name) isset($hours,$minutes,$seconds) {
return isset($this-time);
}
public function unsetTime($name) unset($hours,$minutes,$seconds) {
unset($this-time);
}
public function setTime($name, $value) set($hours,$minutes,$seconds) {
switch($name) {
case 'hours':
$this-time = $value * 3600;
break;
case 'minutes':
$this-time = $value * 60;
break;
case 'seconds':
$this-time = $value;
break;
}
$this-seconds = $seconds;
}
public function getTime($name) get($hours,$minutes,$seconds) {
switch($name) {
case 'hours':
return $this-time / 3600;
break;
case 'minutes':
return $this-time / 60;
break;
case 'seconds':
return $this-time;
break;
}
}
}
with this syntax, you could group the properties like above or, if you
preferred, you could have a different function for each property.
for read only (similar for write only), including the possibility of asymmetry:
class Time {
protected $time;
public $seconds;
public $minutes;
public $hours;
// ...
// now Time::$hours can only be set from inside the class / descendents
protected function setHours($name, $value) set($hours) {
$this-time = $value * 3600;
}
// but Time::$hours can still be retrieved from outside the class
public function getHours($name) get($hours) {
return $this-time / 3600;
}
}
for interfaces:
interface TimeClass {
public function setHours($name, $value) set($hours);
}
This has a number of benefits:
1. This acts like PHP, and also brings along features out of the box
(a) The new syntax mimics the form of the syntax of closures ($x =
function() use($a, $b) { // ... };), so it is somewhat familiar.
(b) The arguments of the isset, unset, getters and setters is
analogous to that in the __get and __set methods, so userland
implementation will be familiar.
(c) The getters and setters are still regular class methods, so they
can be called as methods as usual (subject to visibility, of course)
(d) Adds shades to the read-only and write-only concepts via
visibility modifiers!
(e) Isset / unset make sense now! E.g. that when unsetting $hours, we
actually want to unset the time in general. In fact, this is
preferred, because in the examples we've been looking at, the magic
is in grouping the three class members (seconds, minutes, hours),
and this implementation of isset and unset allow you to do just that
grouping, without having to write 3 isset and 3 unset functions, as
you would have to in the property definition.
(f) This allows for much more compact class definitions, as you don't
have to define getHours(), getMinutes(), getSeconds() individually if
you don't want to (although it allows you the flexibility to do that
if it's what you want).
(g) Inheritance works out of the box.
(h) Final keyword works out of the box.
(i) Documentation works out of the box (just do it as you do it now,
on the class members and the methods).
(j) Interfaces work.
(k) In the example above, the class could go ahead and set the
Time::$time class member directly without incurring the overhead of
the getter / setter functions!
2. Fixes the stated problems
(a) Adds the syntactic sugar to
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
christian.k...@mohiva.com wrote:
...
/**
*
*/
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
For whatever it's worth, I think that this syntax fits much better
into PHP than do either of the those in the RFC.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support discussion
On Tue, Nov 16, 2010 at 6:03 AM, Lars Schultz lars.schu...@toolpark.com wrote: Hi, I certainly don't have PHP-Karma (Does meritocracy really refer to that?), but simply I can't believe that you're talking about this, again. I think Annotation-Supporters have made their point, but shouldn't they let the PHP 5.4 Developers get on with it and let them roll out a new version instead of forcing them to reply to lengthy emails about the same topic over and over again. One could almost believe that you're hoping to drown their voices by frustrating them into not replying anymore, therefore winning your vote. cheers. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php ^ I agree. I also don't think you can discuss annotations without simultaneously discussing their implementation. To me, it looks like you're trying to force through a vote on a very vague topic should PHP support Annotations, and then use that vote later to force through an implementation that many core people have already said is not desirable. Many of the arguments that are central to the question of should PHP support Annotations MUST deal with their implementation because they add a large new set of syntax to the language. I doubt anyone would support annotations at any cost, and yet that's the vote you're trying to force here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
For me, the syntax, or at least the complexity, is important. I like the idea of metadata, but what I found attractive about the docBlock parsing was that it only allowed key/value pairs of meta-data. -1 for annotations in which the engine instantiates arbitrary annotation objects. On Thu, Sep 16, 2010 at 7:58 AM, Christian Kaps christian.k...@mohiva.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] docBlock Parser RFC
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] docBlock Parser RFC
Hello,
Yes, this is not an RFC for annotations or to replicate the exact
functionality you wanted within doc comments.
However, there is support based on the annotations thread for APIs to
parse doc blocks. I don't know what is meant by others (Zeev, Stas,
etc) when they say this. However, in writing this RFC I was nailing
down my interpretation of it. It may not be what they had in mind at
all, and that's fine by me.
I think that this approach has merit *because* of its simplicity. I
also think that the use cases mentioned in the Annotations RFC could
be equally served by this approach (PHPUnit, Doctrine, etc).
If you look at your own example above, the @ReadOnly, @PropertyGetter,
@ClassInvariant, and @InstanceInvariant are all trivially replicated
using the doc block approach. I strongly suspect the others would be
too, except that I'm not sure exactly what you meant by them.
I wrote this because it seems to me from comments in the annotations
thread that the main problem with the annotations RFC is that it mixes
something people want (simple metadata) with something people don't
want (new rules and a new syntax). It's definitely possible that I'm
wrong about this.
Either way, I think this would be a nice thing to have.
Thanks,
Chad
On Thu, Sep 16, 2010 at 3:34 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Thu, 16 Sep 2010 21:56:04 +0100, Chad Fulton chadful...@gmail.com
wrote:
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.
Pointless.
Well, this will maybe speedup and standardize the usage of doc comments, but
it's very far from what we could do with real annotations.
By real annotations, I mean something the engine would recognize and that we
could use in the future to implement AOP functionality with annotations or
to implement other new features in the future, e.g.:
class A {
�...@readonly
public $var;
�...@propertygetter(virtualPropertyName)
public function baz() { }
�...@classinvariant
public static function bar() { }
�...@instanceinvariant
public function foo() { }
/**
* A closure that could be called as if it were a non-static method
* and which would be automatically rebound.
* @var Closure
*/
�...@methodclosure(staticMethod = false, rebind = true)
public static $clos;
�...@before(self::whatever, instance=true) /* Or @After, or @Around */
�...@log(entering foobar) /* user-defined specialization of Before */
�...@precondition(...)
public function foobar() {}
}
The current implementation would not allow any of this, but at least it
opened way. A doc comment parser...
--
Gustavo Lopes
--
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] docBlock Parser RFC
Hello!
That is a good point, there would be no file-level doc block in the
RFC. Here is my reasoning for not including it in the RFC:
Since the motivation for this came from the desire for metadata for
PHP structures, it seemed inappropriate to include metadata at the
file level (since it's not a php structure).
As for the @Validator('blahbla'), I had thought it could be replicated with:
/**
* @Validator blahbla
*/
How to do multiple arguments would be up to user-land functions that
used the parsed doc comments, but one possibility is:
/**
* @Validator foo bar baz
*/
then when you wanted to retrieve these, you could do explode(' ',
$tags['Validator']); or similar.
However, more specific syntax could be added to allow arguments in
the doc block tags. I just feel like in this case absolute simplicity
is important.
Chad
On Thu, Sep 16, 2010 at 2:23 PM, Christian Kaps
christian.k...@mohiva.com wrote:
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
--
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
Since the parsed version of the docblock would only be accessible through a reflection method, you would have to specifically request it for it to be parsed and given to you as an object or array. Also, it would only be parsed, not executed; I don't think that this is proposing executing comment blocks. I for one would give a huge +1 to adding a function which parses docblocks. I would love to see a simple approach, like the one below: A docblock like the following: /** * (Short Description of the DocBlock) * * (Long Description of the DocBlock ... * continues... * * continues...) * * @tag1 value1 * @tag2 value2 * @tag3 value3 */ Would be parsed to return an array or object like the following: Array ( 'short_description' = ' (Short Description of the DocBlock) ', 'long_description' = ' (Long Description of the DocBlock ...\ncontinues...\n\ncontinues... ', 'tags' = array( 'tag1' = 'value1', 'tag2' = 'value2', 'tag3' = 'value3, ) ) The actual rules could be whatever people like most (I think JavaDoc has some fairly explicit rules that could be borrowed from). I would be happy to write an RFC laying out a sample if there is any interest in this, although I don't have permissions to post it on the wiki. This would *also* introduce new syntax into PHP. However, this syntax is widely used already, I think. It would be backwards compatible for current implementations already using the docblocks, since they could continue to use Reflection::getDocComment() to retrieve the string (and of course phpDocumenter uses tokenizer, I think). I think that for the use cases mentioned, there is no great win to be had by having the PHP engine instantiate objects automatically. The most important problem that I think people are asking for annotations to solve is that there is no standardized way to read elements' metadata, and there are simple, effective ways to do it (e.g. the above). At the very least, I think that this would be a nice feature even if annotations as a language structure were to be implemented in the future, and the parsed docblocks would give us more information about what works and what doesn't. On Wed, Sep 15, 2010 at 9:22 AM, James Butler james.but...@edigitalresearch.com wrote: I might be wading into this a bit fast but At a very simple level, comments are not meant to be parsed by design. Hence commenting out code so it is not parsed! How would one tell the parser not to read docblock annotations as there wouldn't be a mechanism to comment them out? Lots of people use comments to stop some of their code being executed for testing etc. I'm indifferent currently towards annotations and their usefulness but I really don't think they should sit in comments -Original Message- From: Guilherme Blanco [mailto:guilhermebla...@gmail.com] Sent: 15 September 2010 17:18 To: Lars Schultz Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch It's curious that you keep complaining about new syntax and propose a new one at the same time. [Foo] introduces new concept, use /** @Foo */ or /** [Foo] */ instead. What's the point then? I think meta programming is not and would never be part of comment. As previously said, docblock means documentation, without any meaning to parser, entirely human readable and totally removable without affecting overall execution. Something that HAS a meaning to execution means something out of the userland comments. Point made. Cheers, On Wed, Sep 15, 2010 at 6:45 AM, Lars Schultz lars.schu...@toolpark.com wrote: listen to this man;) I think he's on to something. I don't see any problem with that aproach and both parties would be satisfied, no? Am 15.09.2010 10:45, schrieb Benjamin Eberlei: Hi Zeev and Stas, I wouldnt mind extending doc block metadata support instead of adding a new syntax. I agree with you that PHP Docs allow metadata and they can be used for that (and some people do, including me), however what the annotation patch + rfc tries to achieve is something going beyong $refl-getDocComment() returning a string only. The string only return leads to hunderets of different approaches for annotating metadata in all the different frameworks and libraries. A single unified syntax would be benefitial. That is why I don't know if it will even be possible to extend the doc blocks in a generic way that does not break half the applications out there. When extending doc-blocks there is probably new method required $refl-getParsedDocComment() which then returns an array of metadata for that particular refl instance. Now here the syntax would be a problem, can we find something that does not break for all the different usages of docblocks out there? Since the method/parsing would be nested, on request only it wouldnt break any application that does not use parsed doc comments.
Re: [PHP-DEV] Strict typing
anyway .. for the love of god, could be please stop arguing in circles, nothing .. really nothing that people brought forth pro/con any approach in regards to type checking/hinting whatever hasn't been mentioned on this list multiple times. +1 please please please please .. read the RFC's on the wiki .. if there is something not mentioned there .. ask the author of the RFC why that is and see if they are willing to add it there and notify the list once. If the author in question is unwilling to add it .. then .. and only then bring it back to this list. +1 regards, Lukas Kahwe Smith m...@pooteeweet.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] Type hinting
Hello! As I mentioned, I think that we have to inform the caller about the problem (be either a type or a conversion mismatch), so the only options to trigger an error, or throw an exception. I like the exception idea better, because it can be easily handled localy (no need to register a global error handler), but as the core devs said, it isn't allowed to throw exceptions from the core, so this is why I think, that the weak type hinting should be implemented as an spl interface. This way we could even support array - ArrayObject conversion too. http://wiki.php.net/rfc/splweaktypehintingwithautoboxing I'm not sure what is being added by using the SPL interface except a way to justify throwing exceptions on type mismatch with data loss? The only reason I can think of for throwing exceptions in this case would be data validation purposes, which I think is not the intention of type hinting, and also not the intention of exceptions (users inputting bad data is not an *exceptional* occurrence imo). Is there some other reason / use case for wanting exceptions? So, I mean, where is the use case where '123abc' will be passed to a type-hinted field where you could catch the exception and do something meaningful to carry on with the execution of the program other than simply error-ing out? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
Hi! Pretty much everywhere. Suppose you have form with, say, 2 fields and first field does not validate. Maybe you want to check the second field too and give the user both errors if they are both wrong? In general, looking at strict typing as user input validation mechanism is a very bad idea. There are specialized use input validation functions/classes/frameworks, and one should use them. Right, that was my point. I can't think of any good reason to use exceptions rather than global errors (E_NOTICE or E_STRICT or similar), but some people seem to want exceptions. I was asking them if they had use valid cases (e.g. *not* data validation or similar which is undoubtably foolish) that would merit using exceptions rather than the global error handling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] backslash, really ... ?
You can take a look at the RFP if you like. It discusses the pros and cons of various possible separators, and why they chose the backslash. http://wiki.php.net/rfc/namespaceseparator http://wiki.php.net/rfc/namespaceseparatorI've been using namespaces for a few months now with the backslash syntax, and I have to say that it doesn't effect the aesthetics or readability of my code. Give it some time, I suspect you'll get used to it in no time. On Wed, Apr 28, 2010 at 3:23 PM, Sylvain Rabot sylv...@abstraction.frwrote: On Wed, 2010-04-28 at 16:58 -0500, Matt Wilson wrote: So, you decided to jump in to criticize a design decision that went in after several months of discussion, without any insight into why it was done the way it was? Not really criticizing, maybe a bit, but more expressing my disappointment regarding aesthetic loss that the choice made has lead to. It might not concern you but it does concern me and probably other people too. I admit I have no knowledge of what have been told during the months of discussion you are referring to. However, you seem to have this knowledge, so I would be grateful if you could tell me if the aesthetic of the backslash token has been discussed and even more if you can redirect me to a discussion thread. Regards. On Apr 28, 2010, at 4:45 PM, Sylvain Rabot wrote: Hi, The comment I'm about to make is behind the times, and, now, useless, I know, but I can't hold me. You chose for the namespace feature, a great feature besides, the backslash ?? really ?? Come on guys, among all the possibilities, you have chosen, according to me, the most hideous character possible. Having Windows©®™ path like strings in the middle of source code is not something that is going to make me use the feature. PHP syntax was simple, clean. To me, the backslash token ruins everything. Using it aside from escaping was something I have never considered, have you ? Do you like it ? The goal of backslash was maybe to highlight namespace in the source code, if it was, congrats, we only see that now. To my opinion it breaks all esthetic's balance of a source code. No need to respond that I should have contribute to the choice, believe me, if I could have, I would have. This was just the comment of a simple guy which is very concerned about source code esthetic's and believes that a neat, well balanced code is more likely to be well maintained that any other one. Best regards. -- Sylvain Rabot sylv...@abstraction.fr -- Sylvain Rabot sylv...@abstraction.fr
