[PHP-DEV] rfc:trailing-comma-function-args
I've been thinking about this RCF for a while now:
https://wiki.php.net/rfc/trailing-comma-function-args
It just doesn't seem necessary - the only time I've ever found something
like this to be necessary, is when a function takes closures or other very
long arguments, some of which are optional... but actually, writing this in
a VCS-friendly way is already possible:
$tree->traverse(
$tree
,
function($node) {
// ...
}
);
... version 2 ...
$tree->traverse(
$tree
,
function($node) {
// ...
}
,
function($node) {
// ...
}
);
This actually comes out more legible, in my opinion.
What really irks me about this patch, is that the trailing comma implies
that another optional argument may exist - it really doesn't make the code
more intuitive to read. The example on the page (using fopen) really isn't
a realistic use-case - who would break a couple of simple arguments into
individual lines like that?
Just my two cents...
- Rasmus
[PHP-DEV] short syntax for construction/initialization, named arguments and (future) annotations
This is a not a feature request, just a note on something that occurred to
me.
Since there is talk of native support for annotations again, it occurred to
me that part of the problem that every userland implementation and proposed
syntax deals with, along with native implementations in other languages, is
that of convenient short-hand syntax for construction and initialization
(of annotation objects.)
A constructor is a method with arguments, so a single familiar syntax
really could (perhaps should) be applicable in all of those cases.
How about something like this?
class Foo
{
public $bling;
public function __construct($bar, $baz)
{
}
// (sample annotation)
public function setName($first, $last)
{
}
}
$test = new Foo({ bar='bar'; baz=123 }) { bling = 'wibble' };
// equivalent to:
// $test = new Foo('bar', 123);
// $test->bling = 'wibble';
$test->setName({ last='Kong'; first='Donkey' });
// equivalent to:
// $test->setBar('Donkey', 'Kong');
So in other words, a unified syntax for named (constructor and method)
arguments, and property-initialization with the "new" keyword - all of
which could be statically checked (in IDEs), as could the property-values
for an annotation instance.
This could mitigate a lot of crappy stuff you see in (even the leading)
frameworks right now, where far too frequently, initialization and
configuration, as well as "named arguments", are implemented as nested
arrays, to which you cannot apply any kind of static analysis.
Proposed annotation syntaxes (and some syntaxes in other languages)
typically address this issue by introducing special syntax for annotations,
which are a good example of where property-initialization is heavily used
and benefits greatly from static checking, auto-complete in IDEs, etc.
Just throwing that thought out there. Try not to get hung up on the syntax
in the example above, I just came up with something on the spot, just to
provide some context.
Re: [PHP-DEV] rfc:foreach-non-scalar-keys
I'm not sure how I came to that conclusion - did the description change
since I looked at it?
I guess the title "foreach-non-scalar-keys" may have thrown me off - so
this isn't about arrays, or really even about foreach, but about the
Iterator interface. I'm not against that at all.
I would suggest considering the addition of a second, distinct interface -
rather than a modification to the existing interface, which already does
what it's supposed to and works well, including the warning, which is
appropriate for the intended use of that interface with the foreach
statement.
This alternative interface could have the opposite behavior - issuing a
warning if the returned key is not an object. I don't think there's a
legitimate use-case where mixing scalar and object keys would be a good
idea? (if there were, a single interface might be the only way to go.)
On Tue, Jan 29, 2013 at 8:34 AM, Etienne Kneuss wrote:
> This RFC is not about arrays.
>
> The proposed change is to allow Iterator::key() to return things other
> than int/strings. Consequently, it would mean foreach($iterable as
> $key=>$foo) { $key can be an object here }.
>
> SplObjectStorage "solves" it by returning an array() of
> object-key/object-data as *value*, and an integer as key, which is not
> ideal.
>
> Best,
>
>
> On Tue, Jan 29, 2013 at 2:15 PM, Anthony Ferrara wrote:
>
>> Rasmus,
>>
>> Relax. It hasn't even been proposed yet. Give the author some time to
>> finish the RFC before proposing it here, and then we can discuss it...
>>
>> Anthony
>>
>>
>> On Tue, Jan 29, 2013 at 8:03 AM, Rasmus Schultz
>> wrote:
>>
>> > I just saw this RFC:
>> >
>> > https://wiki.php.net/rfc/foreach-non-scalar-keys
>> >
>> > By "non-scalar", presumably we're talking about objects? In the numbers
>> > that e.g. resources typically get used, having a collection indexed by
>> > resources would seem like an extremely exotic need.
>> >
>> > Moreover, we already have this:
>> >
>> > http://php.net/manual/en/class.splobjectstorage.php
>> >
>> > I just want to note that, while allowing non-scalar keys may seem like a
>> > natural addition, we're not talking about a simple change to the foreach
>> > statement - we're talking about a fundamental change to the array type.
>> >
>> > So I will point out two things:
>> >
>> > 1. Allowing non-scalar keys in arrays takes away an error-condition that
>> > would normally be reported: accidentally using an object as a key (which
>> > could even work in some cases, and could cause objects not to be garbage
>> > collected.)
>> >
>> > 2. SplObjectStorage already solves this problem - minus e.g. resources,
>> but
>> > you could put your resources in an object and address that (very exotic)
>> > need.
>> >
>> > Bottom line, I'm not in favor of this idea - it just doesn't seem
>> necessary
>> > or really even beneficial to me.
>> >
>> > - Rasmus Schultz
>> >
>>
>
>
>
> --
> Etienne Kneuss
> http://www.colder.ch
>
[PHP-DEV] rfc:foreach-non-scalar-keys
I just saw this RFC: https://wiki.php.net/rfc/foreach-non-scalar-keys By "non-scalar", presumably we're talking about objects? In the numbers that e.g. resources typically get used, having a collection indexed by resources would seem like an extremely exotic need. Moreover, we already have this: http://php.net/manual/en/class.splobjectstorage.php I just want to note that, while allowing non-scalar keys may seem like a natural addition, we're not talking about a simple change to the foreach statement - we're talking about a fundamental change to the array type. So I will point out two things: 1. Allowing non-scalar keys in arrays takes away an error-condition that would normally be reported: accidentally using an object as a key (which could even work in some cases, and could cause objects not to be garbage collected.) 2. SplObjectStorage already solves this problem - minus e.g. resources, but you could put your resources in an object and address that (very exotic) need. Bottom line, I'm not in favor of this idea - it just doesn't seem necessary or really even beneficial to me. - Rasmus Schultz
Re: [PHP-DEV] annotations, vision, goals
I'm sorry, I guess I wasn't real clear on that - I've always known this
feature as a source directive, guess I didn't know that's not really an
established term.
What I'm referring to is much simpler than what you suggested - it's just
an equivalent to the "source" pre-processor directive in for example C:
http://msdn.microsoft.com/en-us/library/b5w2czay(v=vs.80).aspx
In PHP, this would probably be done using the directive keyword:
http://php.net/manual/en/control-structures.declare.php
It might look something like this:
declare(source=foo/bar.zzz#123) {
// ...
}
Any code that throws (or triggers an error) while the directive is active
will report the source of the error as line 123 in the file "foo/bar.zzz" -
it doesn't seem like a big or complicated feature? And it's a well
established idea that works essentially the same in any language that
supports it.
But it would enable pre-processors to accurately report the source of an
error as occurring not in some temporary generated file, but in the
source-file that generated that line.
As said, this is just an example of a much smaller feature that could have
a bigger impact, but cannot be implemented in userland. Not necessarily the
best (or the only) feature that could enable better implementations of
something like annotations - or many other nice patterns that aren't being
done (or done well) in PHP at the moment...
On Sat, Jan 12, 2013 at 1:00 PM, Nikita Popov wrote:
> On Sat, Jan 12, 2013 at 5:29 PM, Rasmus Schultz wrote:
>
>> I hear a lot of interesting arguments in this big annotation discussion,
>> and now there's the ongoing vision discussion, which got me thinking.
>>
>> It is true that there is broad community interest in annotations - part of
>> the problem here, is that different groups have differing opinions about
>> precisely what annotations are, how and when they should be used, the
>> syntax, and a bunch of other things.
>>
>> To name a similar example, there is also broad community interest in
>> e-mail
>> clients - and countless userland implementations. Nobody is pushing for a
>> standard e-mail client in PHP. Granted, e-mail is a run-time library
>> feature, not a language feature, but I don't think it's an unfair
>> comparison, since annotations aren't really so much a language feature
>> either, if you think about it - much of the discussions revolve around API
>> issues, and like someone pointed out, you could do metadata in other ways,
>> without altering the language or parsing docblocks.
>>
>> I'm not making this point to argue against annotations, but it lead me
>> back
>> to another idea that has surfaced in discussions before: a
>> source-directive
>> feature.
>>
>> This sounds like a much smaller feature, which would be much simpler to
>> define and agree on, and much simpler to implement.
>>
>> A source-directive would empower the community to define and implement the
>> syntax, and not only for annotations, but for other features, such as
>> aspect-oriented programming, which I believe was once proposed as an RFC
>> (?) and declined, probably for the same reason... it's a feature with too
>> many variations and opinions, lots of complexity, and it's probably
>> another
>> one of those language-features where the discussions end up revolving
>> around run-time issues more so than language/syntax.
>>
>> It would be nice if every developer in the world could all agree on
>> everything. But we can't, we don't, and we're not going to - and that's
>> not
>> a bad thing, because it means PHP is open for innovators to find better
>> ways to do certain things in userland :-)
>>
>> The big advantage to having something like implemented and maintained in
>> userland, is that these features can thrive and grow if they turn out to
>> be
>> successful - or, if everyone decides in a year or two that annotations
>> suck, they can stop using them and move on to something else. It also
>> means
>> that developers don't need to wait for a year or more for their sysadmin
>> to
>> deploy the next minor PHP update that fixes a bug or makes a minor
>> addition
>> to that feature.
>>
>> Perhaps it's time to think about "lower level" language features that
>> facilitate implementing "borderline" language-features, and enable the
>> community to write better, more reliable implementations of things like
>> annotations and AOP, rather than writing it for them?
>>
>> And perhaps a source-directive isn't the solutio
[PHP-DEV] annotations, vision, goals
I hear a lot of interesting arguments in this big annotation discussion, and now there's the ongoing vision discussion, which got me thinking. It is true that there is broad community interest in annotations - part of the problem here, is that different groups have differing opinions about precisely what annotations are, how and when they should be used, the syntax, and a bunch of other things. To name a similar example, there is also broad community interest in e-mail clients - and countless userland implementations. Nobody is pushing for a standard e-mail client in PHP. Granted, e-mail is a run-time library feature, not a language feature, but I don't think it's an unfair comparison, since annotations aren't really so much a language feature either, if you think about it - much of the discussions revolve around API issues, and like someone pointed out, you could do metadata in other ways, without altering the language or parsing docblocks. I'm not making this point to argue against annotations, but it lead me back to another idea that has surfaced in discussions before: a source-directive feature. This sounds like a much smaller feature, which would be much simpler to define and agree on, and much simpler to implement. A source-directive would empower the community to define and implement the syntax, and not only for annotations, but for other features, such as aspect-oriented programming, which I believe was once proposed as an RFC (?) and declined, probably for the same reason... it's a feature with too many variations and opinions, lots of complexity, and it's probably another one of those language-features where the discussions end up revolving around run-time issues more so than language/syntax. It would be nice if every developer in the world could all agree on everything. But we can't, we don't, and we're not going to - and that's not a bad thing, because it means PHP is open for innovators to find better ways to do certain things in userland :-) The big advantage to having something like implemented and maintained in userland, is that these features can thrive and grow if they turn out to be successful - or, if everyone decides in a year or two that annotations suck, they can stop using them and move on to something else. It also means that developers don't need to wait for a year or more for their sysadmin to deploy the next minor PHP update that fixes a bug or makes a minor addition to that feature. Perhaps it's time to think about "lower level" language features that facilitate implementing "borderline" language-features, and enable the community to write better, more reliable implementations of things like annotations and AOP, rather than writing it for them? And perhaps a source-directive isn't the solution in this case, or perhaps it's only part of the solution - but what I'm saying is, maybe instead of lumping on more features that do one thing, perhaps it's time to turn things around, view things in a different light, and try to think about things on a somewhat more "meta" level? What's are the smallest "building block" language features that would enable the community to build bigger features such as annotations in a better way? I love annotations. But I love my implementation of annotations, I probably won't like yours, and that's not necessarily something we should need to agree upon. Is it really the responsibility of the language to deliver high-level features that support patterns? Or should it deliver simpler features that support the implementation of those patterns? - Rasmus Schultz
Re: [PHP-DEV] [RFC] Reflection annotations reader
I'm going to address these question in the proposal I'm working on - once
it's all in writing, I will post for debate.
On Wed, Jan 9, 2013 at 2:57 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> - Should we support nested annotations?
>
> - How [Foo()] will be different from new Foo()? If they are not different,
> is there an alternative to not bloat lexical parsing?
>
> - How parameters would be injected? Is constructor the only way to inject
> parameters?
>
> - How would we handle optional parameters, like [Foo("bar", null, null,
> "woo")]?
>
> - Suppose you wanna fix the optional arguments by named parameters, like
> [Foo("bar", test="woo")]. Doesn't it diverge with PHP interests of not
> supporting parametrized arguments? Should we modify the former or the
> later? Personally I'm a fan of named parameters.
>
> - How would we deal with inheritance? Should a method, for example,
> inherit the same annotations from parent or not?
>
> - Suppose that you define annotations to fix the inheritance problem, how
> would it be?
>
> - How would we cast possible usages of an annotation to only class, method
> or property? Using annotations too?
>
> - How would it be the syntax to declare a new annotation?
>
> - Would it be possible to modify an annotation value using Reflection, for
> example?
>
> - How could it be handled on APC to minimize the performance impact?
>
Re: [PHP-DEV] [RFC] Reflection annotations reader
To summarize: A native implementation of PHP-DOC block parser for run-time purposes (annotation libraries) is already available in the Reflection API, and already goes as deep as it needs to - going beyond simply finding and extracting the docblocks would make little sense, as every annotation library has it's own individual syntax, behaviors and features. There may be a some libraries that could use a native implementation if it happens to fit their needs, but they most likely won't use it, because (A) they won't win anything by doing so, and (B) these libraries would become incompatible with anything other than bleeding-edge PHP. A native implementation of PHP-DOC parser for offline purposes (documentation generators) is already available in userland, does the job fine, and does not rely on the Reflection API (as someone mentioned) because loading every class in a large codebase is not feasible. If you provide a separate PHP-DOC parser, these projects most likely won't use it, because (A) see above and (B) see above. Who else would need to parse PHP-DOC blocks and why? Bottom line, who is this feature for, what will they do with it, and most importantly, why would they use it? On Tue, Jan 8, 2013 at 3:55 AM, Stas Malyshev wrote: > Hi! > > > First of all, there are already plenty of established userland > > implementations - so there is really no need for this. > > On the contrary, plenty of implementations means there's a need in this > functionality, and it might be a good idea to have one standard > implementation if it can cover like 80% of use cases. > > > > > Whatever you decide on in terms of syntax, most likely won't satisfy > every > > the needs of every userland annotation library, so at least some of them > > most likely won't use it. You'd be creating more work for the maintainers > > of these frameworks, and they don't standard to gain anything from that > > work. > > Since when "it does not satisfy all needs of all users, and some of them > may end up not using it" is an argument for not including functionality? > And how it's more work for maintainers if they just won't use it? > > > On the other hand, I would be interested in having support for actual > > annotation syntax (not docblocks) added to PHP. Real annotation syntax > > Can we please not hijack the topic? We discussed annotations many times > already, if you have better proposal than current RFCs please create > your own RFC (or ask one of the current RFC authors for collaboration) > and start a new topic > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
Re: [PHP-DEV] [RFC] Reflection annotations reader
I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?
e.g. thinking of concrete possible basic syntax, neither of the following
delimiters would work:
[Foo('bar')]
{Foo('bar')}
And presumably none of the following would work either:
~Foo('bar')
@Foo('bar')
^Foo('bar')
*Foo('bar')
&Foo('bar')
:Foo('bar')
Can you think of anything that would work?
On Tue, Jan 8, 2013 at 3:57 AM, Vladislav Veselinov
wrote:
> Assume that you have this class with your proposed syntax:
>
> [SomeAnnotation('somevalue')]
> class Test {
>
> }
>
> This conflicts with the short array syntax. It looks like an array
> containing the result of the function 'SomeAnnotation' invoked with
> the parameter 'somevalue'.
> The only difference is the missing ";" but relying on this to
> determine whether this is an annotation or not would be insane.
> I'd support such a decision but with other syntax.
>
> I like Guilherme's RFC. I just don't think that the syntax is very PHPish.
>
>
Re: [PHP-DEV] [RFC] Reflection annotations reader
On parsing annotations in docblocks: please don't.
First of all, there are already plenty of established userland
implementations - so there is really no need for this.
Whatever you decide on in terms of syntax, most likely won't satisfy every
the needs of every userland annotation library, so at least some of them
most likely won't use it. You'd be creating more work for the maintainers
of these frameworks, and they don't standard to gain anything from that
work.
In terms of performance, there is nothing significant to gain here - any
good annotation engine/framework already caches parsed annotations.
On the other hand, I would be interested in having support for actual
annotation syntax (not docblocks) added to PHP. Real annotation syntax
could have benefits over parsing docblocks, starting with the fact that
most of what's currently in docblocks is documentation, and thus not very
interesting at run-time for anything other than documentation generators.
(again, documentation generators already have working parsers, and don't
stand to gain anything significant from switching to a native docblock
parser.) - also mind the fact that docblocks are a loose standard with many
more variations since annotation libraries came around.
The only real downside (in terms of run-time) to adding custom syntax, is
that existing useful annotations (such as @var for property-types) would
not be useful - but in another sense, that's a good thing, because (for the
most part) in existing codebases, these were written as documentation, not
intended for run-time consumption. IDEs and documentation tools can add
support for new annotation syntax, and treat these consistently and code,
which itself can be documented using phpdoc blocks.
I would support and encourage a C# style syntax and behavior, e.g.:
use my\lib\DataType;
[DataType('datetime')]
public $published_date;
In other words, DataType is a class, implementing an interface for
initialization - everything between the parentheses is interpreted
basically the same way as in an array() statement, and is passed to the
annotation instance after construction via an initialization method defined
by the interface.
I could elaborate tons more on this subject, as it's something I have spent
a lot of time researching in different languages, prior to writing my own
annotation library.
It may strike you as odd that someone who implemented an annotation library
based on docblocks is actually against annotations in docblocks - I mainly
chose that option because it was the best option at the time. I'm not a C
programmer, and I do believe that docblocks are the best approach for a
native PHP implementation. For a native implementation, I'd prefer to see a
clear separation between non-functional documentation metadata and
functional annotation objects. While there is some overlap between the two,
much of what is currently written as documentation (for example @var
annotations) could be written as functional annotations when these have a
meaningful purpose. After all, existing code with phpdoc-annotations most
likely was not written with the intent of consuming that metadata at
runtime, unless written for use with an annotation library.
I would be happy to involve myself deeper in this, if others agree and
would like to work on a new RFC.
- Rasmus Schultz
[PHP-DEV] Re: internals Digest 2 Dec 2012 00:53:48 -0000 Issue 2845
Isn't this need basically covered by accessors?
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
- Rasmus
On Sat, Dec 1, 2012 at 7:53 PM, wrote:
> From: Sebastian Krebs
> To: PHP internals list
> Cc:
> Date: Sat, 1 Dec 2012 13:34:58 +0100
> Subject: Abstract properties
> Hi,
>
> Don't want to start a big discussion, but is there a concrete reason, why
> abstract properties (or "a kind of abstract") are not supported? I've
> learned, that "an interface [the concept, not the implementations within a
> language] is the sum of all accessible (--> public) methods and
> properties", what as far as I understand means, that properties could (and
> should) be defineable in concrete interfaces too
>
> interface Queue {
> public function enqueue($value);
> public function dequeue();
> public $top;
> }
> // or
> abstract class Queue {
> abstract public function enqueue($value);
> abstract public function dequeue();
> abstract public $top;
> }
>
> Of course in the second example the "abstract" is kind of useless, but it's
> for illustration. I've seen some cases (for example the example above),
> where it would be useful to define properties in interfaces, but instead I
> was forced to (in my eyes) misuse [1] methods. Right now I cannot safely
> write somethig like
>
> /**
> * Must have a $top property
> */
> interface Queue {
> public function enqueue($value);
> public function dequeue();
> }
>
> function foo(Queue $q) {
> doSomethingWithTop($q->top);
> }
>
> Because I can never ensure, that $top exists. I always have to work with
> isset() here (or of course I use a getter, as mentioned earlier), what
> takes a little bit from the "usefulness" of interfaces ^^ The interface
> feels incomplete.
>
> Would like to hear some opinions, or maybe a summary of earlier discussions
> about this topic :)
>
> Regards,
> Sebastian
[PHP-DEV] Re: internals Digest 20 Oct 2012 09:49:39 -0000 Issue 2820
I second getting rid of write-onle - the only real case I can think of, is something like a password property on a user/account model-type, which gets encrypted and thus can't be read, and as Amaury pointed out, that should be a setPassword() method instead, perhaps even a separate UserPasswordService component. Certainly not an accessor. As for read-only, I strongly advice against overloading the const keyword with an entirely new meaning, if that's what you're suggesting? Just drop the idea of read-only altogether, please - it's so marginally useful in the first place, unconventional compared to other languages, and will just get in the way. For most properties that only have a read-accessor, it won't even make any sense for someone to try to extend that with a write-accessor. And as said, if you want to keep the internal value safe from write, just declare the actual property as private. -- Forwarded message -- From: Amaury Bouchard To: Clint Priest Cc: "internals@lists.php.net" Date: Sat, 20 Oct 2012 10:09:35 +0200 Subject: Re: [PHP-DEV] [RFC] Accessors v1.1 -> v1.2 Summary read-only / write-only keywords "no equivalent replacement has been suggested" => ouch read-only => const write-only => shouldn't exists. A write-only accessor is just a method disguised in property. It's not a good idea to allow: $obj->prop = 3; when the meaning is: $obj->meth(3);
[PHP-DEV] static analysis and early warning systems
Since there's a heavy debate on the list about strong typing right now, I just want to briefly share my point of view. PHP is not and won't be a strongly typed language. What it can be (and is on the way to be, with Clint's work) is a language that supports type-checking. Not the same as strongly typed. There's a time for unchecked properties and arguments, and there's a time for type-checking - you can argue against type hints and type-checks until you're blue in the face, but they exists for a reason: static analysis, which means better tooling and faster (and more well-documented) codebases in larger projects. And early warning systems - making sure that code fails at the point of failure, rather than bad arguments (or worse, property-values) slipping through the cracks, costing you many hours of painstaking debugging. Code that doesn't fail in the place where it's actually broken, is harder to debug than anything else. Type hints are optional, so PHP can still be a beginner-friendly language. To classify PHP as a "beginner-language" seems unfair to experienced professionals, who brought projects like Symfony and Zend Framework to life. The recent injection of new talent and renewed interest in the past 1-2 years has happened because those people stuck with PHP rather than "moving on" to other languages - let's face it, nobody wants to be stuck in "beginner mode", and if PHP was really strictly a "beginner language", it would be largely a waste of time. To me, it is much more than that - it is a language where you can dip your toes and test the water safely, but you can go really, really deep if you want to. The modern tools, libraries and frameworks available today are a testament to that fact - if the people behind these projects had simply "moved on", where would PHP be today? Growing the language is key to maintaining the interest of smart people who are willing to invest their time in building great software with PHP and sharing it with the community. A language is only worth as much as the community is willing to invest! Don't be afraid of scaring off beginners with advanced features - because PHP is such a loose language, those people can still get on board and start learning, without having to go the whole way on day 1. Beginners are unlikely to start picking apart Symfony or Zend Framework anyhow - but they are likely to start trying them out eventually. Most people do not get into PHP development intending to learn only the basics - they usually have a more long-term plan. Those who get in, intending to learn only a little, are usually designers and front-end people, who will never touch more than a view/template script anyhow, and thus will never even encounter classes, closures, or any of the other "advanced" stuff. Just my two cents.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Just a couple of quick remarks. Clint wrote: > I'm not even sure that automatic backing fields are even desired, I never felt the need to have them in C# and the only reason they were included is because they were a part of Dennis's original proposal. Automatic backing fields are indeed necessary in C# for various technical reasons none of which have any bearing on the PHP language - Nikita explained this in another e-mail. So I vote for dropping automatic auto-implemented accessors. In PHP, an auto-implemented accessor really would be almost identical to a regular property anyhow. I would also add that the double-underscore convention for the field-name seems somewhat spooky to me - double-underscore is generally reserved for PHP internal stuff... now suddenly these would be userland-fields. Seems wrong. Clint, I am sorry these issue were not surfaced earlier... I do seem to recall sending a very long e-mail highlighting many of these issues a long while back though (?) ... I only watch the list with half an eye, but I usually speak up when I feel strongly about something. You're doing a great job here! I hope you you will see it through - this would be a fantastic feature which will make for better code architecture in so many ways.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
> There's no way to stop the developer from doing that without read-only.
Yes, there is - I don't even know why would write it that way - doesn't
seem to make much sense.
What you probably should be doing, is this:
class A {
private $seconds = 3600;
public $hours {
get() { return $this->seconds / 3600 };
}
}
Keep your field private - now try extending this with a write-accessor.
I think that read-only is really almost merely a "pseudonym" for "read-only
accessor for a private field" - what you're really trying to do, is protect
the field behind the accessor, not the accessor itself.
In the same way, write-only is practically synonymous with "write-only
accessor for a private field" - to some extend (at least) the point of
having accessors to begin with, is to protect the underlying value(s) from
unauthorized or incorrect use.
You can relax your read-only or write-only accessors by declaring the
backing field(s) protected - this would be the equivalent of declaring a
read-only accessor that you are permitted to extend with a write-accessor
if you need to...
-- Forwarded message --
From: Jazzer Dane
To: Leigh
Cc: Clint Priest , "internals@lists.php.net" <
internals@lists.php.net>
Date: Tue, 9 Oct 2012 19:33:20 -0700
Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1
> class A {
> > public $seconds = 3600;
> >
> > public $hours {
> > get() { return $this->seconds / 3600 };
> > }
> > }
> >
> > class B extends A {
> > public $hours { // Maintains 'get' from class A
> > set($value) { $this->seconds = $value; }
> > }
> > }
> >
> ^There's no way to stop the developer from doing that without read-only.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
This looks great, and essentially has everything I had hoped for! My only remaining comment is on the read-only and write-only keywords... this seems really superfluous and strange to me - the syntax (using a hyphenated keyword) and the feature itself, is way off the grid as compared to other languages. In my opinion, this is a feature that is so exotic, it's likely to never actually be used by anyone. What I dislike the most about this feature, is that it's existence may mandate a "best practice" of declaring read-only properties as read-only. What I mean is, because this feature exists, anytime you're declaring something that is read-only by nature (because a write-accessor makes no logical sense), you would be expected to declare such a property as read-only. In other words, not using the read-only keyword for a property that only has a read-accessor, can only be interpreted in two ways: 1. it's an oversight, or simply bad practice. 2. it's an implied invitation to implement the write-accessor in an extension. Case 1 of course shouldn't happen, while case 2 would be an extremely exotic and far-fetched scenario. I understand the justification for this keyword - but the use-cases are just too rare, and they don't, in my opinion, outweigh the disadvantages. This feature just feel clumsy and out of place to me. I will never use it, and I would strongly prefer not to have to think about it, having to declare read-only and write-only deliberately. For 95% of cases, it's going to be perfectly obvious, both to me and other consumers of the code, why or whether something is read-only or write-only, and the extra guarantee or insulation against error in the marginal 5% of cases do not justify the effort of having to declare it explicitly everywhere. Just my two cents... Subject: [PHP-DEV] [RFC] Propety Accessors v1.1 It's been a while since I posted any updates about this, a few individuals have been asking about it privately and wanting me to get it out the door for PHP 5.5 release. It's come a long way since the last time I posted about it. RFC Document: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Re: [PHP-DEV] Re: Arrays which have properties of sets
looks like you're right - spl_object_hash() does in deed work... I guess I was mislead by some of the notes people made in the documentation... perhaps these should be moderated, and the documentation should be update to clear up some of the mystery and confusion that seems to surround this function? http://us3.php.net/manual/en/function.spl-object-hash.php#110242 "Changing the state of an object does not affect the result" - well of course not, since spl_object_hash() does not in fact seem to hash the "object", or at least not it's state. http://us3.php.net/manual/en/function.spl-object-hash.php#95666 "The unique identifiers of destroyed objects can and will be reused" - this could be demonstrated more clearly by using unset() ... though I understand it now, this example made me think at first that keys would just be reused at random... http://us3.php.net/manual/en/function.spl-object-hash.php#94647 "It seems that when switching scopes, the last one is repeated" - that's not at all what's happening in this extremely misleading example... rather, spl_object_hash(new stdClass()) creates an object that immediately falls out of scope and gets destroyed, at which point the same key may be reused in a different scope OR even in the same. http://us3.php.net/manual/en/function.spl-object-hash.php#94060 this seems to demonstrate an alternative approach, but as pointed out by Sherif, this is not the same thing at all. http://us3.php.net/manual/en/function.spl-object-hash.php#91164 "The spl hash will always be the same for a given object, regardless of content" - this is definitely not the case. http://us3.php.net/manual/en/function.spl-object-hash.php#90296 http://us3.php.net/manual/en/function.spl-object-hash.php#87422 Both attempt to implement spl_object_hash() in older versions of PHP, but both are extremely misleading since they have essentially nothing in common with spl_object_hash() as such. http://us3.php.net/manual/en/function.spl-object-hash.php#76220 This actually clarifies something things that probably should be explained in the documentation. It's perhaps the worst case of misleading user comments to date... ;-) On Sun, Oct 7, 2012 at 7:51 PM, Sherif Ramadan wrote: > On Sun, Oct 7, 2012 at 7:12 PM, Rasmus Schultz wrote: >> the manual states, "The implementation in SplObjectStorage returns the >> same value as spl_object_hash()" - so I don't know how this would >> really work any better than a custom implementation. >> >> perhaps safer would be to simply implement a collection-type that >> requires the classes of elements in the collection to implement an >> interface, exposing a unique key... and for objects that don't have a >> unique key, generate sequential keys from a static counter in each >> class... not ideal if you want to implement a document store that can >> store "anything", since now every stored object/class needs to provide >> a key... >> > > How is that safer? If anything this introduces every aspect of being > unsafe since relies on a user implementation that may or may not exist > and may or may not be unique. As opposed to spl_object_hash, which can > actually identify objects uniquely by looking at the internal symbol > table that exposes all the objects in memory. > >> On Sun, Oct 7, 2012 at 4:06 PM, Jared Williams >> wrote: >>> >>> See SPL's SplObjectStorage. That allows object instances as keys. >>> >>> Jared >> >> -- >> 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: Arrays which have properties of sets
the manual states, "The implementation in SplObjectStorage returns the same value as spl_object_hash()" - so I don't know how this would really work any better than a custom implementation. perhaps safer would be to simply implement a collection-type that requires the classes of elements in the collection to implement an interface, exposing a unique key... and for objects that don't have a unique key, generate sequential keys from a static counter in each class... not ideal if you want to implement a document store that can store "anything", since now every stored object/class needs to provide a key... On Sun, Oct 7, 2012 at 4:06 PM, Jared Williams wrote: > > See SPL's SplObjectStorage. That allows object instances as keys. > > Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Arrays which have properties of sets
Yeah, on that note - I've never understood what use this function is, as it reuses object IDs... it will return the same hash for two different objects during the same script execution - so it's unusable as far as getting unique keys for objects... and I don't know what else you could really use it for? On Sun, Oct 7, 2012 at 5:01 AM, Pierre Joye wrote: > > Object hash may be what you are looking for. > > http://php.net/manual/en/function.spl-object-hash.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Arrays which have properties of sets
Since I was the one who started this discussion, I'd like to reply to
some of these points.
First off, let me say - as you pointed out, when the values are
unique, they are best represented
as keys... however, this of course applies only to value-types, which
isn't the problem, and not
why I started this conversation in the first place. Objects don't work
as keys. And objects do
not always have a value that you can use as keys.
I believe I understand the nature of arrays quite well - the
situations you covered in this e-mail
simply do not address the issues I was trying to tackle. I too have
used the key/value duplication
strategy you mentioned:
array("val1" => "val1", "val2" => "val2");
I stopped doing that many years ago - what's the benefit of storing
everything twice? At some
point I started doing this instead:
array("val1" => true, "val2" => true);
You're storing the same amount of information, but now there's no
confusion as far as which is
the key and which is the value - and for longer keys, you don't need
twice the memory. And when
modifying the array, you don't have to maintain both the key and the value.
Effectively this *is* a set, and as such works fine - but works only
for scalar values, not for objects.
> function create_set($arr) {
> return array_combine($arr, $arr);
> }
> $set = create_set(array("val1","val2"));
This seems very misleading to me, as what comes out of create_set() is
not a set, but
just another array - which happens to contain a set. I get what you're
trying to do here,
but... it just doesn't work.
I don't think there's any "work-around" for not having sets, and I'm
not sure if that's what
you're suggesting either, but - there's no way you can educate anyone
out of that issue
if or when someone needs a set of objects that (per definition) do not
have unique keys.
You can implement a set of course, as a class - using array_search()
internally in the
class, you can check if a given value (or object) is present in the
set. I've done this on
one occasion, and it actually performs acceptably for a small (~1000)
set of objects, so
it's not that this problem represents a roadblock by any means. But it
is a solution with
obvious performance deficiencies and trade-offs...
> From: Adam Jon Richardson
> To: internals@lists.php.net
> Cc:
> Date: Thu, 4 Oct 2012 12:48:53 -0400
> Subject: Arrays which have properties of sets
> A while back, there was a thread discussing adding a specific function
> for removing elements from an array by value. Rasmus L. noted that
> when the values are unique, they would be better represented as keys:
> > The problem is that it is a rather unusual thing to do. I don't mean
> > removing an element, that is very common, but you are implying that you
> > know you don't have duplicates and you want a fast way to remove an
> > element by value in that case. To me that means you built your array
> > badly. If the values are unique then they should be the keys, or at
> > least a representation of the value should be the key such that you
> > don't need to scan the entire hash for the element when you need to
> > access it. And removal is just like any other access.
> When I come across situations where an array's properties match those
> of a set, I create array "sets" by duplicating keys and values:
> array("val1" => "val1", "val2" => "val2");
> This approach has several benefits:
> - Form the union of values using the "+" operator (which forms unions
> through use of keys)
> - Fast, easy removal of values through unset (e.g., unset($elements["val1"]))
> - Standard handling of values in for loops:
> for ($elements as $element) {
> echo $element;
> }
> Writing a userland function to create array sets from
> numerically-indexed arrays (avoiding the duplication of typing the key
> and value) is indeed trivial:
> function create_set($arr) {
> return array_combine($arr, $arr);
> }
> $set = create_set(array("val1","val2"));
> However, I find that the use of array sets is very common and helpful
> to me, and I see many situations where a developer would have been
> better served by leveraging the key to store the value. I suspect many
> PHP users don't understand the nature of PHP arrays. I'm wondering if
> adding a function (or language construct) for creating array sets
> would prove helpful (just because of the vast amount of code which
> could make use of it) and facilitate the education of developers so
> they might better leverage the benefits of the underlying hash map
> structure when their array is essentially a set and they wish to
> perform operations such as removing an item by value.
> Ada
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructor hook
Good point - I agree. Thanks for taking the time to think about this! On Tue, Sep 18, 2012 at 12:22 PM, jpauli wrote: > On Tue, Sep 18, 2012 at 5:14 PM, Amaury Bouchard > wrote: > > Sounds to me like aspect-oriented programming, applied to object > construction. > > Take a look at: https://github.com/AOP-PHP/AOP > > +1, this is the same case as AOP, but for constructor. > Thus AOP may fit the need. > > Julien.P >
[PHP-DEV] constructor hook
Hey,
I'm going to make this brief, because I suspect a lot of people are going
to jump at the opportunity to cry bloody murder when I suggest this.
I wonder if it would make sense to have a way to globally hook into
__construct() - sort of like how you can hook into the autoloaders with
spl_autoload_register() ...
This could be useful for things like dependency injection and debugging.
Lithium (for one) uses a unified constructor to accomplish something like
this:
http://lithify.me/docs/manual/lithium-basics/architecture.wiki
That's bad for various reasons I won't delve into.
Various DI containers use a replacement for the "new" keyword, e.g.
DI::create('MyClass') which is bad (worse) for other reasons...
So basically, what if you could solve these design patterns by hooking into
constructors directly instead - something like:
constructor_hook_register(function($object) {
> echo 'an object of type '.get_class($object).' was constructed!';
> });
> $test = new Foo();
would print:
an object of type Foo was constructed!
One other area where this could help, is in event-driven systems, where
this sort of thing could be used for "co-construction".
Of course, you could accomplish the same thing in a more controlled
fashion, by simply establishing conventions - for example, DI::inject(new
My Class()) would work just as well, it's just inconvenient to type; on the
other hand, it's explicit about what's happening.
So I'm not at all demanding this feature - I'm merely posting this for
debate.
Thanks,
Rasmus Schultz
[PHP-DEV] progressive buffer allocation
Interesting technique: http://ayende.com/blog/158721/rule-out-the-stupid-stuff-first-select-still-ainrsquo-t-broken I wonder if this is applicable to PHP in any way? Would stream buffers benefit from something like this? Perhaps not, I just thought it was interesting enough to share - it's not a technique I was familiar with... :-)
Re: [PHP-DEV] is GD being actively maintained?
Good point - the bug could actually be in the rendering, rather than in the bounding box calculation. We could determine which is the case, by running the exact same script with the exact same font, on a system where the bug is present, and on another system where it's not. Then overlay the resulting images in photoshop: - if the type aligns, and the red lines do not, the bug is in the bounding box computation. - if the type does not align, the bug is either in the type rendering, or in both (less likely) the rendering and bounding box computation. That should narrow it down some? On Fri, Sep 7, 2012 at 1:12 AM, Pierre Joye wrote: > On Fri, Sep 7, 2012 at 3:09 AM, Rasmus Schultz wrote: > > Jannik, > > > > Thank you - this confirms I'm not crazy, or at least it's evidence to > > support that theory ;-) > > > > It may be OS specific - perhaps the Windows and OSX binaries are built > > against a different build (or configuration) of FreeType? > > It can depend on three things: > > - bug in gd (bbox or offset calculation) > - freetype version > - freetype options (some options, not always enabled, strongly affects > rendering) > > cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >
Re: [PHP-DEV] is GD being actively maintained?
Jannik, Thank you - this confirms I'm not crazy, or at least it's evidence to support that theory ;-) It may be OS specific - perhaps the Windows and OSX binaries are built against a different build (or configuration) of FreeType? Or it could be specific to 32 or 64 bit builds. I have never built PHP (or any other C project since 15 years ago in school) so I really have no way to take this any further... Thanks! On Thu, Sep 6, 2012 at 9:15 AM, Jannik Zschiesche wrote: > > Hi Alexey, > > I just tested it on PHP 5.4.4 on OSX and I can confirm, that the issue is > still present. > (used font: Open Sans Regular/Bold/Italic, screenshots: > http://min.us/mM2c5yyBU ) > > > Cheers > Jannik Zschiesche >
[PHP-DEV] is GD being actively maintained?
I opened this bug report 2 years ago: https://bugs.php.net/bug.php?id=52756 Is GD still actively maintained? If it isn't, then perhaps it's time to start thinking about switching to a graphics library that is maintained? Perhaps something more modern with real drawing capabilities and a better typographic engine? Just wondering...
Re: [PHP-DEV] Support negative indexes for arrays and strings
Yes, typo! sorry. $array = array(1001, 1002, 1003, 1004); $number = $array[-1]; // => 1004 $array[-1] = 1005; $number = $array[-1]; // => Looking at the resulting code, I would like to point out also that it's extremely misleading... because $array[-1] references two completely different elements depending on whether you're reading or writing the value... unless $array[-1] = 1005 would actually overwrite the last element in the array - in which case it gets even more dangerous, as well as breaking backwards compatibility... On Fri, Aug 31, 2012 at 9:24 AM, Ferenc Kovacs wrote: > > > On Fri, Aug 31, 2012 at 3:14 PM, Rasmus Schultz wrote: >> >> Having thought about this for a while, I think this is a bad idea - here's >> why: >> >> $array = array(1001, 1002, 1003, 1004); >> >> $number = $array[-1]; // => 1004 >> >> $number[-1] = 1005; >> >> $number = $array[-1]; // => >> >> Obviously, the last statement must return 1005, since otherwise that >> value would be inaccessible. >> > > maybe you wanted to write > $array[-1] = 1005; > instead of > $number[-1] = 1005; > ? > > otherwise I can't see the problem that you are mentioning. > could you clarify? > > -- > 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] Support negative indexes for arrays and strings
Having thought about this for a while, I think this is a bad idea - here's why:
$array = array(1001, 1002, 1003, 1004);
$number = $array[-1]; // => 1004
$number[-1] = 1005;
$number = $array[-1]; // =>
Obviously, the last statement must return 1005, since otherwise that
value would be inaccessible.
On the other hand, to know whether you have to know whether your array
is currently a hash or not - since array index now works completely
differently depending on whether your array is currently a hash or an
array.
This is not something you can currently even test for - and not
something you should really need to know or care about in the first
place. Having to know this information in certain cases would defeat
the purpose of having a single collection-type in the first place: it
really *should* work the same, all the time.
Just my $0.02...
--
From: Marc Easen
To: "internals@lists.php.net" , Lars Strojny
Cc:
Date: Sun, 17 Jun 2012 20:53:38 +0100
Subject: Re: [PHP-DEV] Support negative indexes for arrays and strings
Hi Lars,
I don't think there needs to be a new operator, as it is possible to
achieve this behaviour without adding a new language construct. The
odd thing with PHP as I'm sure you are aware of is that arrays can be
either a lists or a dictionary. This is where this becomes quite
difficult to implement:
Numerical keyed array:
$a = array('foo', 'bar', 'baz');
$a[0] === 'foo'
I would expect:
$a[-1] === 'baz';
An string keyed array:
$b = array('foo' => 1, 'bar' => 2, 'baz' => 3);
$b[0] === 1;
Would generate an E_NOTICE: PHP Notice: Undefined offset: 0 in php
shell code on line 1.
An negative offset would also generate the same E_NOTICE.
So going back to your point, the change would only be to numeric based
arrays (list) and strings. It could be possible to string keyed arrays
to be accessed by the numeric counter parts, but I'm not familiar to
comment on if this is even possible.
It seems this topic has generated a lot of interest, I feel the best
way to proceed would be to write a RFC. I've never written one before
so could someone give me access to create a page on the RFC site or
create a RFC for me and give me permission to update it, my username
is 'easen'.
Thanks,
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aspect Oriented Programming in PHP
But AOP is just one of many popular techniques that require code generation. And for that matter, there is an endless number of different approaches and features found in different AOP solutions for various languages - it's not a "one size fits all" idea, many people are going to have preferences about the details, and hence not a good candidate for a language feature, in my opinion. I would much prefer to see the language enhanced on a lower level - to enable solid, reliable, efficient implementations of code generation in userland, paving the way for good AOP frameworks, as well as many other techniques and ideas, now and in the future. Thanks to bytecode caching, and various other advances in efficiency in the past few years, PHP in general is (or could be) a brilliant language for code-generation tasks. For instance, check out this elegant parser library: http://qntm.org/loco For something like an aspect-oriented language extension and pre-processor, you could get a head start on parsing enhanced PHP syntax really quickly. Also, consider how much simpler it would be to implement things like template engines... On Sun, Aug 26, 2012 at 2:34 PM, Peter Nguyen wrote: > That's why I thnk the extension is superior to all other solutions, > because it doesn't require code generation in userland. Also, it will be > possible to backtrace to the declaration of the aspects. > > > 2012/8/26 Rasmus Schultz > >> > >> > On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote: >> > I know very little about AOP and don't pretend to know a lot, but how >> > would we benefit >> > from directly adding it into core instead of taking the approach FLOW3 >> did? >> >> >> as I see it, the problem with AOP in PHP is the same as with any other >> technique that requires code-generation, in some form or another, >> including code-manipulation, pre-processing, transpilers, and so >> forth: traceability of errors. >> >> languages that are popular as intermediary languages generally support a >> directive that makes it possible to trace errors back to their source. >> >> I raised this issue on the list recently, and no one seemed to react with >> any interest... >> > >
Re: [PHP-DEV] Aspect Oriented Programming in PHP
> > On Thu, Aug 23, 2012 at 7:36 AM, Peter Nguyen wrote: > I know very little about AOP and don't pretend to know a lot, but how > would we benefit > from directly adding it into core instead of taking the approach FLOW3 did? as I see it, the problem with AOP in PHP is the same as with any other technique that requires code-generation, in some form or another, including code-manipulation, pre-processing, transpilers, and so forth: traceability of errors. languages that are popular as intermediary languages generally support a directive that makes it possible to trace errors back to their source. I raised this issue on the list recently, and no one seemed to react with any interest...
Re: [PHP-DEV] re: removing an item from an array
Thank you, but this isn't really anything like what I had in mind.
What I had in mind is more like set-semantics for arrays, e.g. designed to
work with sets of distinct values/objects.
Since I do not have permission to write on the wiki, I posted an initial
draft here:
https://gist.github.com/321ad9b4b8c4e1713488
On Mon, Aug 20, 2012 at 10:10 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/8/21 Rasmus Schultz :
> > I have a login (mindplay) but I do not have permission to post or edit
> > anything on the wiki...
>
> I've created RFC for this
>
> https://wiki.php.net/rfc/array_delete
>
> Get wiki account and finish discussion.
> I may write patch for this with my spare time, but
> it may take while to find time. I suggest write patch
> and send pull request.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> >
> > On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
> >
> >> Please let this die until someone is serious enough to come up with an
> >> rfc. This has been nothing but counterproductive arguing. If someone
> feels
> >> strongly about it, write an rfc then we can discuss?
> >> On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
> >>
> >>> Hi,
> >>>
> >>> 2012/8/21 Herman Radtke :
> >>> >>> May be we should have something like
> >>> >>
> >>> >> >>
> >>> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300)
> >>> return
> >>> >> >> true; })
> >>> >> >
> >>> >> > So array_filter?
> >>> >>
> >>> >> I'll use it or like for deleting, but the point of this thread is
> >>> >> "intuitive function for deleting element(s)"
> >>> >>
> >>> >> array_delete($array, $value|callable)
> >>> >>
> >>> >> would be nicer for users, perhaps.
> >>> >
> >>> >
> >>> > You are basically asking to alias array_filter with "array_delete".
> >>> That is
> >>> > a very slippery slope. I think array_filter is very a very obvious
> >>> choice to
> >>> > remove something from an array. The "filter" function/method is
> common
> >>> in
> >>> > functional languages (and functional frameworks like Underscore).
> >>> >
> >>> > These are things developers just need to learn as part of
> development.
> >>> > Really, this is entire thread should be on stack overflow, not
> >>> internals.
> >>>
> >>> I guess you haven't read later post.
> >>>
> >>> You've also made a novice mistake.
> >>> array_filter() DO NOT delete elements, but creates new array.
> >>> array_delete() is another form of array_walk(), not array_filter().
> >>> See my posts.
> >>>
> >>> Having a API for dedicated task is good thing.
> >>> Who would argue array_pop()/array_push() isn't needed?
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Yasuo Ohgaki
> >>> yohg...@ohgaki.net
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>
> >>>
>
Re: [PHP-DEV] re: removing an item from an array
I have a login (mindplay) but I do not have permission to post or edit
anything on the wiki...
On Mon, Aug 20, 2012 at 8:01 PM, Will Fitch wrote:
> Please let this die until someone is serious enough to come up with an
> rfc. This has been nothing but counterproductive arguing. If someone feels
> strongly about it, write an rfc then we can discuss?
> On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote:
>
>> Hi,
>>
>> 2012/8/21 Herman Radtke :
>> >>> May be we should have something like
>> >>
>> >> >>
>> >> >> array_delete_if($array, function($v, $k=null) { if ($v == 300)
>> return
>> >> >> true; })
>> >> >
>> >> > So array_filter?
>> >>
>> >> I'll use it or like for deleting, but the point of this thread is
>> >> "intuitive function for deleting element(s)"
>> >>
>> >> array_delete($array, $value|callable)
>> >>
>> >> would be nicer for users, perhaps.
>> >
>> >
>> > You are basically asking to alias array_filter with "array_delete".
>> That is
>> > a very slippery slope. I think array_filter is very a very obvious
>> choice to
>> > remove something from an array. The "filter" function/method is common
>> in
>> > functional languages (and functional frameworks like Underscore).
>> >
>> > These are things developers just need to learn as part of development.
>> > Really, this is entire thread should be on stack overflow, not
>> internals.
>>
>> I guess you haven't read later post.
>>
>> You've also made a novice mistake.
>> array_filter() DO NOT delete elements, but creates new array.
>> array_delete() is another form of array_walk(), not array_filter().
>> See my posts.
>>
>> Having a API for dedicated task is good thing.
>> Who would argue array_pop()/array_push() isn't needed?
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
Re: [PHP-DEV] re: removing an item from an array
Absolutely, you're right. I have a tendency to get dragged into those. I apologize. On Fri, Aug 17, 2012 at 5:50 PM, Nikita Popov wrote: > > Could we please stop these pseudo-arguments?
Re: [PHP-DEV] removing an item from an array
I think adding more collection-types is the intuitive reaction to this issue, but there's something to be said for the idea of having only a single collection-type - I think that's one PHP feature we should not give up. Not having to pick and choose (and compromise) to select the "right" collection-type, and not having to refactor when you realize you needed another collection-type - as well as easy comprehension for developers... these are valuable aspects of having only a single collection-type. Some newer languages like Opa embrace that idea with great elegance. Giving up on that idea should be the last option, in my opinion. There are plenty of cases for collections of objects that do not have a scalar key, where the key is indeterminate, or where the key can change - and thus cannot have known indexes. As an aside note, I recently benchmarked array_search() for a project that needs to store many different types of objects in a list - and searching a list with 1000 objects for one specific object is extremely fast: a couple of micro-seconds more (per search) when compared against a hash-based lookup with a known key, so (in my case) nothing to worry about at all in terms of performance. Arrays are a powerful and pure feature in PHP - I would vote against introducing more collection-types, and instead leverage the already powerful and well-understood existing singular collection-type. On Sat, Aug 18, 2012 at 2:42 AM, Alexey Zakhlestin wrote: > > On 16.08.2012, at 0:18, Rasmus Schultz wrote: > > > How come there is no straight-foward obvious way to simply remove a given > > value from an array? > > Well, this sounds like a reason for creating SplSet class > >
Re: [PHP-DEV] re: removing an item from an array
Most other languages have more than one collection-type... since PHP has
only the single, hybrid array-type which acts both as a hash and as an
array, something like this ought to be available.
I don't know why everyone is so eager to jump up and argue against
something this simple, basic and useful. The fact that this is missing is
an oversight - just look at the number of solutions people come up with.
For what?
I want to remove and object from a list. Not an exotic and crazy
requirement, is it? It just isn't the sort of thing that should require any
substantial thinking or typing.
And it doesn't help make codebases more legible when people come up with 25
different ways to do it.
On Fri, Aug 17, 2012 at 5:23 PM, Rasmus Lerdorf wrote:
> On 08/17/2012 05:21 PM, Rasmus Schultz wrote:
> >>
> >> if(($key = array_search($del_val, $messages)) !== false) {
> >> unset($messages[$key]);
> >> }
> >>
> >> Nothing horrible here.
> >>
> >
> > I disagree - this is (or should be) a simple, atomic operation...
> > yet, you've got a function-call, an intermediary variable, a boolean
> test,
> > and an unset statement repeating the name of the array you're deleting
> from.
> >
> > This should be a simple statement or function/method-call, and in most
> > other languages it would be...
>
> Really? I can't think of a single language that has a call to remove an
> element by value in a key-value hash. Do you have some examples? What do
> you do with duplicates?
>
> -Rasmus
>
>
[PHP-DEV] re: removing an item from an array
>
> if(($key = array_search($del_val, $messages)) !== false) {
> unset($messages[$key]);
> }
>
> Nothing horrible here.
>
I disagree - this is (or should be) a simple, atomic operation...
yet, you've got a function-call, an intermediary variable, a boolean test,
and an unset statement repeating the name of the array you're deleting from.
This should be a simple statement or function/method-call, and in most
other languages it would be...
[PHP-DEV] removing an item from an array
How come there is no straight-foward obvious way to simply remove a given value from an array? Just look at the number of horrible ways people solve this obvious problem: http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key Shouldn't we have something simple, like: array_remove($array, $value) : array (returns a new array) and/or array_delete(&$array, $value) : bool (modifies array directly) ?
[PHP-DEV] missing documentation for use-clause in closures?
Is this all the documentation there is for the use-clause for anonymous closures? http://us2.php.net/manual/en/functions.anonymous.php For one, it would be nice to have documentation that explains whether the variables listed in the use-clause are copied/referenced at declaration-time or at call-time? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] notes on a couple of RFCs
Is this RFC outdated?
https://wiki.php.net/rfc/jsonable
We have JsonSerializable in 5.4 - this appears to be essentially the same thing?
(Should it be moved from "draft" to "implemented", or should it just
be removed? It was not implemented with the names used in this RFC.)
I was also looking at the following RFC:
https://wiki.php.net/rfc/linecontrol
I have often wondered about something similar - although I don't like
what's proposed here as far as syntax. We already have syntax for
directives - building on that, I would expect to see something like
this:
declare(file='source.tpl#3');
This would affect error-reporting of all lines following that line.
Using the directive block-syntax, this would affect error-reporting
only within the block:
declare(file='source.tpl#3') { ... }
I've been hungry for this feature for many years - it would pave the
way for huge improvements in template-engines, AOP frameworks,
pre-processors, code-generators, and meta-programming in general...
most php-developers shy away from most of these powerful patterns,
because there is currently no way to implement "proper"
error-reporting for any of these patterns...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ReflectionParameter::getClassName() missing
I was doing some work with the Reflection API, and I ran into something missing from ReflectionParameter. Turns out, there's no way to get the class-name of a parameter, short of calling getClass() - the problem with that is, there's no way to get the class-name of a parameter without causing the class itself to autoload. Okay, so I can work around that by __toString() and parsing that, but that seems rather hacky. Thoughts?
Re: [PHP-DEV] common issue with version_compare()
using this particular version-numbering scheme, 1.01 is equal to 1.1 - I don't think that's a bug, because the version-numbers in this version-numbering scheme are integers, not decimals. so I believe this is in fact as correct as it can be, since numbers like "01" should not really be used in this version-numbering scheme, as it's not an integer. changing it is probably not a good idea, since comparisons like "1.10" and "1.100" could potentially become really tricky - in the current version-numbering scheme, 100 is greater than 10, but if these were interpreted as decimals, they would be equal. looks like I opened up pandora's box with this one ;-) bottom line, I think, is that version_compare() should work for the version-numbering scheme used by PHP, so that it works for checking the PHP version-number. if you happen to use the same version-numbering scheme for your PHP projects, good for you - if you don't, too bad... there are just too many version-numbering schemes to support them all... On Sat, Jul 21, 2012 at 2:22 AM, Kris Craig wrote: > > > 1.01 eq 1.1 > > Could you explain this one to me? In every versioning system I've ever > used, 1.1 would be greater than 1.01, not equal. > > > On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev >wrote: > > > > > Hi! > > > > > > >> For example, I was not the only one who found it odd that "1.0" is > > > >> considered less than "1.0.0" - wouldn't it make sense to "pad" the > > > shortest > > > >> version-number with zeroes? e.g. "1.0" if compared against "1.0.0" > > > would be > > > >> padded with zeroes at the end, e.g. as "1.0.0". > > > > > > 1.0.0 and 1.0 are different things. If you want to make a comparison > > > that takes into account only two components, you can just cut them both > > > to two components, then compare. > > > -- > > > Stanislav Malyshev, Software Architect > > > SugarCRM: http://www.sugarcrm.com/ > > > (408)454-6900 ext. 227 > > > >
Re: [PHP-DEV] common issue with version_compare()
> 1.0.0 and 1.0 are different things. I think the problem is, version numbers are different things to different people - I guess the documentation maybe isn't clear enough on precisely what version numbering scheme it's using. To most people, "1" and "1.0" are the same thing, because they look like decimal-numbers to Americans. The documentation doesn't state how leading zeroes or missing numbers are treated in comparisons. I just submitted a comment with a small script that runs version_compare() on a list of version numbers - 1 lt 1.0 1.0 eq 1.00 1.00 lt 1.01 1.01 eq 1.1 1.1 lt 1.10 1.10 gt 1.10b 1.10b lt 1.10.0 I was a bit surprised at some of these, but they make sense now that I can see how the version-number interpretation works... On Fri, Jul 20, 2012 at 5:07 PM, Stas Malyshev wrote: > Hi! > > >> For example, I was not the only one who found it odd that "1.0" is > >> considered less than "1.0.0" - wouldn't it make sense to "pad" the > shortest > >> version-number with zeroes? e.g. "1.0" if compared against "1.0.0" > would be > >> padded with zeroes at the end, e.g. as "1.0.0". > > 1.0.0 and 1.0 are different things. If you want to make a comparison > that takes into account only two components, you can just cut them both > to two components, then compare. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 >
[PHP-DEV] common issue with version_compare()
>From the comments in the documentation, it seems others are having the same problem with version_compare() that I was running into: http://us2.php.net/version_compare Look at all those code-samples and "extensions" to the function - I found it very odd that the documentation does not explain how an "empty" version-number is interpreted compared to the strings and numbers, which are clearly defined and explained. For example, I was not the only one who found it odd that "1.0" is considered less than "1.0.0" - wouldn't it make sense to "pad" the shortest version-number with zeroes? e.g. "1.0" if compared against "1.0.0" would be padded with zeroes at the end, e.g. as "1.0.0". Of course that would break backwards compatibility, which kind of defeats the purpose of having a standardized version-number comparison standard. But as you can see, people aren't using the function as-is anyway - they're writing their own... - Rasmus Schultz
[PHP-DEV] Re: internals Digest 21 May 2012 21:48:46 -0000 Issue 2690
oh, wow! so this was already implemented in 5.4, and without introducing some kind of base-class to enable it. who knew... fantastic, thanks for the info! case closed :-) - Rasmus From: "Gustavo Lopes" To: internals@lists.php.net Cc: Date: Mon, 21 May 2012 21:13:52 +0200 Subject: Re: [PHP-DEV] memory usage ouchy On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz wrote: I just realized something that never occurred to me before - every property is actually stored as a hash. This test-script will demonstrate: [snip] The test-script contains no information about the version of PHP you're using. Starting with PHP 5.4, the properties hash table is only created if you're storing dynamic properties (i.e. assigning undeclared properties) or if it otherwise requested. Otherwise, they're stored in an array.
Re: [PHP-DEV] memory usage ouchy
Adding/removing properties at runtime is great if you want obscure, unmaintainable code and don't think an IDE is useful. So to make my previous statement more precise, dynamic properties are not widely used in respectable modern codebases, and is generally something a reputable developer would frown upon. Yes, some codebases (e.g. Drupal) rely on this extensively, but modern frameworks generally do not - in fact, they often take measures to ensure that exceptions are thrown if you try to access a property that has not been formally defined. For that matter, most ORMs (a typical example of where dynamic properties would come in handy) don't rely on dynamic properties either - they rely on __get() and __set() and store the actual values in a single property, as an array. So even for highly dynamic components in modern frameworks, this is not a feature that is often used. Drupal-development aside, and perhaps some XOOPS-development back in the dark ages, I can't actually recall when I've used dynamic properties. I suddenly realize why certain heavily-used classes in the Yii framework have obscure property-names like $_m and $_p ... they're trying to save memory. Not really logical that you should have to compromise legible code in favor of saving memory. Makes me wonder if this issue could be addressed, killing two birds with one stone. Since the dynamic aspect is an inconvenience to many developers, and since it causes memory-overhead whether they make use of this feature or not, how about introducing a non-dynamic alternative base-class that actually throws if you access properties that have not been defined? This wouldn't change the way PHP objects work by default, but would lighten the memory-overhead in a lot of modern frameworks, and possibly speed up property-access too, since you can have a flat look-up table for class-properties; and could eliminate the need for an "object" or "component" base-class in frameworks... On Mon, May 21, 2012 at 2:55 PM, Stas Malyshev wrote: > Hi! > >> How come it's necessary to store the property-names of every property >> in every object? For properties that have been defined in classes, why >> can't they be stored in a more efficient manner? (using lookup tables) > > No because you can add and remove properties freely at runtime. > >> I know the nature of PHP is dynamic, and I know that dynamic >> properties would have to be stored in a key/value form internally... >> but if you look at modern PHP software, dynamic properties is actually >> something very few people use. > > This is not true. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] memory usage ouchy
I just realized something that never occurred to me before - every
property is actually stored as a hash.
This test-script will demonstrate:
= 'a';
$foo-> = 'b';
$foo-> = 'c';
$foo-> = 'd';
$bytes += 4;
$test[] = $foo;
}
$after = memory_get_usage(true);
header('Content-type: text/plain');
echo ($after-$before).' bytes used; '.$bytes.' bytes of information stored.';
Output is this:
786432 bytes used; 4000 bytes of information stored.
I know this an extreme example, I just did it to see if what I
suspected was actually correct.
How come it's necessary to store the property-names of every property
in every object? For properties that have been defined in classes, why
can't they be stored in a more efficient manner? (using lookup tables)
I know the nature of PHP is dynamic, and I know that dynamic
properties would have to be stored in a key/value form internally...
but if you look at modern PHP software, dynamic properties is actually
something very few people use.
My suspicion is that all this memory-overhead has performance
implications as well? Allocating and deallocating memory for all of
these repeated property-names, it can't be very efficient?
I don't know much about the inner workings of PHP or C in general, but
if the property-names are in deed stored repeatedly, and if the
string-type uses a pointer, wouldn't it possible to point all of the
property-name strings to same address in memory, sharing the
property-name strings, instead of storing them repeatedly?
Just a thought...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 24 Apr 2012 22:20:08 -0000 Issue 2675
On Tue, Apr 24, 2012 at 10:10 PM, Anthony Ferrara wrote: > There's already an __isset() magic method that does exactly this: > http://us2.php.net/manual/en/language.oop5.overloading.php#object.isset I know. In my opinion, that was a mistake, and if I catch anyone on my team using that, I will have to slap them around some ;-) If you think consistency is paramount, I'm not going to argue with that, nor would I persist in arguing against this feature... >> I would suggest making the unset-method optional for properties, and >> the default behavior for unset($time->Hours) would be >> $time->Hours=null when no unset-method is implemented. > > Agree there. The only other sane way of handling that would be to > raise an error "trying to unset an accessor property"... Or it would > try to unset the true public variable by that name, and hence > unsetting nothing... Yeah, that was my first thought - but it doesn't seem very "php" to throw errors when you're trying to do something that can behave in a meaningful way without forcing you to write tedious boilerplate. >> The "readonly" keyword in my opinion is redundant - properties are >> naturally read-only (or write-only) if you implement only the get or >> set method, same as any other language. No need to break common >> language conventions here. > > Well, it's redundant for a single class. It's not redundant with > inheritance. Otherwise a child class could define a writer for that > property, which may be undesirable... Then again, what are the use > cases for an enforced read-only (or write only for that matter)...? In my opinion, that's the kind of thinking that made Java overly ceremonious. If I have a real reason to make something writable that wasn't writable in the base-class, why make that harder than it has to be? We're talking about a tiny fraction of cases where this is even a real concern in the first-place - things that are read-only tend to be read-only for a reason... for example, if you have a property that returns the number of users currently active on your website, or the current date/time, how or why would you make those writable? I think confusing things with yet another keyword is completely overkill for such a small amount of marginal cases. Let's not encourage artificial limitations on code extensibility, for things that < 1% of users are likely to abuse in a lifetime. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: internals Digest 24 Apr 2012 22:20:08 -0000 Issue 2675
I agree, overloading isset() for properties is somewhat creepy - as
that would mean you can no longer rely on isset() to actually work the
way it works for any other value. I understand that's actually the
intent, but I think this would be confusing - isset() is supposed to
behave a certain way depending on the value, and now suddenly it could
return completely arbitrary values unrelated to the value of a
property, breaking established semantics.
As for unset() on the other hand - I feel that this is almost a must,
since without it, properties can't fully replace the magic methods. To
complete the example from the RFC, it would look like this:
class TimePeriod
{
private $seconds;
public property hours
{
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; }
}
public function __unset($name)
{
if ($name == 'Hours') {
unset($this->seconds);
}
}
}
That's pretty awful.
For that matter, if __unset() was not implemented, what would happen
if you did unset($time->Hours) ? The behavior would be undefined -
worst case, nothing would happen at all, which could lead to fun
debugging sessions, when you think you're deleting properties and they
just stay unchanged.
I would suggest making the unset-method optional for properties, and
the default behavior for unset($time->Hours) would be
$time->Hours=null when no unset-method is implemented.
The "readonly" keyword in my opinion is redundant - properties are
naturally read-only (or write-only) if you implement only the get or
set method, same as any other language. No need to break common
language conventions here.
RFC looks good though, much better than initial proposals - I like it! :-)
- Rasmus
> From: Anthony Ferrara
> To: Clint M Priest
> Cc: "internals@lists.php.net"
> Date: Tue, 24 Apr 2012 08:56:55 -0400
> Subject: Re: [PHP-DEV] RFC: Property get/set syntax (added isset/unset and
> references)
> Clint,
>
> Very nice job overall! Looking quite good.
>
> > Alternatively we could throw an error to a call on isset and/or unset
> > against a property which didn't define an implementation.
>
> I don't care for that concept much. All it's doing is trading one set
> of boilerplate for another. I'd prefer the get() !== null approach,
> since there is a zval allocated for it, so the isset() part.
>
> And I do like the unset overloading, which is right inline with __unset()...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: internals Digest 18 Apr 2012 20:34:27 -0000 Issue 2671
> On 04/10/2012 06:20 PM, Adir Kuhn wrote: > > "PHP Gotchas, how they came to be, and why we can't simply fix them" > can't or won't? It seems that the requirement for backward compatibility, as with most software, stands in the way of any substantial leaps, and makes it impossible to do away with outdated cruft. As a result, PHP is dragging around a lot of baggage - both the language itself and the libraries. Hey, here's a crazy thought: http://www.php.net/unsub.php
[PHP-DEV] Re: internals Digest 13 Apr 2012 01:23:19 -0000 Issue 2650
> From: Arvids Godjuks > To: Kris Craig > Cc: PHP internals list , Yasuo Ohgaki > > Date: Fri, 13 Apr 2012 03:26:16 +0300 > Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts > Well, I just don't know how i can appeal to common sence to some people on > the list anymore. First the type hinting threads, now this. That was my reaction as well. Why someone would spend this much time and documentation on such a trivial issue, I'm at a loss. Don't we have bigger fish to fry? > The world does not work only on one web server and there are different type > ls of them out there. I for once use nginx and i configure how to run > scripts by locations, not by file types. I just pass the params to fastcgi > server thet runs a php binary. And it does not.care about the extension. I > can use any extension.l for my code. Yes, i use .php, others use. phtml or > other variants. Extensions are just a convension, nothing more. You can > give a file any or none extension at all and it will not change a thing.Ok, > in windows you will not be able to open the file in a program by double > click, but through the open dialog in the app - be my guest. To PHP, > fastcgi and the web server it does not matter. It just matters to people so > they can distingush between a php file, js file and a css file. This is what I was thinking, plus this: the closing tag isn't even required to begin with, so you can really think of "http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 回复： [PHP-DEV] resume after exception
2012/4/5 Anthony Ferrara :
> Why not just do:
>
> function foo(callable $callback) {
> $a = 0;
> $callback();
> $a = 1;
> $callback();
> }
>
> function bar() {
> foo(function() { echo 1; });
> }
>
> It's functionally the same, but doesn't have the stack magic.
>
> Now, it won't be able to do everything that your concept does (bubble
> up to an arbitrary point), but I see that as a good thing, since this
> is explicit. And considering that you're intending to use it as a
> control flow structure (which is not what exceptions are supposed to
> be), I would say exceptions and their dynamic nature would be
> literally a bad thing in this case...
I don't see how exceptions are anything but a control flow structure?
If all you wanted was an error-message, you'd be using trigger_error()
- the only way exceptions differ, is that they allow execution to
continue from a certain point, under certain circumstances; it allows
you to control the flow.
> It's functionally the same, but doesn't have the stack magic.
your argument and example above is certainly valid, but from the same
point of view, why not get rid of throw/try/catch statements too while
we're at it?
function foo(callabable $errorhandler)
{
if (some_condition()) {
$errorhandler();
}
}
function bar() {
foo(function() { echo 'an error occurred!'; exit; });
}
This works just as well, and as you pointed out, it's probably easier
to understand.
Now, it won't be able to do everything that an exception does (bubble
up to an arbitrary point), but you could view that as a good thing,
since this is explicit. You could argue that exceptions and their
dynamic nature is literally a bad thing in every case.
To your technical point:
> This could get really ugly as you'd be
> forced to have multiple stacks hanging around if you used more than
> one of these in your code.
I don't see how?
If you throw an interrupt, and nothing catches it, the program
terminates, same as after an exception.
if you throw an interrupt and something catches it, that interrupt
(and it's retained stack) only lives for the duration of the
catch-statement:
try {
...
} catch (Interrupt $i) {
if (some_condition())
resume; // (A)
else if (other_condition())
throw $i; // (B)
// (C)
}
There are three ways you can exit this catch{} block:
(A) we resume execution from the throw-statement, and the previous
stack remains valid.
(B) the previous stack is preserved for another catch-statement (or
exit with an error-message)
(C) if we exit the catch{}-block and don't resume, it is safe to
unwind the stack at this point. (assuming we're talking about just
interrupts, and not continuations that can be serialized and resumed
at a later time.)
I don't know why you think interrupts are so unnatural or difficult to
understand - to me, it would be a natural extension of exceptions. And
I've never understood why they are so frequently compared to GOTO. I
think it's entirely a matter of how you perceive (and apply) the idea
of exceptions - personally I see them not as a "better" replacement
for triggering errors, I really can't see them as anything other than
flow-control statements; there are few cases from which it is really,
truly impossible to recover, but when I identify such a case, I still
use trigger_error() - and granted, this is rare, but there are cases.
And mind you, registering an error-handler was possible before
exceptions were around, and we got by then - just because something
works or is well-established, doesn't mean there is no room for
improvement.
I'm not going to pretend I know enough about programming languages to
say for sure that this is a good idea - if this idea has been tried or
researched and proven "bad" already, I'd love to learn about it. But
if so, I doubt it was for any of the reasons I've heard so far...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 回复： [PHP-DEV] resume after exception
interesting, but this doesn't have anything in particular to do with
what I was talking about.
to the best of my understanding, an exception transfers control back
to the nearest calling code that has declared it is ready/willing/able
to resume control in the event that, somewhere up the call-stack, a
condition occurs that causes an exception.
it's a wonderful mechanism with more uses than simply reporting errors
- the aspect of transferring control is what I find really interesting
about exceptions.
with regards to transferring control, why does it strike you as so
unnatural to also provide a mechanism for returning control?
to me, it seems like a perfectly natural extension of that mechanism -
and of course, not as something that just happens, but as a feature
you can opt into.
since breaking program flow is already supported by exceptions, and
since that is the first half of the mechanism I have in mind, I
thought it would be natural to have an extended type of exception (I
called it an "interrupt") where it is also possible to resume program
flow after the throw-statement.
the way I defined it, as with exceptions, this requires a formal
declaration to do so, both on the part of the throwing code, and on
the part of the code that catches and assumes control after the throw.
exceptions aren't guaranteed to be handled, and similarly, there's no
guarantee that control will be returned to the throwing code after an
interrupt. for all intents and purposes, it's still an exception, and
can be handled as an exception too - the difference is, by throwing an
interrupt, you've agreed to possibly resuming execution after the
interrupt is handled, if the interrupt is caught and the catching code
decides to return control.
it's not a one-way transfer of control like a goto, where you have to
test for conditions and decide where to transfer control on a
case-by-case basis. in my mind, the term "spaghetti" doesn't describe
the program itself, but the more or less unpredictable execution path,
which can only be understood by trying to "execute" the program in
your mind. exceptions (and what I call an interrupt) does not allow
you to sporadically transfer control just anywhere, but rather follows
the well-understood mechanics of an exception, with a hierarchical
execution path - just with the added benefit of returning control from
the exception-handler after catching and handling it.
taking this one step further (with state-serialization and
continuation) was just an afterthought, something that occurred to me
while I was typing - that may be taking it too far, and really wasn't
something I've been thinking about deeply...
On Tue, Apr 3, 2012 at 3:28 AM, reeze wrote:
>
> If just for exception recovery how about implement ruby's retry ?
>
> http://www.tutorialspoint.com/ruby/ruby_loops.htm Ruby retry statement
> section.
>
>
> 在 2012年4月2日星期一，下午8:44，Rasmus Schultz 写道：
>
> I was just reading about the new async/await keywords in C# 5.0, and while
> this has no particular relevance to PHP as such, it got me thinking about
> this idea...
>
> What if you could resume execution after an exception was thrown?
>
> Fictive example:
>
> function test()
> {
> echo "Begin Test!\n";
>
> throw new Interrupt();
>
> echo "Execution resumed!";
> }
>
> try
> {
> test();
> }
> catch (Interrupt $e)
> {
> echo "Execution interrupted.\n";
> resume;
> }
>
> The output of this would be:
>
> Begin Test!
> Execution interrupted.
> Execution resumed!
>
> In other words, Interrupt is a new type of Exception, from which you can
> recover, using the new resume keyword.
>
> Taking this one step further, imagine it were also possible to serialize()
> an Interrupt - and resume it at a later time. This would open up entirely
> new possibilities for (AJAX) web-application frameworks, which would be
> able to suspend execution, serialize the script state, return a response,
> wait for further interaction from the user, and then resume execution.
>
> I'm sure there are lots of problems with this idea, and perhaps it's not a
> good fit for PHP at all, but I figured it couldn't harm to put the idea
> out
> there anyway :-)
>
> Any thoughts?
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] resume after exception
I was just reading about the new async/await keywords in C# 5.0, and while
this has no particular relevance to PHP as such, it got me thinking about
this idea...
What if you could resume execution after an exception was thrown?
Fictive example:
function test()
{
echo "Begin Test!\n";
throw new Interrupt();
echo "Execution resumed!";
}
try
{
test();
}
catch (Interrupt $e)
{
echo "Execution interrupted.\n";
resume;
}
The output of this would be:
Begin Test!
Execution interrupted.
Execution resumed!
In other words, Interrupt is a new type of Exception, from which you can
recover, using the new resume keyword.
Taking this one step further, imagine it were also possible to serialize()
an Interrupt - and resume it at a later time. This would open up entirely
new possibilities for (AJAX) web-application frameworks, which would be
able to suspend execution, serialize the script state, return a response,
wait for further interaction from the user, and then resume execution.
I'm sure there are lots of problems with this idea, and perhaps it's not a
good fit for PHP at all, but I figured it couldn't harm to put the idea out
there anyway :-)
Any thoughts?
[PHP-DEV] Re: internals Digest 22 Feb 2012 22:13:24 -0000 Issue 2561
Just a couple of quick notes...
I think that your proposal looks good, but I'd like to suggest a few
> changes. First of all, I'd like to see the association with integers
> removed. An enum instance shouldn't just be a name for an integer, it
> should be more like a singleton instance of a special kind of class
> that can only ever have a predefined set of named instances. There
> should be no value associated with it.
Strongly disagree.
Enum-values absolutely must translate to a scalar value, probably an int -
otherwise, how would you map an enum to a database, or submit it's value
via a form?
Secondly, there already exists the capacity for arbitrary classes to
> be used in foreach and count you just have to implement Iterator and
> Countable. Other interfaces that all enums might want to implement
> automatically are ArrayAccess and Serializable. This would just
> require the enum itself to be an object (maybe of type enum or
> something) such that it can implement the relevant methods.
Strongly agree!
I'm not sure what would be the value of a dedicated enum in PHP - I think
enum as a base-class with special capabilities would be a much better idea.
The requirements for enumerators often grow as you work through a problem -
today, you just need a few scalar values, tomorrow you need to iterate over
the possible value, next week you find you need to filter the values based
on a set of criteria, the week after that you suddenly need a drop-down in
a user-interface and you discover each value needs a user-friendly
description in english, and so on and so forth...
If all you really need is a simple "indicator" value of some sort, just use
class-constants with integer values - works nicely.
If you need anything more than that, it's likely you'll soon need more than
an enum anyway, regardless of how "fancy" your enum implementation is. I
would also point out, that the more "advanced" features you add to your
enum, the more you will find those features resemble class-features.
Another point I'd make, is that for anything enum-related, you often end up
needing functions that translate, sort, or filter, based on the values of
that specific type - with a dedicated enum-type, you'll end up needing a
class to go along with your enum to handle those things. Why not just use a
class in the first-place then?
In strongly-typed, compiled languages, I see the case for enums.
For a language like PHP, I think classes and objects would make more sense.
As said, I tend towards class-constants myself, but let's take this:
enum Foo
{
Bar = 1,
Baz = 2
}
And compare to this:
class Foo extends Enum
{
public static $Bar;
public static $Baz;
}
Foo::$Bar = new Foo(1);
Foo::$Baz = new Foo(2);
Was it really that much more work? How many enums do you add in a day? :-)
Now you can strongly type function-parameters, e.g.:
function doStuff(Foo $kind) { ... }
doStuff(Foo::$Bar);
doStuff(Foo::$Baz);
In a sense, enums in most languages are just crippled classes, although in
system-languages of course there's the benefit of enums performing better.
But I think you won't get a significant performance advantage from native
enums in a language like PHP.
Note that I'm assuming here that there's a base-class called Enum - it
would be nice if this implemented Iterator or IteratorAggregate, Countable,
etc.
The beauty of this approach as opposed to a native enum, is that you can
extend the Enum type to provide display-friendly values, ORM integration,
form integration, filtering, sorting, etc.
If you don't need any of those features, just use class constants.
Just my two cents...
Re: [PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549
On Sat, Feb 4, 2012 at 1:13 PM, Clint M Priest wrote: > The read-only and write-only keywords act a little differently. Without > them, attempting a set on an accessor without a setter defined will cause > __set() to be called whereas with the read-only it will produce an error. > The inverse is true for write-only. I attempted to keep the ability to > have lazy initializing of properties via accessors, but that could be > written in php slightly differently if the read-only/write-only keywords > were not present (due to guards). Doesn't particularly matter to me. > I'm hard pressed to think of a real use-case for something like that - seems like this could easily cause confusion, having the getter invoke one mechanism, and the setter an entirely different mechanism. In my opinion, if you declare an accessor (whether get, set, or both) the accessor-mechanism should take over and replace the "magic" methods. In the case of a read-only or write-only accessor, I'd expect an exception, not a magic method as a secondary fall-back mechanism. Accessor-methods* *aren't magic, they're concrete properties that execute code when you use them. Accessors give you more compartmentalization than __get() and __set() which work for "wild" property-names - e.g. in situations where you don't know at design-time whether a property exists; but with accessors, you're defining concrete property-names, so there is no need for "magic". In my opinion. And then there's the matter of actually explaining the read-only and write-only keywords to programmers, and the difference in behavior. This would be easier to explain, if the difference wasn't almost a different * language*-behavior. Normally, public $foo prevents both __get() and __set() being invoked for the $object->foo property - that's been a given for a long time, and it's a mechanism that is easy to explain and easy to understand. While you could certainly explain how this works, and I personally understood your explanation, as said, it's very hard for me to think of a real use-case - so while you can make it understood how this works, technically, it's unlikely that you, as a programmer, will ever actually care or fully understand the differences until someday you run into it. It's less likely to be something you look for to solve a particular problem - which means it's more likely to get in the way. Just my opinion :-) > > Would it not be more correct to implement an auto-backing field as > protected? The reason for implementing accessors in the first place, is > > usually to prevent direct access to an underlying field. > > Makes sense, in C# these backing fields are completely inaccessible > directly, would that be even better in this case or would protected suffice? > There are definitely situations (such as ORM) where you may need access to the backing-field... It's a common requirement when, for example, the set-accessor has side-effects. A dirty-flag, timestamp or version-number, for example - you don't want those invoked when the ORM hydrates an object with database-values. There are also cases when backing-fields get initialized at construction - when a class extends another class, the enhanced constructor might need direct access to the backing-field.
[PHP-DEV] Re: internals Digest 4 Feb 2012 09:08:29 -0000 Issue 2549
A couple of quick comments... Why can't the read-only and write-only keywords be implicit instead of explicit? I've never seen another language where you have to explicitly indicate what you're doing. At best, it acts an extra fail-safe to prevent making errors - at worst, it just means more redundant code to maintain, more ways to make errors. Do the benefits really outweigh the value of this? Regarding automatic implementations - according to the wiki, the backing field is implemented as public. Is that correct? Most other languages don't even expose the existence of the backing field. Would it not be more correct to implement an auto-backing field as protected? The reason for implementing accessors in the first place, is usually to prevent direct access to an underlying field. Since a high degree of explicitness seems to be a design goal, it would probably make more sense if you had to use reflection to access a backing-field without invoking the accessor-methods. Looks nice otherwise! :-) - Rasmus 2012/2/4 > From: Clint M Priest > To: "internals@lists.php.net" > Cc: > Date: Fri, 3 Feb 2012 13:47:53 + > Subject: [PATCH] Property Getters/Setters (v2.4) for review > The property accessor functionality is done and is detailed here: > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented > > Core Patch: http://www.clintpriest.com/patches/php-core/accessors/2.4.diff > > The core patch encompasses the entire original RFC and the as-implemented > includes implementation details and edge cases not defined by the original > RFC. > > Most changes are in zend_compile, zend_object_handlers and > zend_language_scanner. > > Thanks, > > -Clint
Re: [PHP-DEV] ReflectionFile missing
Well, my thinking was, in my annotation engine, rather than globally registering aliases for fully-qualified annotation-type class-names, I would support the use-statement. This is generally how it works in other languages (such as C#) that have built-in support for annotations. So you'd be able to say "use VendorName\AnnotationLibrary\SomeAnnotation" at the top of your script, and emulating the PHP name-resolution rules, you would then be able to annotation classes/properties simply with "@some" rather than the full class-name. I know this is very specific to my project, but I could see this being important to other aspects of meta-programming with PHP in general. Clearly I'm not the first person who has needed this - there are numerous (more or less complete) implementations around the net... Although as said, I see your argument about time/effort vs usefulness, and I do agree, there are probably other areas of PHP in need of more immediate attention than this one. It is a problem that can be solved with user-code, although, as always, that means varying APIs of varying quality, and most likely some degree of duplication, since each library that needs these feature is going to implement this feature in different ways... 2012/1/30 Johannes Schlüter > On Mon, 2012-01-30 at 09:33 -0500, Rasmus Schultz wrote: > > From my point of view, the concept of a "file" has become semantically > more > > important, and increasingly relevant to Reflection, with the latest PHP > > features added in the past couple of years. > > > > I can see what you mean though - it's probably not a small effort, and > > there are probably more important aspects of PHP that need attention... > > When at runtime do you need this? - I can see the need for doing it > "statically" when building some form of autoloading map or such. > > For static analysis I (in my personal, probably narrow) opinion see > little benefit in doing it from within PHP (see other part of the > thread) > > johannes > > >
Re: [PHP-DEV] ReflectionFile missing
>From my point of view, the concept of a "file" has become semantically more
important, and increasingly relevant to Reflection, with the latest PHP
features added in the past couple of years.
I can see what you mean though - it's probably not a small effort, and
there are probably more important aspects of PHP that need attention...
2012/1/29 Johannes Schlüter
> Hi,
>
>
> On Sun, 2012-01-29 at 18:51 -0500, Rasmus Schultz wrote:
> > I realized the other day that ReflectionFile is missing from the
> Reflection
> > API.
>
> As is ReflectionNamespace and some others one might think about. In the
> end it boils down to the fact that we don't have structures internally
> representing them as for PHP there is no need to keep the data and then
> we're restrictive in adding such meta-data just for the purpose of
> reflection. Mind that we'd have to keep all that in memory and opcode
> caches have to copy it around etc. in the end the consensus was: the
> effort needed doesn't seem worthwhile.
>
> The alternative would be to "emulate" it, something like
>
>class ReflectionFile {
>private $filename;
>private $classes = array();
>private $functions = array();
>
>private initFunctions($filename) {
>foreach(get_defined_functions()['user'] as $f) {
>$rf = new ReflectionFunction($f);
>if ($rf->getFilename() == $filename) {
>$this->functions[$rf->getName()] = $rf;
>}
>}
>}
>
>private initClasses($filename) { /* ... */ }
>
>public __construct($filename) {
>$this->filename = realpath($filename);
>$this->initFunctions($this->filename);
>/* ... */
>}
>
>public getFunctions() {
>return $this->functions;
>}
>
>public getFunctionNames() {
>return array_keys($this->functions);
>}
>
>/* ... */
>}
>
> But that feels more like a hack than a solution, too.
>
> johannes
>
> PS. Mind that the example you've given even works on files not included
> by parsing files, whereas internal reflection provides information what
> actually is available from engine point of view ...
>
>
[PHP-DEV] ReflectionFile missing
Dear List, I realized the other day that ReflectionFile is missing from the Reflection API. A search for "ReflectionFile" on Google will reveal a number of implementations of classes with exactly that name, which suggests users are missing this - for example: https://github.com/rmccue/ReflectionFile/blob/master/ReflectionFile.php I think reflecting on files used to be less important than it is now - with the addition of namespaces, and the ability to import classes and interfaces from other namespaces, there are some interesting and useful aspects of files that could be exposed via Reflection. One thing that comes to mind, is with custom annotation libraries for PHP - some libraries (such as my own) permit you to globally set custom aliases to make annotation-names shorter and more useful, others resort to making you type the fully qualified class-name every time you want to apply an annotation. Neither approach is very elegant. This is addressed by the language, by allowing you to import classes and interfaces - annotation libraries could discover imported annotation types this way, but that aspect of the source code is not exposed via Reflection. Any thoughts? - Rasmus Schultz
[PHP-DEV] APC caching identical files multiple times
Hello Folks, We're hosting an increasing number of Drupal (ick) sites on our servers, and while going over the diagnostic screen for APC, we noticed that identical files are being cached multiple times. For example, "user.module" is cached 3 times for 3 sites. I've seen other people asking this question around forums and on SO, but no clear answer. According to the change-log, release 3.1.1 includes a "file_md5" option, which seems to be a dud - or maybe this was intended to be implemented at some point, but currently does nothing? The documentation isn't clear on what this option is for. It seems like it should not be too difficult to use an md5 (or other hash) of the file contents plus filename (sans path) and use that as the cache key? In shared hosting environments, this could reduce in-memory duplication quite a lot, or not? I think it's common to host multiple Drupal, Joomla or WordPress sites - all of which could share a common codebase, but personally I don't want them to, since this creates problems with deployment and maintenance/upgrades, and it seems like this would be a work-around more than a solution. Most sites use a framework these days, and most companies have one or two frameworks they prefer, so this feature would make a lot of sense. Is there some reason this is not as easy to implement as it might seem? (and just occurred to me, is this the correct list for this post? my apologies if it's not. looks like a lot of the contributors are on this list...)
Re: [PHP-DEV] Phalanger
You want to compare Mono performance to .NET performance - I'm sorry, but I don't see how that's even relevant? Your benchmark would be relevant if I was proposing you write a PHP interpreter and run that on Mono. What I'm proposing (and what Phalanger does) is to compile PHP code to CLR bytecode, and running it directly on the VM - I'm not saying run an interpreter under the VM. That would be pointless. So what you should be comparing, is Mono performance against PHP performance. What you should be comparing is probably something closer to this: http://shootout.alioth.debian.org/u64q/performance.php?test=spectralnorm (and I realize of course that CLR bytecode derived from a dynamic language like PHP was have a considerably higher runtime overhead than that of a static language like C#, but it should still be orders of magnitude faster than an interpreter.) According to the chart you mentioned, Mono performance on Linux is comparable to that of Java - which has performed adequately to support a very large industry and thousands of languages. Sure, .NET is orders of magnitude faster than that. But it is optimized for a single platform, and if we're looking at cross-platform VM alternatives, your two best choices are Mono and Java - .NET should not even be in that chart, except for the sake of argument that Mono has room for optimization still. Also, according to your chart, Mono has considerably lower memory usage, which could be relevant when running highly parallelized applications such as web-services. Here's another chart I'm sure you've all seen, comparing the Windows build of PHP to Phalanger: http://www.php-compiler.net/benchmarks Yes, performance is worse under Linux - probably around half the speed you get under .NET on Windows. Does that mean it's going to be slower under Mono than the Zend VM? I would say not likely. But I guess we'll have to wait for a Linux PHP vs Linux Phalanger benchmark to know for sure... - Rasmus On Thu, Dec 8, 2011 at 7:16 PM, Rasmus Lerdorf wrote: > On 12/08/2011 03:53 PM, Rasmus Lerdorf wrote: > > This is a complete non-starter. The bulk of PHP users are on > > non-Windows, especially Linux, and Mono performance on Linux is really > > not good. Last time I checked it was an order of magnitude slower on > > Linux compared to the same hardware running Windows. Granted that was > > quite a few years ago now and I assume it is no longer 10x slower. > > Perhaps it is up to 4x or even 2x slower. > > Here are some more recent numbers to back that up: > > http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx > > Basically what you are suggesting is that we replace the Green bar there > with the Grey one. Note that lower is better. This does show that Mono > performance is starting to approach .Net performance, at least for this > benchmark, but it still isn't there. And if you look through the various > benchmarks you will see that native C/C++ code is 5-10x faster than the > same code running under Mono. > > -Rasmus > >
[PHP-DEV] Phalanger
Don't take this the wrong way, I'm merely trying to provoke your thoughts a bit with this e-mail! :-) Has it occurred to anyone, to abandon the official PHP codebase and adopt Phalanger instead? Some convincing (to me) points: - Phalanger runs on Mono, meaning similar platform-reach as PHP. (but eliminating most platform-specific implementations.) - It's fast. (probably fast enough to mostly eliminate the need for native extensions in general.) - The community would be able to write modules/extensions in PHP or other CLR languages. - It's secure. (not that C/FFI PHP extensions tend not to be trustworthy, but they do tend to come from a relatively small group of authors.) - Access to more languages means a much bigger community who can contribute extensions and core patches. - Access to existing CLR codebases means more third-party libraries can be readily integrated without writing and maintainting C/FFI wrappers. - The codebase is new, clean and modern (it's not dragging around a lot of legacy baggage.) - Fully take advantage of new 64-bit hardware (vector computations and larger address space) in all aspects. (core, extensions, PHP scripts). I'm not going to try to sell you on the fact that the integration with the Windows world is tighter in Phalanger than in PHP - but it is a point that carries considerable weight to many businesses. People I know have had a tendency to view Phalanger as "PHP for Windows" - it's really not. It's PHP for CLR - and CLR is not (only) Windows. And it is readily available on most modern operating systems with good support for various hardware platforms. Now, before you start flaming me - I'd love to hear precisely why you're eager to hang on to the C codebase. What are the benefits of the C codebase over Phalanger? I understand the licensing may be an issue. It may be the argument that outweighs everything else, but I'm curious to hear what else would keep you from moving to Phalanger? Thanks! - Rasmus Schultz
Re: [PHP-DEV] Patch: getters/setters syntax Implementation
I have no opinion about how it gets implemented under the hood - I thought
we were just discussing the syntax. I most likely don't know enough about
the innards of PHP it carry on that discussion.
But by userspace definitions, are you referring to the fact that getters
and setters would compile down to actual methods? I have no strong feelings
about that one way or the other - as long as the reflection API reports
what was defined in the source code, rather than reflecting the underlying
accessor-methods as actual methods. (something that doesn't seem to be true
for traits...)
I don't know if that's meaningful or relevant to you, but I think that's
all I can contribute to that discussion...
On Wed, Dec 7, 2011 at 1:11 PM, Will Fitch wrote:
> The difference being *where* the functionality gets mapped. It's not
> about making something "look like something else", it's about requiring
> more userspace definitions. Functionality within get {} and set {} can
> (and should IMO) be implemented outside of userspace code. Whether that
> means another union within op_array or a completely new structure mapped to
> a property zval and bitmap added to the zend_uchar type identifying it as
> an accessor I'm saying be creative - don't just implement something
> halfway for the sake of getting it done.
>
>
> On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote:
>
> >> if we're attempting to get around __set/get, let's not replace them with
> > more method implementations
> >
> > I don't understand this argument. Accessors are methods - making them
> look
> > like something else won't change that fact.
> >
> > In C#, type-hinted properties with automatic getters/setters actually
> > compile down to two method implementations, while implemented
> > getters/settings do the same, substituting "value" for whatever is
> required
> > to access the auto-implemented backing field.
> >
> >
> > On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch wrote:
> >
> >>
> >> On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote:
> >>
> >>> I agree with all of those points - the extra indentation looks messy,
> and
> >>> yes, type hints are important. It does fit better with PHP in general.
> >>>
> >>> It would be nice to also have support for automatic backing fields in
> >>> addition though - so something simple like this:
> >>>
> >>> class BlogPost
> >>> {
> >>> private $_author;
> >>>
> >>> public get author()
> >>> {
> >>> return $this->_author;
> >>> }
> >>>
> >>> public set author(Person $value)
> >>> {
> >>> $this->_author = $value;
> >>> }
> >>> }
> >>
> >> I don't like this approach. All efforts (which I'm currently part of)
> to
> >> implement type hinting return values will be compromised. If you want
> to
> >> implement accessors, keep them within a syntax that makes sense.
> >> Personally, I support the C# style as much as possible. Methods are
> >> already overused for purposes they shouldn't be, so if we're attempting
> to
> >> get around __set/get, let's not replace them with more method
> >> implementations.
> >>
> >>
>
>
Re: [PHP-DEV] Patch: getters/setters syntax Implementation
> if we're attempting to get around __set/get, let's not replace them with
more method implementations
I don't understand this argument. Accessors are methods - making them look
like something else won't change that fact.
In C#, type-hinted properties with automatic getters/setters actually
compile down to two method implementations, while implemented
getters/settings do the same, substituting "value" for whatever is required
to access the auto-implemented backing field.
On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch wrote:
>
> On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote:
>
> > I agree with all of those points - the extra indentation looks messy, and
> > yes, type hints are important. It does fit better with PHP in general.
> >
> > It would be nice to also have support for automatic backing fields in
> > addition though - so something simple like this:
> >
> > class BlogPost
> > {
> >private $_author;
> >
> >public get author()
> >{
> >return $this->_author;
> >}
> >
> >public set author(Person $value)
> >{
> >$this->_author = $value;
> >}
> > }
>
> I don't like this approach. All efforts (which I'm currently part of) to
> implement type hinting return values will be compromised. If you want to
> implement accessors, keep them within a syntax that makes sense.
> Personally, I support the C# style as much as possible. Methods are
> already overused for purposes they shouldn't be, so if we're attempting to
> get around __set/get, let's not replace them with more method
> implementations.
>
>
Re: [PHP-DEV] Re: Patch: getters/setters syntax Implementation
On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote:
> 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/**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-7f30.html#**
> WS5b3ccc516d4fbf351e63e3d118a9**b90204-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
>
I agree with all of those points - the extra indentation looks messy, and
yes, type hints are important. It does fit better with PHP in general.
It would be nice to also have support for automatic backing fields in
addition though - so something simple like this:
class BlogPost
{
private $_author;
public get author()
{
return $this->_author;
}
public set author(Person $value)
{
$this->_author = $value;
}
}
Could be written like this:
class BlogPost
{
public Person $author;
}
Effectively, this shorthand syntax just gives you type-safe properties -
but it refactors nicely, since you can replace it with a full
implementation of a backing field at any point.
(on second thought, I don't like the idea I suggested before - adding a
magical $value in accessors, similar to $this - it's confusing and it's
going to look like an undeclared local variable...)
[PHP-DEV] Re: Patch: getters/setters syntax Implementation
2011/12/4 Clint M Priest :
> 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?
Re: [PHP-DEV] some notes about traits
who can hook me up with a login, so I can contribute to the documentation? > Here's a better example of something useful that actually works: >> > > Assuming your example is OK, you could edit the doc and submit it as a > patch at https://edit.php.net. > >
Re: [PHP-DEV] some notes about traits
Hi Stefan,
Appreciate you taking the time to discuss this - and I apologize if I
jumped the gun with some of these comments.
I knew about the traits features in Scala, and I guess I assumed this would
be similar - not so.
Reading through my own remarks and your comments, I now have a better
understanding of what traits are, and how they're intended to be used.
I believe the key to understanding traits, is understanding that traits are
in fact an implementation detail - an artifact that does not really change
or affect the nature of OOP in PHP as such, and by design, should not. I
understand that now - thank you :-)
>From my perspective, a key difference from classes and interfaces, is that
traits have no meaningful use at run-time - no type-hinting and with no
real reflection-features that reveal the details. They cannot implement
interfaces for classes, but classes can use them to implement interfaces.
Traits just provide a set of method implementations that can be aggregated
by classes. So in a sense, they're a design-time tool for the programmer.
So I guess my remaining quibble is that the documentation needs to relay
this somehow - with a basic real-world example that actually uses an
interface too, to clarify the difference, and to demonstrate how this tool
use useful in conjunction with class and interface declarations. Hello
world really doesn't explain anything, other than the syntax.
Here's a better example of something useful that actually works:
trait Accessors
{
public function __get($name)
{
return $this->{'get'.$name}();
}
public function __set($name, $value)
{
$this->{'set'.$name}($value);
}
}
class OrderLine
{
use Accessors;
public $price;
public $amount;
public function getTotal()
{
return $this->price * $this->amount;
}
}
$line = new OrderLine;
$line->price = 20;
$line->amount = 3;
echo "Total cost: ".$line->total;
This may be a little too magical for an example in the documentation though
- and doesn't demonstrate interfaces.
I'll ponder this and post a better example if I can think of one... :-)
And just one other comment:
> > var_dump($test instanceof CartBehavior); // => false
> Why would it be beneficial to throw an exception here?
CartBehavior is a trait, and not a class or interface. The instanceof
operator has no meaning for traits - it always returns false.
You could argue that false is the expected result - I would argue that the
only reason this happens to work at all, is because traits internally are
classes.
Suppose you thought you were actually doing a meaningful type-check of some
sort? If by mistake you put a trait-name where you meant to put the name of
an interface or class, such an error could be very hard to spot.
Since there is no such thing as an "instance of" a trait, the instanceof
operator should not work for traits.
Once again, thank you for taking the time to talk about this, Stefan - I
hope this feedback is useful :-)
- Rasmus
On Fri, Nov 11, 2011 at 12:02 PM, Stefan Marr wrote:
> Hi Rasmus:
>
> First, sorry, I don't have currently the time to reiterate all discussions
> on these questions.
> Please, do me the favor and search the archives for previous discussions.
> I believe _all_ points you raise here have been discussed and commented
> before, and most of them quite recently.
>
> Since I believe the answers are already given,
> let me try another approach to tackle your problems.
> From my perspective the purpose of traits is often misunderstood.
> So, let me ask a few questions. They might sound basic,
> but I want to better understand your design rational,
> and the reasons behind your implementation approach.
>
> If you got the time, please try to answer all of them.
> They might seem suggestive, or even worse, 'rhetorical',
> but that is not on purpose.
>
> Answering them will help us all better to understand
> what the underlying issues/conceptual problems are we need to tackle,
> either by improving the current implementation and/or documentation.
>
> On 11 Nov 2011, at 17:00, Rasmus Schultz wrote:
>
> > class Cart
> > {
> > public static $instance;
> >
> > # public function addItem(CartBehavior $item, $amount=1) // => script
> > terminates
> > public function addItem($item, $amount=1)
> > {
> >echo "Adding {$amount} {$item->getName()} to shopping cart - price =
> > ".($amount * $item->getPrice())."\n\n";
> > }
> > }
>
> What is the real purpose of adding the type hint for CartBehavior here?
> My understanding would be, you want to express/document that the given
> object is required to support a specific set of operatio
[PHP-DEV] some notes about traits
It seems to me, there's a couple of things related to traits that were
missed in this implementation.
Take the following example:
script
terminates
public function addItem($item, $amount=1)
{
echo "Adding {$amount} {$item->getName()} to shopping cart - price =
".($amount * $item->getPrice())."\n\n";
}
}
Cart::$instance = new Cart;
trait CartBehavior
{
public function addToCart($amount=1)
{
Cart::$instance->addItem($this, $amount);
}
}
class Product
{
use CartBehavior;
private $_name;
private $_price;
public function __construct($name, $price)
{
$this->_name = $name;
$this->_price = $price;
}
public function getPrice()
{
return $this->_price;
}
public function getName()
{
return $this->_name;
}
}
$test = new Product('Fish', 100);
$test->addToCart();
var_dump($test instanceof CartBehavior); // => false
var_dump((new ReflectionClass('Product'))->getTraits()); // CartBehavior is
a ReflectionClass?
The first problem is that type-hinting isn't supported... so you have this
horizontal extensibility now - traits are kind of like interfaces with a
built-in implementation. They're more like interfaces than classes, at
least, in the sense that they can't have state, and you can't create an
instance of a trait.
So the first issue is, you can't use a trait as a type-hint - the addItem()
method can't be type-hinted, so we can't define explicitly what to expect
here. This is one of the most important reasons for having interfaces,
perhaps the second-most important after the ability to enforce conformity
on class implementations. Traits don't work in this case. And sure, you
could add an interface too, and redeclare all your accessors again. But
why? An abstract base-class with some abstract methods seems like a much
stronger tool, except that you can't reuse that horizontally...
Secondly, the instanceof operator doesn't complain when you test to see if
an object carries a trait - if this isn't going to work, it should at least
throw an exception. Although as pointed out, it seems natural to expect
that this would work.
Lastly, when you reflect on a trait, it comes back as an instance of
ReflectionClass. As pointed out, traits are probably more similar to
interfaces than they are to classes, and they definitely don't have
properties, as are exposed by the ReflectionClass type.
I would also point out that the examples in the documentation (which it
seems were just copied from the RFC?) do not demonstrate any real purpose
of this feature. Is this the most anybody has attempted to do with this
feature? Trying to come up with a real example, I didn't get very far
before running into these stumbling blocks.
If this feature is useful in it's current form, I don't see how - and the
examples in the documentation definitely do not demonstrate any real
practical use for this.
Here's another quick example demonstrating these problems:
interface MyInterface
{
public function myMethod();
}
trait MyTrait # implements MyInterface // fails (B)
{
public function myMethod()
{
echo "foo";
}
}
class MyClass implements MyInterface
{
use MyTrait;
}
$test = new MyClass;
var_dump($test instanceof MyInterface); // true
var_dump($test instanceof MyTrait); // false (A)
If I can't use instanceof to check for a trait (A), then I would at least
expect to be able to write a trait that implements an interface (B) - does
that not seem reasonable or logical?
Having to use both the interface and the trait as a pair, and having to
explicitly apply them both to the class, feels like a work-around.
I apologize if I'm somehow missing the big picture here, or maybe I set my
expectations too high - but my first impression of this feature is that
it's crippled and somewhat half-baked... If there was a deliberate and
logical reason for not supporting these features, I would like to
understand why. If not - great work so far, but perhaps this feature is not
quite mature enough for release just yet?
- Rasmus
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload
I'm not talking about the __call() magic method, I'm proposing a global and/or namespaced call to a flat __call() *function *- you could use it to implement autoloading like so: * * closure) and loading scripts that return an anonymous function. Similarly, we could use a namespace-specific __call() function as shown above, to autoload functions. It was just a thought - just throwing it out there for discussion, I'm not submitting a complete RFC at this point :-) / Rasmus Schultz On Sun, Aug 14, 2011 at 6:44 PM, Ferenc Kovacs wrote: > On Mon, Aug 15, 2011 at 12:11 AM, Rasmus Schultz > wrote: > > Instead of trying to figure out how to autoload functions and cover all > your > > bases, how about simply adding a __call() magic method? > > > > That way, each application (or framework) can make their own decisions > about > > what they're going to autoload and how. > > > > A much simpler solution, and one with more potential uses than just > > autoloading. > > > > The __call() method could be invoked first in the current namespace, if > > present - then in the parent namespace, if present, etc. up to the global > > namespace. Since functions are no longer just global, but can now exist > in a > > namespace, it is likely you're going to need a different "autoloader" or > > other dynamic function resolvers in each namespace, since we tend to > create > > a namespace for classes/functions designed to perform a specific kind of > > task - for example, a template/view-engine probably needs to autoload > > display-formatting functions, while a controller/dispatcher might need to > > autoload action-filters, etc. > > > > Just a thought :-) > > > > / Rasmus Schultz > > > > we already have a magic method with the name __call. > I'm not sure where you propose adding this magic method, but judging > from it's name, you would like to propose something similar than > __autoload what we have abadoned for many reasons, the main reasons is > that the spl_autoload_register is more explicit and supports having > multiple callbacks. > > please create an RFC for your idea, from first glance, I feel that you > didn't really thought over the details yet. > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload
Instead of trying to figure out how to autoload functions and cover all your bases, how about simply adding a __call() magic method? That way, each application (or framework) can make their own decisions about what they're going to autoload and how. A much simpler solution, and one with more potential uses than just autoloading. The __call() method could be invoked first in the current namespace, if present - then in the parent namespace, if present, etc. up to the global namespace. Since functions are no longer just global, but can now exist in a namespace, it is likely you're going to need a different "autoloader" or other dynamic function resolvers in each namespace, since we tend to create a namespace for classes/functions designed to perform a specific kind of task - for example, a template/view-engine probably needs to autoload display-formatting functions, while a controller/dispatcher might need to autoload action-filters, etc. Just a thought :-) / Rasmus Schultz
[PHP-DEV] Re: internals Digest 10 Jul 2011 16:41:19 -0000 Issue 2392
Hello list, I'd like to share a brief critique of the proposed "foreachlist" feature - https://wiki.php.net/rfc/foreachlist The argument that this makes code more flexible, is questionable - in my opinion, it makes the code less flexible, since nested arrays have to be nested with their dimensions in the order you expect to iterate through them. This makes refactoring more difficult, since if you want to change the iteration order, you'll need to either reorganize the dimensions of the array, or fall back on the old syntax, using two nested foreach statements. In my opinion, this syntax gives you less control, in favor of shorter syntax - and all you've saved is a couple of curly braces and the word "foreach", which just got replaced with the word "list" anyway. So I don't even see how this is very convenient. I also don't think this syntax is very transparent - it's not by any means obvious what's happening, and this syntax is going to throw off newcomers. It makes it appear as though you're performing one loop iteration, when you're actually performing two (or more) nested iterations. And finally, it's not clear to me how this feature would work in conjunction with the "break" and "continue" statements - at what dimension would a break or continue statement operate? the inner-most? or the outer-most? Either way, this is not going to be obvious from reading the code. Or would the break/continue statements not work at all? In that case, I would argue again that this feature complicates refactoring, and also in some cases optimization, since you would have to rewrite the code using nested foreach-statements to eliminate redundant processing by using break or continue. In my opinion, this feature is syntactic sugar - I find it unnecessary, and it does not add any considerable benefits in terms of code volume or clarity. It harms transparency, ease of refactoring and potentially performance, too. I don't see a description in the RFC explaining what this feature is for, or how it compares to existing syntax? And even so, it would be a hard sell for me. Regards, Rasmus Schultz
