2012/10/15 Clint Priest cpri...@zerocue.com
Also, your should be valid statement implies that you feel properties
and accessors are the same and they are not, internally. When a class
attempts to implement an interface a function check is done and since
there is no __getXX() function defined
I prefer the current syntax to your proposal because:
1) It is not at all obvious which side is which. Example:
*protected:private
*Is protected* *for get? Or set? The average PHP developer will have no
idea. In fact, they likely won't know that they even correlate to get and
set.
2)
Hi!
public DateTime $date;
This is *real* progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic language like PHP, for reasons that were amply
Hi!
The RFC states
ReflectionClass::getMethods() will not return accessor functions
(hides implementation detail).
Up until now reflection is leaky and is telling the truth. We should
either keep that or completely clean up reflection. (mind also
get_class_methods() and
Hi!
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
My feedback on the RFC:
1. Accessors IMO should be regular PHP methods that PHP generates with
two additional things:
a. Their name is generated by PHP
b. Their argument set is defined by the accessor pattern (i.e. same
thing as
Hi!
Does the PHP programmer need the truth of underlying language
implementation details or do they need the truth of what they've
defined?
If the method exists, he needs to know it exists. For the rest, see below.
I would argue that if the PHP programmer has defined a property
accessor
Hi!
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is a *huge* feature - one of the
This discussion is opened in the dedicated thread. I used my proposal as an
example to illustrate my point of view, not to pollute this thread.
2012/10/16 Jazzer Dane tbprogram...@gmail.com
I prefer the current syntax to your proposal because:
1) It is not at all obvious which side is which.
Hi!
I think that accessors should be allowed with interfaces because an
interface really is a specification on how to communicate and while
accessors do pass messages, properties do not.
Communicate is a loaded term. Property access is communication too,
but properties aren't defined in the
#2: I agree with you here - this is problematic. isset/unset accessors that
invoke the isset/unset function should actually invoke the function rather
than being compared to null, as that isn't the same as isset.
#5: From what I understand, an extending class can not override an accessor
with a
Hi!
#5: From what I understand, an extending class can not override an
accessor with a non-accessor.
This should be in the RFC then - along with what exactly happens. Note
that this will represent a sort of BC break in terms that you could have
two properties $a before, but if you change
2012/10/16 Stas Malyshev smalys...@sugarcrm.com
public DateTime $date;
This is *real* progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed language, which would not work well in a
dynamic
Hi!
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
I have no idea what rock-solid modern tool means, though PHP is
trivially a modern tool by being
Hi!
Not necessarily strongly typed. (sorry to land on this topic afterwards)
As I see PHP, it's a language that can be used as an informal scripting
language, but also as a rock-solid modern tool.
I have no idea what rock-solid modern tool means, though PHP is
trivially a modern tool by being
Hi!
In regards to #11, yes, you'd just write {}. I imagine you could also
This doesn't work for the same class (and for traits which put things in
the context of the same class) - it would not behave as no setter, it
would behave as there's a setter doing nothing. Is this the proposed
solution?
Stas, the proposed solution thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write only
I haven't done an exhaustive analysis of every language out there that supports
interfaces but to my knowledge there isn't a single one that supports
properties in interfaces. Again, not exhaustive either but there is one
language that does support accessors in interfaces and that's C#.
When
I would have to agree with Stas, the type hints that are presently implemented
are failed code waiting to be found. Good luck if you're not monitoring your
error logs. I can agree with the concept of wanting to avoid having to do all
kinds of simple verification of input parameters but
At this point, the last two weeks of deliberations on this RFC have pushed its
release back quite a long ways. I don't know when 5.5 is due out but if it's
within the next 6 months (and I'm the only one working on the code) then it
will probably not be happening. Due to the dramatic changes
2012/10/16 Stas Malyshev smalys...@sugarcrm.com
Also, the fact is that other dynamic languages do not
have strong typing. It may be they just aren't smart enough to recognize
everybody needs it - or there may be a reason why it doesn't happen. I
think there is a reason
Doing the same for
Hi!
Stas, the proposed solution thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write
I apologize for my confusing terminology - let me elaborate. There are no
special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code between the
curly braces.
Hi!
If the first could be useful, the second could be useful too. Or you are
saying that parameters type hinting was a bad idea?
Given how it is understood now - as a first step to make PHP a strongly
typed language - yes, I'm starting to think it was. If it was understood
as it was intended -
Hi!
I apologize for my confusing terminology - let me elaborate. There are
no special syntaxes. The below code should help clear things up a bit:
class MyClass {
private $otherProperty;
public $property {
get() {}; // Does not have a body, as there is no code
Hi!
that supports properties in interfaces. Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.
So what C# does when mixing regular properties and accessorized properties?
Think about it, if you allowed an outside caller of your
Excuse my late-night-influenced terminology, the word empty is much more
suitable than does not have.
And this solution really is more of a hack or work-around than a solution.
I do think that there is a better way to go about implementing
read/write-only, but nothing has come to mind as of yet -
Hey Stas, a bunch of this has already been covered but I will attempt to answer
each of these as is my current understanding of the hives decision... :P
1. Accessors IMO should be regular PHP methods that PHP generates with two
additional things:
a. Their name is generated by PHP
b. Their
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
Hi!
private final get/set() {} is indeed not a read/write only functionality. I
really would like to keep new keywords out of whatever syntax is
implemented, but I think the latest proposal can and should be improved
upon.
I've been thinking about this quite a bit.
To reiterate the initial problem,
This would conflict with the concept of auto-implementation, which if we went
with Nikita’s suggestion, would make an undefined body setter actually set the
property it shadows.
For example
class a {
public $prop {
get() { … }
Hi!
This is the way it is, though Nikita strongly disagrees that they
should be callable, visible methods on the object and I agree with
Nikita on this issue, I never did like the idea that __getHours() and
I think PHP engine has enough complexity and we do not need to add more
unwarranted
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
Yes, I'm aware - I thought of the clash with Nikita's proposal while
writing mine, but decided not to bring it up. If we were to go with my
proposed syntax, then one of two things would have to happen.
1) Don't auto implement get/set. *On a similar note, what's the difference
between using a
Hi!
If you have a public property $a which internally can only deal with
it being set to 2 or 3 and someone external to the class sets it to
4, your class either has to check that it's 2 or 3 and deal with the
fact that it is now 4 or have indeterminate results when it is set to
4.
Most of
Gabeezus, I have to get to work Stas! ;)
This is the way it is, though Nikita strongly disagrees that they
should be callable, visible methods on the object and I agree with
Nikita on this issue, I never did like the idea that __getHours() and
I think PHP engine has enough complexity and
2012/10/16 Clint Priest cpri...@zerocue.com
In this regard, I have yet to see any proposal that is as clear or concise
as public read-only $abc. What is the big problem with adding read-only
and write-only keywords? Once they are in the language they could be
expanded to plain properties.
Hi!
I very much disagree, engine details should not be visible to users.
It is irrelevant to them and only serves to confuse.
It's not engine detail. We're not talking about exposing C pointers or
zend_op values. We're talking about implementing methods that have
special meaning. They are
On Oct 16, 2012 11:27 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until
Stas Malyshev wrote:
What remains on your TODO list for this functionality?
When are you planning to run an RFC vote on this?
I think this would be a valuable addition to PHP 5.5.
I think we shouldn't rush with votes on this until all fine details
aren't hashed out. This is a*huge* feature -
On 10/16/2012 02:51 AM, Amaury Bouchard wrote:
2012/10/16 Stas Malyshev smalys...@sugarcrm.com
public DateTime $date;
This is *real* progress, even if under the hood all it does is wrap
I think it's a movement in wrong direction. Again, it is an attempt to
make PHP a strongly typed
Lester,
But a vote NOT to include it should still be one of the options!
No it should not.
Comments like this are not helpful, and are quite destructive. Please stop
running that circle.
As far as the particular implementation goes, I'd vote against it right
now. Not because it's bad, but
2012/10/16 Rasmus Lerdorf ras...@lerdorf.com
The rule in PHP for any sort of type hinting is that it is only done for
non-coercable types. In cases where there is simply no way to recover
from passing the wrong type, it is good to catch it as early as
possible. Extending this to also cover
On Tue, Oct 16, 2012 at 10:31 AM, Amaury Bouchard ama...@amaury.net wrote:
2012/10/16 Rasmus Lerdorf ras...@lerdorf.com
The rule in PHP for any sort of type hinting is that it is only done for
non-coercable types. In cases where there is simply no way to recover
from passing the wrong type,
My choice of words were misleading/incorrect. If you are programming to an
interface then the interface dictates what *will* work, if you attempt to use
an interface to do something that the interface has not declared is supported
then it may work or it may fail.
On Oct 16, 2012, at 7:43 AM,
Stas, go back a few revisions of the RFC and you'll see there used to be
automatically implemented accessors which were voted out. The current RFC does
not reflect the current fork of the code, it did before I modified it with
the consensus from around 10/12 before Nikita brought up some more
Jesus, this is such a CF. Can I not write understandable English?
read-only and write-only ENFORCE UPON SUBCLASSES that no setter or getter
(respectively) can be defined. That's all they do. There is no currently
proposed solution that meets this need.
This NEED was pulled from the original
Is it just me or has this Property Accessors chain of emails been impossible to
make heads or tails of? People replying within replies within replies, quoting
partial emails, cross-posting and all sorts of chaos.
Would anyone be willing to entertain an alternative communication method with
I may sound old fashioned, but what about a forum?
On Wed, Oct 17, 2012 at 3:05 AM, Clint Priest cpri...@zerocue.com wrote:
Is it just me or has this Property Accessors chain of emails been
impossible to make heads or tails of? People replying within replies
within replies, quoting partial
I agree. VBulletin rules. It also permits voluntary participation rather
than getting every email for ever conversation. Should you prefer to get
everything via email, I believe it is possible to sync VBulletin with a
mailing list.
On 10/16/2012 5:18 PM, Yahav Gindi Bar wrote:
I may sound
Personally, I like IP.Board. Put that aside, I thought about PHPBB or
another open-source software :)
On Wed, Oct 17, 2012 at 3:22 AM, J. Adams zardozro...@gmail.com wrote:
I agree. VBulletin rules. It also permits voluntary participation rather
than getting every email for ever conversation.
Yahav Gindi Bar in php.internals (Wed, 17 Oct 2012 03:18:12 +0300):
I may sound old fashioned, but what about a forum?
A forum is new fashioned. I am reading and writing this on news.php.net.
Webinterface: http://news.php.net/php.internals
But you'd better use a proper newsreader. Some browsers
I was thinking more along the lines of a collaborative wiki with
inline-threaded comments...
-Original Message-
From: Jan Ehrhardt [mailto:php...@ehrhardt.nl]
Sent: Tuesday, October 16, 2012 8:00 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Alternatives to mailing list?
On 16/10/12 22:34, Clint Priest wrote:
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property
53 matches
Mail list logo
