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 Accessor
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?
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
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 wrote:
> I agree. VBulletin rules. It also permits voluntary participation rather
> than getting every email for ever conversation. Should you prefer to
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 ol
I may sound old fashioned, but what about a forum?
On Wed, Oct 17, 2012 at 3:05 AM, Clint Priest 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 emails, cross-post
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
s
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 origina
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 mo
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, "
On Tue, Oct 16, 2012 at 10:31 AM, Amaury Bouchard wrote:
> 2012/10/16 Rasmus Lerdorf
>>
>> 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 ea
2012/10/16 Rasmus Lerdorf
> 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 scalar coercable
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 bec
On 10/16/2012 02:51 AM, Amaury Bouchard wrote:
> 2012/10/16 Stas Malyshev
>
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, w
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 Oct 16, 2012 11:27 AM, "Stas Malyshev" 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 all fine
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 sti
2012/10/16 Clint Priest
> 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.
public:const $a
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 compl
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
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 proper
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
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
unwarrante
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() { … }
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, al
> -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!
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. Th
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
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 you
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 co
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
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!
> 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
2012/10/16 Stas Malyshev
> 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 object properties
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 th
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 thankfu
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
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 acc
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
solut
In regards to #11, yes, you'd just write {}. I imagine you could also just
throw an exception. Maybe an exception could be thrown automatically if
there is no code between the braces. Though this doesn't really directly
relate to providing the ability to disable get/set in an accessor.
The only cl
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 b
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 b
2012/10/16 Stas Malyshev
> >> 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
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 impl
#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 no
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 t
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
> I prefer the current syntax to your proposal because:
>
> 1) It is not at all obvious which side is which. Example:
> *prot
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
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
> acc
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!
> 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!
>> 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 e
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) Ther
2012/10/15 Clint Priest
> 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 it would fa
54 matches
Mail list logo
