Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks
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?
Or does that seem illogical when the trait does not implement all of the
methods specified by the interface?
(Because I think expects might be a common name in APIs for some kind of
validation.)
Best Regards
Martin Wernstahl
On Fri, Dec 10, 2010 at 18:09, Stefan Marr p...@stefan-marr.de wrote:
Hi Nathan:
On 10 Dec 2010, at 17:49, Nathan Nobbe wrote:
Def not :D, however, I still think this paradigm is lacking. Don't you
think it makes more sense if I write a trait that expects a given interface
or class to be able to specify said interface/class in it's entirety with
just a single identifier rather than listing out all the methods?
For example, I think this would be ugly
?php
trait IteratorHelper{
abstract public current();
abstract public key();
abstract public next();
abstract public rewind();
abstract public valid();
}
?
essentially you're redeclaring the entire interface in the trait, the
same would be true of the public interface of an expected class. i think it
would be much more elegant to allow a specification on the trait declaration
itself, something like
?php
trait IteratorHelper expects Iterator {
...
}
?
:D That was exactly my thought when I was writing my first answer.
My second thought was, damn, not another keyword...
But since you also seem to see the need, we should give it a thought.
Anyone else with an opinion on that?
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
--
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
Oh, sorry, should have read the RFC thoroughly before sending an email. But yeah, require might be a good choice, provided it doesn't collide with the specific require logic in the scanner/parser (I don't have much knowledge on that subject, but I've peeked a few times on it as it is interesting). Best Regards Martin Wernstahl On Fri, Dec 10, 2010 at 18:29, Nathan Nobbe quickshif...@gmail.com wrote: On Fri, Dec 10, 2010 at 10:15 AM, Martin Wernstahl m4r...@gmail.comwrote: 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
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
@Johannes:
The T_STRING token never contains $, AFAIK all identifiers starting with
$ are instead classed as T_VARIABLE tokens.
So you'd search for the visibility modifier (+ static, etc.) + T_STRING for
methods, and visibility (+ static) + T_VARIABLE for properties.
Martin
2010/11/27 Johannes Schlüter johan...@schlueters.de
On Sat, 2010-11-27 at 23:14 +0100, Johannes Schlüter wrote:
[ T_PUBLIC | T_PROTECTED | T_PRIVATE | T_STATIC | T_ABSTRACT ] { }
T_STRING ( param_list ) { { statement_ist } }
I forgot T_FINAL there.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New to the PHP internals and I want to help
Hi! I'm an 18 years old student from Sweden with an interest in programming, particularly in solving more complex problems (like creating a database abstraction, advanced template parser etc.). I use PHP because it is a very nice and adaptable language, and I work as a web developer in my free time. I've wanted to add a few features to PHP for some time (a few years ago I tried to implement closures, but it didn't go well because I didn't really know where to start - by the way, I really like the current implementation of closures so far!). Does anyone have somewhere to point me for resources on how to modify the PHP core? (More specifically, add/modify things to/in the Zend engine) I'm attempting to implement a kind of extend-on-the-fly thing, so it would be possible to add and replace methods on classes on the fly (for example it would be helpful when extending classes and still wanting to refer to them by the same name, eg. in a framework). I've tried a few things but I cannot get the parser to parse the syntax correctly, it always complains about a T_STRING that according to my rules *should* be there but it thinks not. I haven't been able to get much information about re2c, so I'm grateful for help and/or links. Also, if you think I should start by creating/modifying/fixing something else (that is easier) in the PHP core, just tell me ;) Best Regards Martin Wernståhl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
