Yes, the two proposals can definitely work together. See my initial message:
class A {
// $str has public reading and private writing,
// and manage french quotes
public:private $str {
get { return "«" . $this->str . "»"; }
set { $this->str = tri
On 7/23/12 12:38 PM, "Amaury Bouchard"
mailto:ama...@amaury.net>> wrote:
2012/7/23 André Rømcke mailto:andre.rom...@ez.no>>
I think these two proposals can be synced up, what if:
public readonly $a;
Is shorthand for:
public $a { get; protected set; }
And when no function is defined,
2012/7/23 André Rømcke
> I think these two proposals can be synced up, what if:
>
> public readonly $a;
>
> Is shorthand for:
>
> public $a { get; protected set; }
>
>
> And when no function is defined, no function overhead is added.
>
Well, this code:
public read-only $a;
introduces
On 7/16/12 5:29 PM, "Nikita Popov" wrote:
>On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard
>wrote:
>> Yes, but only if you have to write an accessor.
>> If you just want an attribute that is:
>> - readable from everywhere
>> - writable from the current class only
>>
>> With my syntax:
>> p
Thank you Matthew. I had the feeling that my proposal was dismissed a bit
quickly by some people, while I think it's how object-oriented languages
should handle attributes' visibility.
I still think it's very simple and elegant, and more coherent in some
situations (those situations targeted by the
On 2012-07-16, Andrew Faulds wrote:
> An ugly, confusion-causing syntax.
I'm sorry, but how does this add _anything_ to the discussion?
Qualify your statement, please. What do you find "ugly" about the
syntax, and why? Where do you see confusion arising from the syntax -
what problems do you for
On 2012-07-16, Amaury Bouchard wrote:
> --f46d0446312cc5e06104c4f42161
> Content-Type: text/plain; charset=ISO-8859-1
>
> My point is not to add two ways to do the same thing.
> What I'm humbly suggesting to do is to keep the core idea of the
> existing RFC (make things easier when you have to wri
That is already accounted for, both the visibility (what's inside
limits what's before the variable) as well as changing the
write-only/read-only options. If you read the RFC, when extending a
class and adding "set" method to a member that was read-only, you
overload the read-only setting...
Hence
Are you sure that this mix of distributed visibilities (sometimes before
the attribute, sometimes before a "get" or "set" keyword) and new keywords
("read-only" and "write-only", between the initial visibility and the
attribute itself; but what is an "initial visibility" exactly?) is really
more cl
On Mon, Jul 16, 2012 at 4:31 PM, Amaury Bouchard wrote:
> My point is not to add two ways to do the same thing.
> What I'm humbly suggesting to do is to keep the core idea of the existing
> RFC (make things easier when you have to write getters/setters), and think
> about another syntax for managi
My point is not to add two ways to do the same thing.
What I'm humbly suggesting to do is to keep the core idea of the existing
RFC (make things easier when you have to write getters/setters), and think
about another syntax for managing reading and writing visibilities.
2012/7/16 Andrew Faulds
> If you just want an attribute that is:
> - readable from everywhere
> - writable from the current class only
I believe the RFC sugests:
public $a {
private set;
}
Would be enough, if I understand correctly...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard wrote:
> Yes, but only if you have to write an accessor.
> If you just want an attribute that is:
> - readable from everywhere
> - writable from the current class only
>
> With my syntax:
> public:private $a; (read it aloud "public reading, pri
How much syntactic sugar do we really need? Why add two ways to do something?
On 16 July 2012 16:24, Amaury Bouchard wrote:
> 2012/7/16 Nikita Popov
>
>> I'm not sure I really understand what this adds over the existing
>> getter/setter proposal. read-only and write-only should cover the most
>>
You already have the read-only/write-only option proposed on that RFC
- by not defining set and vice-versa for write only - or by inserting
new keywords (not sure if this is needed/optimal).
And nowhere in PHP do we have the syntax you propose as A:B, and I
even recall a short array [a:1, b:2] syn
2012/7/16 Nikita Popov
> I'm not sure I really understand what this adds over the existing
> getter/setter proposal. read-only and write-only should cover the most
> common cases. If you do need visibility control, it is possible too:
>
> public $property {
> get { ... }
> protected set {
An ugly, confusion-causing syntax.
On 16 July 2012 14:11, Nikita Popov wrote:
> On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard wrote:
>> Hi,
>>
>> Here is an RFC proposal about a syntax extension for PHP. The purpose is to
>> manage precisely the visbiliy of attributes, by separating reading a
On Sun, Jul 15, 2012 at 5:46 PM, Amaury Bouchard wrote:
> Hi,
>
> Here is an RFC proposal about a syntax extension for PHP. The purpose is to
> manage precisely the visbiliy of attributes, by separating reading and
> writing access.
>
> First of all, I know there is already an RFC about attributes
2012/7/15 Brandon Wamboldt
> This seems pretty useful, but could technically be accomplished using the
> get/set syntax already proposed. Obviously this is a cleaner implementation
> however.
As I said, the get/set syntax RFC propose a "read-only" and a "write-only"
keywords.
For example, it wi
This seems pretty useful, but could technically be accomplished using the
get/set syntax already proposed. Obviously this is a cleaner implementation
however.
On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard wrote:
> Hi,
>
> Here is an RFC proposal about a syntax extension for PHP. The purpose
20 matches
Mail list logo
