Re: [PHP-DEV] [RFC] Property accessors

Hi internals, > > I'd like to present an RFC for property accessors: > > https://wiki.php.net/rfc/property_accessors Hi internals, I am new here. Thank you Nikita for this wonderful proposal. A few days ago, I sent an identical message to this thread but I am not sure it was sent properly. So

Re: [PHP-DEV] [RFC] Property accessors

‐‐‐ Original Message ‐‐‐ On Tuesday, May 4th, 2021 at 6:33 AM, Nikita Popov nikita@gmail.com wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a sin

Re: [PHP-DEV] [RFC] Property accessors

> On May 4, 2021, at 6:33 AM, Nikita Popov wrote: > > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and p

Re: [PHP-DEV] [RFC] Property accessors

Hi internals, I am new here. Let me make a suggestion for this one of mostly asked feature: class MyOldOrdinaryObject { public string $prop1 { get use getProp1; set use setProp1; } public string $prop2 { get use prefixProp2; set use prop2Sufix; } // pre existing me

Re: [PHP-DEV] [RFC] Property accessors

On Tue, May 4, 2021, at 5:33 AM, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and pr

Re: [PHP-DEV] [RFC] Property accessors

On Tue, 4 May 2021 at 06:34, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and proper

Re: [PHP-DEV] [RFC] Property accessors

On 04-05-2021 12:57, Marco Pivetta wrote: > * instead of allowing by-ref `get` declaration, can we just kill it here, > before it breeds again? I don't think I need to explain the woes of by-ref > to internals, but removing the ability to declare new accessors by-ref > would be a huge win for the

Re: [PHP-DEV] [RFC] Property accessors

On 04-05-2021 12:33, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors Wow. Thanks for all the effort you put into this! > While I put a lot of effort into both the proposal and the implementation, > I've grow

Re: [PHP-DEV] [RFC] Property accessors

W dniu 04.05.2021 o 18:32, Marco Pivetta pisze: > I'd strongly advise killing by-ref array push there: it's an acceptable > limitation, for the amount of benefit we get :P > In fact, people doing `__get` now are already familiar with "Indirect > modification of overloaded property" (https://3v4l.or

Re: [PHP-DEV] [RFC] Property accessors

Hey NikiC, On Tue, May 4, 2021 at 4:21 PM Nikita Popov wrote: > On Tue, May 4, 2021 at 12:58 PM Marco Pivetta wrote: > >> Hey NikiC, >> >> On Tue, May 4, 2021, 12:34 Nikita Popov wrote: >> >>> Hi internals, >>> >>> I'd like to present an RFC for property accessor

Re: [PHP-DEV] [RFC] Property accessors

2021-05-04 12:33 GMT+02:00, Nikita Popov : > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and properties wit

Re: [PHP-DEV] [RFC] Property accessors

On Tue, May 4, 2021, at 5:33 AM, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and pr

Re: [PHP-DEV] [RFC] Property accessors

On Tue, May 4, 2021 at 12:58 PM Marco Pivetta wrote: > Hey NikiC, > > On Tue, May 4, 2021, 12:34 Nikita Popov wrote: > >> Hi internals, >> >> I'd like to present an RFC for property accessors: >> https://wiki.php.net/rfc/property_accessors >> >> Property accessors are like __get() and __set(), b

Re: [PHP-DEV] [RFC] Property accessors

2021-05-04 15:57 GMT+02:00, Olle Härstedt : > 2021-05-04 12:33 GMT+02:00, Nikita Popov : >> Hi internals, >> >> I'd like to present an RFC for property accessors: >> https://wiki.php.net/rfc/property_accessors >> >> Property accessors are like __get() and __set(), but for a single >> property. >> T

Re: [PHP-DEV] [RFC] Property accessors

2021-05-04 12:33 GMT+02:00, Nikita Popov : > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties and properties wit

Re: [PHP-DEV] [RFC] Property accessors

Hey NikiC, On Tue, May 4, 2021, 12:34 Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors > > Property accessors are like __get() and __set(), but for a single property. > They also support read-only properties

Re: [PHP-DEV] [RFC] Property accessors

I haven't read it properly yet (been watching a little), but I just wanted to say thanks for the refreshing honesty :) Cheers Joe On Tue, 4 May 2021 at 12:34, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: > https://wiki.php.net/rfc/property_accessors

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

Bringing up this old issue a bit. Nothing was ever said of unset? Should unset be benign? Since unset() is intended to take an action (rather than check on state) shouldn't an invalid unset (one with a guarded property that doesn't have a setter) emit a warning? On 10/30/2012 10:37 PM, Clin

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Am 19.11.2012 16:41 schrieb "Nikita Popov" : > > On Wed, Nov 14, 2012 at 5:24 PM, Patrick Schaaf wrote: > >> class ... { >> no methodname(); >>// or >> no $property; >> } >> > Removing methods from an extending class is an LSP violation. I see LSP as a best practise for class design, not

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Wed, Nov 14, 2012 at 5:24 PM, Patrick Schaaf wrote: > I thought I'd made a proposal that would solve that problem, but maybe it > was > overlooked, or more likely too ugly to be recognized as such. > > Requires a single new feature / syntax, that at least I find missing right > now: > > class

Re: [PHP-DEV] [RFC] Property Accessors v1.2 Consensus Changes

On Mon, Nov 19, 2012 at 1:19 AM, Clint Priest wrote: > Can anyone who has an interest in this project please review over the > "Current Consensus Changes" section of this document: > > https://wiki.php.net/rfc/**propertygetsetsyntax-as-** > implemented/change-requests

Re: [PHP-DEV] [RFC] Property Accessors v1.2 Consensus Changes

On Sun, Nov 18, 2012 at 5:19 PM, Clint Priest wrote: > Can anyone who has an interest in this project please review over the > "Current Consensus Changes" section of this document: > > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests > > Lets hear if there are any other

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Fatal error: Call to private method a::__setb() from context ''... > > Or... > > Fatal error: Cannot set private property a::$b. > > Which makes more sense to the most people? Either of these is fine. I'm not talking about that though. You said: "stack traces, reflection, etc would hide

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Yeah, pretty much. I would not say they are "hidden" from the user, they are simply not revealed purposely. (see example below for reason) It's an irrelevant engine implementation detail. They would simply be callable only because they are actually methods. They are not magic methods becaus

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

*sigh* Which error would make more sense to you Stas... Given this code: class a { public $b { get() { return 5; } private set($x) { /* do something */ } } } $o = new a(); echo $o->b; $o->b = 42; There are two possibilities at this point. The code base, without all

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Wednesday 14 November 2012 16:35:31 Nikita Popov wrote: > On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest wrote: > > Been AWOL for a while and getting back to this, doesn't seem like any > > resolution has occurred, just the conversation has died down. > > I got the feeling that in the last few

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Been AWOL for a while and getting back to this, doesn't seem like any > resolution has occurred, just the conversation has died down. > > I would propose that: > > 1) Internal accessor methods that are defined are callable directly. > 2) Said methods are not reflected or revealed by the e

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest wrote: > Been AWOL for a while and getting back to this, doesn't seem like any > resolution has occurred, just the conversation has died down. > I got the feeling that in the last few mails we actually made some progress and some people agreed with m

RE: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

class? I hope that does not sound aggressive ;) Best regards Christian -Original Message- From: Clint Priest [mailto:cpri...@zerocue.com] Sent: Wednesday, November 14, 2012 2:28 PM To: PHP Developers Mailing List Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Acces

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Been AWOL for a while and getting back to this, doesn't seem like any resolution has occurred, just the conversation has died down. I would propose that: 1) Internal accessor methods that are defined are callable directly. 2) Said methods are not reflected or revealed by the engine (stack trac

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Le 26/10/2012 11:37, Clint Priest a écrit : I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests In the RFC, section "read

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi Stas, hi Etienne, let’s get practical and apply LSP to property accessors. Find below what I would read from the characteristics of LSP. Am 31.10.2012 um 20:46 schrieb Stas Malyshev : [...] >> Instead, LSP simply states that, given B <: A, all objects of A can be >> substituted by objects of

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Well, LSP is typically not applied to program semantics, since this is > not a generally decidable problem. The only post-conditions that LSP > normally enforces is type based, i.e. the covariance of the return > type. Err, I'm not sure where you are taking this from, but LSP is certainly n

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Nikita, your examples convinced me that a strict "accessor methods as specialized __get/__set semantics" approach is undesirable. To recapitulate your two examples: Example 1: class A { public $foo; } class B extends A { public $foo { get() { ...} } } Example 2: class A { public $foo {

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi, On Wed, Oct 31, 2012 at 12:16 AM, Stas Malyshev wrote: > Hi! > >>> I'm not sure why you are expecting this, and also this is probably an >>> LSP violation, since such override would change semantics of the value >>> that A clients expect. It may be possible to implement, technically, but >>>

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

Would you say the same of unset? Always benign? On 10/29/2012 2:14 PM, Stas Malyshev wrote: Hi! So... to be explicit here, you think in this situation: class a { public $b { set($x) { $this->b = $x; } } } $o = new a(); if(!isset($o->b)) { /* delete files */ } echo (int)

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! >> I'm not sure why you are expecting this, and also this is probably an >> LSP violation, since such override would change semantics of the value >> that A clients expect. It may be possible to implement, technically, but >> I'm not sure it's the right thing to do. > > Why would it be not ex

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev wrote: > Hi! > >> Stas, you seem to have missed the point behind my mail. This wasn't >> about what the exact details of the implementation will be, the >> message was that the semantics of a dedicated accessors syntax and the >> semantics of a magic

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Stas, you seem to have missed the point behind my mail. This wasn't > about what the exact details of the implementation will be, the > message was that the semantics of a dedicated accessors syntax and the > semantics of a magic implementation can not match. I see your point now, thanks, b

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

There are still use cases for __get(), when the list of internal properties is dynamic. We're actually leveraging that for Drupal 8's entity system. Removing it would be a big problem. :-) But that still doesn't resolve the mental model question. --Larry Garfield On 10/30/12 3:05 AM, Ferenc

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

I would say that the proposed accessors is what we should have added back then instead of __get/__set . The problem is that now we will have two similar (albeit one is an ugly subset of the other) feature which needs to co-exists. My gut tells me that we should ditch the magic method approach with

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Mon, Oct 29, 2012 at 10:56 PM, Stas Malyshev wrote: > Hi! > >> If I got it right now, what Stas wants is that we introduce __getFoo >> and __setFoo methods that will be called whenever an undefined ->foo >> property is accessed and that the "normal" property accessors syntax >> is made nothing

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > If I got it right now, what Stas wants is that we introduce __getFoo > and __setFoo methods that will be called whenever an undefined ->foo > property is accessed and that the "normal" property accessors syntax > is made nothing more than a fancy notation for this. Yes, pretty much, though

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

Hi! > Is there another class of error that would make more sense? Don't most > people turn off E_NOTICE errors? Perhaps emit an E_STRICT? I always run with E_NOTICE in development, that's kind of what E_NOTICE is for :) I don't think isset() should produce any warnings/notices - this is how it

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

Hi! > So... to be explicit here, you think in this situation: > > class a { >public $b { > set($x) { $this->b = $x; } >} > } > > $o = new a(); > > if(!isset($o->b)) { >/* delete files */ > } > echo (int)isset($o->b); /* This should return false and not emit any > sort of war

RE: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

> -Original Message- > From: Clint Priest [mailto:cpri...@zerocue.com] > Sent: 28 October 2012 16:03 > > So... to be explicit here, you think in this situation: > > class a { >public $b { > set($x) { $this->b = $x; } >} > } > > $o = new a(); > > if(!isset($o->b)) { >/*

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

That's pretty fair, that last statement... As far as an application is concerned $o->b doesn't exist because it can't be read. Seems as though some developers are going to want to know when they've tried to violate it though... I dunno. Personally I would consider it error or warning worthy b

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

On 29/10/12 03:02, Clint Priest wrote: So... to be explicit here, you think in this situation: class a { public $b { set($x) { $this->b = $x; } } } $o = new a(); if(!isset($o->b)) { /* delete files */ } echo (int)isset($o->b); /* This should return false and not emit any sort of w

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

See, I'm not convinced that "everyone would agree that #1 [just some syntax candy] is definitely not right". From the discussion here, it seems like some are still thinking of it that way. If they are supposed to be a 3rd thingie, and the only relation to data members as we've known them is t

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Sun, Oct 28, 2012 at 4:50 PM, Clint Priest wrote: > On 10/28/2012 2:04 AM, Stas Malyshev wrote: >> >> Hi! >> >>> Stas, you should probably do some research before posting such non-sense: >> >> Which part is "non-sense"? I've brought you examples of Python and Ruby >> not doing exactly what you

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

Well I guess this and many of the other issues from other threads are the reasons I had it written the way that it is currently (basically an extension of __get()) but numerous other proposals have muddied the situation. On Sunday, October 28, 2012 2:17:47 AM, Stas Malyshev wrote: Hi! Sorry

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

So... to be explicit here, you think in this situation: class a { public $b { set($x) { $this->b = $x; } } } $o = new a(); if(!isset($o->b)) { /* delete files */ } echo (int)isset($o->b); /* This should return false and not emit any sort of warning/notice? */ I mean specifically,

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On 10/28/2012 2:04 AM, Stas Malyshev wrote: Hi! Stas, you should probably do some research before posting such non-sense: Which part is "non-sense"? I've brought you examples of Python and Ruby not doing exactly what you claim all languages are doing. By your definition, they don't have access

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Stas Malyshev wrote: By accessors I am simply referring to getters, setters (and in the case >of php, issetter and unsetter). I wish it was so, but it was mentioned many times in this discussion that "accessors should be accessors" and that only the situation where accessors are special function

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

hi Clint, On Sat, Oct 27, 2012 at 7:39 PM, Clint Priest wrote: > That's basically what #2 is getting at, my only question is, emit a warning > or notice or not? > > Technically returning false on an invalid isset() call could be misleading > without emitting some kind of notice or warning about i

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

Hi! > Sorry I guess I should have been more clear. The recursion would > prevent the accessor from being called which would allow the ordinary > property code to execute, thus accessing the property directly. I This could lead to weird scenarios where the same $foo->bar in random function co

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Am 28.10.2012 02:42 schrieb "Clint Priest" : > > Sounds like you're implying that the mere existence of a properly named function such as __prop_get_hours() would cause it to be called instead of returning the property. Only when the property does not exist, just like it is with __get > 1) Curren

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Stas, you should probably do some research before posting such non-sense: Which part is "non-sense"? I've brought you examples of Python and Ruby not doing exactly what you claim all languages are doing. By your definition, they don't have accessors - as you define accessors as hidden metho

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > 1) Currently __get() is only checked/invoked if there is not a property > already defined; ie properties shadow __get() (no performance penalty) Yes, that's kind of the point of it - extending __get. > 2) It would dramatically reduce performance because every property > access would have

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hey Larry, Glad you chimed in here on this. I my opinion (author of thingy), they are separate and distinct from data members. More specifically they are getter and setter code that is called when the property is accessed. Using your example: echo $obj->baz; // executes the code "return $t

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On 10/27/2012 09:38 PM, Larry Garfield wrote: On 10/26/2012 05:37 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemente

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

On 10/26/2012 05:43 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests -

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On 10/26/2012 05:37 AM, Clint Priest wrote: I'm opening up several new threads to get discussion going on the remaining "being debated" categories referenced in this 1.1 -> 1.2 change spec: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests -

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Stas, you should probably do some research before posting such non-sense: http://en.wikipedia.org/wiki/Property_%28programming%29 Every language you mentioned has them. Perhaps the confusion is that I am calling them accessors since other languages refer to accessors as "properties" while PHP

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Sounds like you're implying that the mere existence of a properly named function such as __prop_get_hours() would cause it to be called instead of returning the property. There are several problems with this approach: 1) Currently __get() is only checked/invoked if there is not a property alr

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

Sorry I guess I should have been more clear. The recursion would prevent the accessor from being called which would allow the ordinary property code to execute, thus accessing the property directly. I suppose if it were in a setter and the property were not defined by the accessor then it wou

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > What is "reflection hiding patches" referring to? Reflection is changed > to reflect what the user has defined, that's what reflection is supposed > to be.. no? No. Reflection is supposed to show which methods exist on a class, which can be called from certain context, etc. This has noth

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > That's why I think they shouldn't even be visible to users, they aren't > relevant to them and in fact it could mis-lead them into thinking that > they could simply define __getHours() and expect $foo->Hours to call > it, which it wouldn't. I think it should. That's how __get works. --

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

Hi! > Recursion is guarded by the same mechanism __get uses to avoid recursion. __get on recursion returns undefined, __set on recursion does nothing. However you're saying "No direct access to the property would be allowed except from within the accessor" - but what this not allowing means? Just

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Saturday 27 October 2012 13:05:27 Clint Priest wrote: > That's why I think they shouldn't even be visible to users, they aren't > relevant to them and in fact it could mis-lead them into thinking that > they could simply define __getHours() and expect $foo->Hours to call > it, which it wouldn't.

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On 10/26/2012 6:37 PM, Stas Malyshev wrote: Hi! Stas, if you define an accessor, how do you define it? Do you say Either way, doesn't matter. According to the current proposal at least you can write the first code *and the first code only*. If you write the second code then you That's wher

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

That's why I think they shouldn't even be visible to users, they aren't relevant to them and in fact it could mis-lead them into thinking that they could simply define __getHours() and expect $foo->Hours to call it, which it wouldn't. To me, the bottom line is, the fact that there are methods

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

On 10/26/2012 9:39 AM, Stas Malyshev wrote: Hi! /* Would be equivalent to this */ class TimePeriod { public $date { get() { return $this->date; } set(DateTime $value) { $this->date = $value;} } } I don't think this has a use case and this encourages mixing var

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

That's basically what #2 is getting at, my only question is, emit a warning or notice or not? Technically returning false on an invalid isset() call could be misleading without emitting some kind of notice or warning about it. On 10/26/2012 9:56 AM, Stas Malyshev wrote: Hi! 1. If al

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

Recursion is guarded by the same mechanism __get uses to avoid recursion. On 10/26/2012 9:33 AM, Stas Malyshev wrote: Hi! v1.2 Proposes that this be inverted such that if there is an accessor defined for a given property name, the accessor will always be used. The accessor would be able to get

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

> > - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on. > > I think it'd more natural to make it __set__PROPNAME. Though __set_state > is a static method, so maybe we can live with it - except that you won't > be able to declare property named $_state. Needing an "except" is inelegant, if

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Stas, if you define an accessor, how do you define it? Do you say Either way, doesn't matter. > According to the current proposal at least you can write the first > code *and the first code only*. If you write the second code then you That's where I think it is wrong. It would be much sim

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Fri, Oct 26, 2012 at 10:34 PM, Stas Malyshev wrote: > Hi! > >> users control. Actually, both approaches are exactly the same, the >> only difference is whether we additionally put the accessor function >> into the method table or whether we do not. > > They may be almost the same technically, b

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > an accessor setter method for a property $_state IF that method would > follow the __set$PROPNAME pattern. As a solution for that, I'd propose > naming the new magic methods with a so-far-not-taken common prefix: __prop > - i.e. name them __prop_get_xxx, __prop_set_xxx, and so on. I think i

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > users control. Actually, both approaches are exactly the same, the > only difference is whether we additionally put the accessor function > into the method table or whether we do not. They may be almost the same technically, but very different conceptually. Your approach means we introduce

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Fri, Oct 26, 2012 at 4:14 PM, Stas Malyshev wrote: > Hi! > >> Some people are in favor of the internal functions being generated by an >> accessor declaration should be invisible and non-callable directly. >> Others are in favor of leaving them visible and callable. > > I think these types are

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

Hi! > I just have one question: can we drop `public`? Default visibility in We already had var, it didn't prove a good idea. PHP is explicit for a reason, to be clear. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Run

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

I'm all for having the "internal" methods being totally normal magic methods, for the reduced complexity reasons already mentioned. I would also expect to be able to simply define such a magic method myself, and have it behave in just the same way as when defining it using the accessor declaration

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

> > *Extra shorthand declaration* > > Allow extra short declaration of an accessor: > > class TimePeriod { > public DateTime $date; > } > > /* Would be equivalent to this */ > > class TimePeriod { > public $date { >

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"

Hi! > 1. If all cases can be tested for during compilation, prefer > compile failures. Not likely. isset($foo->$bar) is completely opaque since we don't know what $foo or $bar is. > 2. Let the compilation occur and at runtime when a disallowed > action is attempted, emit a wa

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

Hi! > /* Would be equivalent to this */ > > class TimePeriod { > public $date { > get() { return $this->date; } > set(DateTime $value) { $this->date = $value;} > } > } I don't think this has a use case and this encourages mixing variables with properties (which I'm no

Re: [PHP-DEV] [RFC] Property Accessors 1.2 : Shadowing

Hi! > v1.2 Proposes that this be inverted such that if there is an accessor > defined for a given property name, the accessor will always be used. The > accessor would be able to get/set/isset/unset the property with the same > name as the accessor. No direct access to the property would be all

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

Hi! > Some people are in favor of the internal functions being generated by an > accessor declaration should be invisible and non-callable directly. > Others are in favor of leaving them visible and callable. I think these types are not right. It has nothing to do with internals/userland, it ha

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On 10/26/12 6:37 AM, Clint Priest wrote: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests Some people are in favor of the internal functions being generated by an accessor declaration should be i

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor MethodVisibility / Callability

On 26-10-2012 12:37, Clint Priest wrote: Some people are in favor of the internal functions being generated by an accessor declaration should be invisible and non-callable directly. Others are in favor of leaving them visibl

Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Extra shorthand declaration

Is the only intended benefit behind this proposal the ability to seamlessly extend a seemingly normal property as an accessor? On Fri, Oct 26, 2012 at 3:43 AM, Clint Priest wrote: > I'm opening up several new threads to get discussion going on the > remaining "being debated" categories reference

RE: [PHP-DEV] [RFC] Property Accessors v1.1

Each time I've posted the RFC for review more has come up so I suppose at this point it needs to go through a waiting period on further comments and then in 2 weeks? > -Original Message- > From: Paul Dragoonis [mailto:dragoo...@gmail.com] > Sent: Monday, October 08, 2012 7:50 AM > To: