Re: [PHP-DEV] supporting the final keyword for properties
2013/5/28 Sebastian Krebs > > And in your example you have to know, that you are "manipulating" a > variable :? > > Sure. But my example's goal was to show the idea of Lars. Using the "final" keyword on variables would allow to manipulate variables and "constant variables", without the need to know if it's a variable or a constant (obviously because they are all variables). Not my idea, I was just explaining.
Re: [PHP-DEV] supporting the final keyword for properties
2013/5/28 Sebastian Krebs >print($$b); >> > > print(constant($b)); > It's definitely different. In your example you have to know that you are manipulating constants only.
Re: [PHP-DEV] supporting the final keyword for properties
2013/5/28 Maciek Sokolewicz > It’s a good idea in general but what about having it for variables as >> well? Could open interesting possibilities for an optimizer. >> >> final $foo = "str"; >> $foo = "bar"; // bails out >> >> Don't we already have that? It just has a different name: constants. It's different. You can manipulate variables in some ways you can't with constants. This code, for example: $a = 'abc'; $b = 'a'; print($$b); It will display "abc". It's currently not possible to do something similar with constants. I think the subject was already debated, but I wonder why we should write that: final $foo = 'bar'; instead of: const $foo = 'bar';
Re: [PHP-DEV] Continued try blocks
2013/4/29 Stas Malyshev > I agree. If your code can handle the problem, it should not throw. If it > throws, the control should not go back there, since the code already > gave up and declared it can not continue doing whatever it was doing. > Exceptions are meant to handle exceptional situations, not serve as a > kind of goto with objects, IMO, and if the code threw an exception, it > should be done. > It's a point of view, not something the language should enforce. You may have a lib/object/chunk of code which raises exceptions, because its developer thought some error is not recoverable; but when you use it, you don't want to break your program's execution. It happens.
Re: [PHP-DEV] Continued try blocks
Why not. But it will come in addition to "resume", not instead of it.
Then:
- "resume" => continue execution just after the point where the exception
was raised.
- "restart" => restart the whole try block.
I don't understand the meaning of your "rollback".
2013/4/29 Camilo Sperberg
>
> On Apr 28, 2013, at 17:27, Julien Pauli wrote:
>
> > On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard
> wrote:
> >
> >> 2013/4/27 Ferenc Kovacs
> >>
> >>> please don't reuse the continue keyword for it.
> >>>
> >>> There are a bunch of code out there where which uses exceptions in a
> loop
> >>> context.
> >>> For example you have a retry counter decremented in a loop and you
> catch
> >>> the exceptions and retry until the retry limit is reached.
> >>>
> >> Fair enough. We can use "resume".
> >>
> >
> > "continue" is just a keyword (syntactic sugar) we sure can change, I like
> > "resume" yes :-)
> >
> > Julien.Pauli
>
> And how about a restart instead of resume? I have used try catch blocks as
> a type of transactional block, so I think it would be nice if I could
> restart the entire block instead of resuming from the last point where it
> failed:
>
> $blue = 'blue';
> try {
> $data = a($blue);
> b($data); // This throws the dataIntegrityException
> c();
> } catch (dataIntegrityException $e) {
> $blue = 'is the new red';
> restart; // executes a(), b() and c() again
> } catch (Exception $e) {
> rollback();
> }
>
> Greetings.
Re: [PHP-DEV] Continued try blocks
2013/4/27 Daniel Macedo > Sorry but I disagree, I think you're approaching try-catch wrong. > > You shouldn't have a try-catch that *can* continue on the next line after > the throw. > What you should do is have decoupled code that handles _their own > exceptions_ nicely and either cleans up after itself else it rethrows the > exception/a new one. > > Any top level try-catch is supposed to be a control structure with one of > two chances: either lines 1-N go smoothly and no exceptions are thrown, or > Exception_X is thrown and you clean up on it's catch block... > It's an opinion, a software engineering choice. Not something that must be enforced by the language. It could be very useful in some situations, not all the time (as traits, for example). Ideally, every errors (in fact, any abnormal situation) should raise an exception, right? OK, but that doesn't mean that any abnormal situation should be able to break execution flow, with no other solution than writing more code. Also remember that you have the finally block. > Can you explain how the finally block can help in my example?
Re: [PHP-DEV] Continued try blocks
2013/4/27 Ferenc Kovacs
> please don't reuse the continue keyword for it.
>
> There are a bunch of code out there where which uses exceptions in a loop
> context.
> For example you have a retry counter decremented in a loop and you catch
> the exceptions and retry until the retry limit is reached.
>
Fair enough. We can use "resume".
try {
doThis();
doThat();
} catch (NotImportantException $nie) {
addToLog($nie->getMessage());
resume;
} catch (Exception $e) {
cleanupEverything();
}
Re: [PHP-DEV] Continued try blocks
2013/4/26 Andreas Heigl
> try {
> $foo = $bar->getObject();
> $foo->doSomething()
> } catch(Exception $e) {
> continue // Or whatever shall be used
> }
>
> When $bar->getObject throws an Exception no $foo is set. So the next
> line will result in a "PHP Fatal error: Call to a member function
> doSomething() on a non-object".
>
That's fine to me.
It's a software engineering problem you can solve easily:
try {
$foo = $bar->getObject();
$foo->doSomething();
} catch (ObjectCreationException $oce) {
add_to_log('Unable to create object');
throw $oce; // or do something else,
// or just do nothing to exit from the try/catch block
} catch (Exception $e) {
add_to_log($e->getMessage());
continue;
}
The getObject() method should raise an ObjectCreationException, while the
doSomething() method could raise any other type of exception.
It's just a natural and smart way to use exceptions.
It could be solve differently:
try {
$foo = $bar->getObject();
$foo->doSomething();
} catch (NotImportantException $nie) {
add_to_log($nie->getMessage());
continue;
} catch (Exception $e) {
add_to_log($e->getMessage());
throw $e; // or do something else,
// or just do nothing to exit from the try/catch block
}
If an expression raises a NotImportantException, it will not interrupt the
execution flow.
Re: [PHP-DEV] Continued try blocks
I will answer, as the idea came from Pierrick Charron and I :-)
Sometimes, you call functions (or methods) and you know they can throw some
exceptions. But you don't want to stop all computations just because one of
them raised an exception. Maybe you just want to log it, and go to the next
call.
If you write that:
try {
$o->method1();
$o->method2();
$o->method3();
} catch (Exception $e) {
add_to_log($e->getMessage());
}
If method1() raises an exception, it's not possible to execute method2().
And so it forces us to write ugly code like that:
try {
$o->method1();
} catch (Exception $e) {
add_to_log($e->getMessage());
}
try {
$o->method2();
} catch (Exception $e) {
add_to_log($e->getMessage());
}
try {
$o->method3();
} catch (Exception $e) {
add_to_log($e->getMessage());
}
But honestly, nobody uses a try/catch block for every single line of code!
Unfortunately, it's sometimes the only solution...
What I'm suggesting is to be able to continue the code execution, from to
point where an exception was raised.
try {
$o->method1();
$o->method2();
$o->method3();
} catch (Exception $e) {
add_to_log($e->getMessage());
continue;
}
In this example, if method1() raises an exception, it will be logged, and
then method2() will be called.
If method2() raises an exception, it will be logged, and then method3()
will be called.
Is method3() raises an exception, it will be logged, and the execution will
continue after the try/catch block.
"continue" is the best keyword for that: The meaning is "please, continue
the execution of my code" :-)
As Julien said, there is a BC break, when a try/catch block is written
inside a loop. But I think it's not a major usage, and it's a minor
inconvenient.
Amaury
2013/4/26 Patrick Schaaf
> On Friday 26 April 2013 16:41:17 Julien Pauli wrote:
>
> > *try {*
> > * foo();*
> > * bar();*
> > * baz();*
> > *} catch (SomeException $e) {*
> > *dosomestuff();*
> > *continue; /* Here is the feature, go back to try block */*
> > *} catch (Exception $e) {*
> > *dosomething();*
> > *}*
> >...
> > So, in this example, if, say, bar() throws a SomeException , the code
> > would then resume and execute baz() after the catch block.
>
> What exactly would it "continue" with?
>
> The next instruction after whereever the "throw" was?
>
> The toplevel function call (or other code) next after the toplevel
> function in
> the try block that threw up?
>
> The first answer won't work because any object live when bar() threw but
> only
> referenced in the call stack below the try block, will already have been
> destructed.
>
> The second answer appears ... semantically dubious.
>
> best regards
> Patrick
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Re: Was Reflection annotations reader - We Need A Vision
2013/1/11 dukeofgaming > I have a question, maybe it is dumb: why not those opposed to using > annotations just... refrain from using them? > As I said in a previous message: « (...) providing annotations as it is proposed will make them a core feature of the language. It will be perceived like objects, exceptions, interfaces or visibility. And the direct impact is that PHP will be seen as a more complex language. A really. More. Complexe. Language. » The discussion is not about how to put every single programming concept inside PHP, and then choose if we want to use them or not. It's about choosing which programming concepts would fit well in PHP. If annotations means a new language in the language, it's questionable (from the end-user point of view as well as for technical reasons in PHP's core). Horizontal reusability (traits) hasn't this problem.
Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
2013/1/10 Rafael Dohms > In my humble opinion, if your only "argument" is a -1, the don't be part of > the discussion, but rather be a vote when (and if) the RFC goes to a vote. > > There are 2 moments to express yourself: the discussion, the vote. > > In the discussion phase I believe opinion should be expressed with solid > concerns. Performance issues, bad syntax, is it relevant or not, etc. > A simple "i don't like it" does not add, so it can be ommited. > «is it relevant or not» => If I can't express my dislike, how can I say that I think something is not relevant? Sorry, but if something seems not good for PHP, any of us should share his thoughts. Because it is pointless to work on RFCs and to write patches if everybody agreed that the functionality is not needed. Discussions are not here just to push new functionalities as far as possible, without arguing if we need them or not, waiting for the vote to be the last safeguard. Well, it's my humble opinion. 2013/1/10 Tyler Sommer > Annotations are already a part of PHP. They are widely used in one of the > most prolific frameworks, Symfony, and it's ORM "counterpart" Doctrine. > Both of which are serious drivers of the PHP community. It's > even potentially spreading to Zend Framework: > > http://zend-framework-community.634137.n4.nabble.com/Annotations-own-implementation-or-Doctrine-Commons-td4655427.html > > To say "they shouldn't be part of PHP" is fine, but it's too late for that. > Annotations are already here. Are we going to just ignore this fact and > hold back what a very significant portion of the community wants to see > because it conflicts with some ambiguous master plan for PHP? > Last summer, I heard a talk from Rasmus. He was presenting what's new in PHP. I remember there was something (I don't remember what exactly, sorry) that seems a bit useless. Roughly speaking, Rasmus said that this kind of functionality will not be used by everybody, but the guys who are writing frameworks will love it. This kind of evolution is fine. No problem to add things inside PHP, even if they will be used by few people, as long as it will not change anything for the rest of us. When PHP went OO, I guess everybody agreed. We knew that, from this point, PHP programming will deeply change, because new extensions will be object oriented; but it was not a problem. Yes, object programming became the new proper way to code in PHP, but it was still possible to do without it. When PHP5 went deeply OO, it was not a problem either. Yet it was the beginning of new changes. For example, if I want to use SPL, I will surely have to use objects, interfaces and exceptions. But nobody is forced to do this. When traits came in PHP, again it was not a problem. You can use it, but it's not an obligation. And it doesn't change how everybody should code. There is multiple problems with annotations: - It's a language in the language. A new syntax to learn. It's not in the code, but without it the code have fat chance to work anymore. - It's a parser in the parser. More code to maintain inside PHP engine. Maybe some performance issues. - More important, providing annotations as it is proposed will make them a core feature of the language. It will be perceived like objects, exceptions, interfaces or visibility. And the direct impact is that PHP will be seen as a more complex language. A really. More. Complexe. Language. Yes, I know that C# has a lot of good ideas. But I also know that C# is not seen as flexible and "teach-me-how-to-code-I-will-use-you-professionally" as PHP. It's true that annotations are already used by frameworks and ORM. But it is their choices, and usually annotations are one of many possibilities to configure code-related stuff. Annotations are not seen as the right way of writing PHP code just because annotations are used by Symfony and Doctrine. But if you put them inside the core of PHP, annotations will gain this status. And I don't know what to say except "I don't like it". One last thought about the "PHP is not Java" thing. Anthony is bored by that. OK. But maybe it's not totally pointless. Many stuff were taken from Java, in the PHP's OO model. OK. The generator concept came from Python. OK. There is some interresting things in many other languages (Ruby, Lua). I guess it's OK to take inspiration from them. When the "yield" keyword appeared, I don't remember anything like "PHP is not Python". Why? Because it's a cool new feature, but it doesn't change PHP behaviour. Annotations are maybe too much for PHP; on the wrong side of the line. Yes, I know, the line is not defined, but still.
Re: [PHP-DEV] Was Reflection annotations reader - We Need A Vision
2013/1/9 Anthony Ferrara > Stas, > > Would you shut up with this rhetoric already? All it does is show that > you're completely and utterly out of touch with the reality of modern > development. > > Frankly, I'm getting sick and tired of seeing these recurring themes of > "PHP is not java" and "I never want this". If you never want this, then > don't contribute to the discussions at all. > What's the point? If only those who agree can talk, I'm not sure about the result... If Stas doesn't like the proposed syntax, how can he express his dislike in a sufficiently positive manner? (it's a honest candid question; I'm asking it even after receiving nice and harsh responses to my patch proposal last summer) > PHP NEEDS a vision. Rasmus' answer was about balance. I guess it's hard to strongly define what a language should be; there is no drawable line. Each step is questionable in some way, This balance is the strength of PHP, the root of its flexibility. But I totally understand your frustration.
Re: [PHP-DEV] Generics proposal
Nobody wants to turn PHP into Java. But, even if I agree for generics (or templates), I would like to know where is the border line. Classes, exceptions, interfaces, traits, type hinting in parameters => OK Type hinting in object properties, type hinting of returned values, type templating => KO? Maybe we'd save time if it was clearly defined (and accept my apologies if it was already defined somewhere). 2012/10/21 Stas Malyshev > Hi! > > > Hello, list. I want to propose generics. > > Please no. If you need Java, you know where to find it. Java has a set > of great tools, great books, great community. And it's completely free. > Anybody who needs Java can just do it. I see no need to turn PHP into Java. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
I don't disagree (sure, I campaigned to remove the "read-only" keyword). But "not writable" is still different from "private writing". Should we loose any of these meanings? 2012/10/21 Clint Priest > I think that seems to be the consensus at this point, anyone disagree? > > > -Original Message- > > From: Levi Morrison [mailto:morrison.l...@gmail.com] > > Sent: Sunday, October 21, 2012 10:26 AM > > To: Amaury Bouchard > > Cc: Nikita Popov; Clint Priest; internals@lists.php.net > > Subject: Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords > > > > > If for some reason you need to enforce that nobody inherits it and > > > sets the property, then declaring a setter and issuing an error or > > > exception would suffice. > > > > I meant to say declaring a `private or final setter`. Noticed that > after I sent it. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
2012/10/21 Levi Morrison > I would like to point out that in my mind `const` and `read-only` are > not necessarily the same thing. Read-only means that from outside the > class it cannot be modified; the internal class can change it whenever > it wants. Const means that once the value is set it will NEVER change. > Big difference. > "read-only" means that it is only readable. Like const. If the internal class can change it, you are defining writing visibility (as private or protected). Yes, it is different. Visibility has far more meaning than just saying it's a constant value. In fact, "read-only" is a sub-case of usual visibility management.
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
2012/10/20 Derick Rethans > There is nothing wrong with being verbose. PHP has always been verbose, > which IMO is a strong point of the language as it makes everything a lot > easier to search for. > There is a confusion between being verbose and being explicit. PHP syntax is explicit. Verbosity is not a goal.
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
2012/10/20 Nikita Popov
> Could you maybe explain where exactly "const" would be used?
>
Well "const" and "read-only" have the exact same meaning. You can replace
one by the other. So why create a new keyword?
> Please
> don't forget that we do not use your "foo:bar" syntax, so where would
> the "const" go with the currently used syntax?
>
Don't be rude. It's not a "foo:bar" syntax sent no matter how on this
mailing-list. It was an argumented RFC proposal, with an associated patch
(but yeah, who cares?).
If you want to give it a silly nickname, I'd prefer "public:private". :-)
The RFC was:
public read-only $a {
get { return $this->_a; }
}
It could be:
public const $a {
get { return $this->_a; }
}
Is it so different that it needs a new keyword?
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); 2012/10/20 Clint Priest > Hey everyone, seems like the conversations have died down and I've > attempted to go back through all of the emails and produce a 1.1 -> 1.2 > document which summarizes what I believe are decided, being debated, > issues, todos, etc. > > Pierre had pointed out that I had partially changed the "as-implemented" > document which no longer reflected what the fork implements. So... I have > reverted that document to the 1.1 version. > > For the TODO items I will start to tackle those which are not dependent > upon some undecided changes. > > > https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests > > Please take a look and lets continue the discussion. > > Lastly, in order to keep the discussions of this large change, can we > keep/maintain separate threads discussing each of the major points? For > example if you want to talk about the "internal accessor method > visibility", create an email chain like "Accessors v1.2 : internal accessor > method visibility" > > Hopefully we can keep the emails in each thread on topic. > > Thanks! > > -Clint >
Re: [PHP-DEV] [RFC] Accessors : read-only / write-only keywords
read-only => final set null;
It begins to be verbose.
As I said many times, why don't you want to use the "const" keyword? It
already exists and is pretty well understood by everybody.
2012/10/20 Clint Priest
> I had thought of a deviation on some of the ideas presented to get rid of
> read-only/write-only while still keeping the ability to maintain their
> effect, if we so decide that the feature is wanted. Here it is:
>
> class TimePeriod {
> private $Seconds;
>
> public $Hours {
> get() { return $this->Hours; }
> final set NULL;
> }
> }
>
> It's close to what's been suggested but is pretty clear that there IS NO
> SETTER it could not be called within the class and since its final it
> cannot be over-ridden. I've included this in the change tracking document.
>
> Thoughts?
>
> -Clint
>
>
>
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
2012/10/17 Stas Malyshev > No, you don't get an error. You'd get an error in compiled language. In > dynamic language, your client gets an error when his site is launched > and instead of happy launch his users get white screens. To avoid that, > you'd need to add checks - or just ship it as is and hope your unit > tests were as good as you hoped they are (which they never are). I don't understand why this situation would be better without type hinting. I guess you think it's worst to code with the feeling of having a safety net (that's the feeling given by type hinting to most people) ? (no joke here, I just want to understand)
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 types would be > disastrous for the entire ecosystem and would completely change PHP. My point was not about scalar types. It was about porting the logic of parameters type hinting to object properties. Nothing more, nothing less. And the fact that it is "optional" means absolutely nothing because once > some piece of your system has "optionally" decided to use it you don't > have the option not to abide by it, and it certainly isn't a hint, it is > a strong type. You will end up casting every call to everything all the > time just to be safe. > I use parameters type hinting everyday. I can say it's very useful. And I never needed to cast anything. If the object model is used wisely, and if type hinting is used as an option (i.e. don't use it when you know you'll need "mixed" data), it's a very good thing. I don't see why it couldn't be as good for properties as it is for parameters. But Stas said it was already discussed a lot here, so I give up. :-)
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
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 $abc; (in cyberspace, no one can hear me scream) No need for another keyword when there is one doing the job. IMHO, write-only doesn't make any sense. If you define something "like an attribute" to be only writeable, in fact you are defining a method. But you use it like that: $obj->attr = 3; instead of using it like that: $obj->meth(3); What's the point? More, read-only and write-only are very poor-meaning keywords. We need full PPP visibility (and yes, I know the RFC allows asymetric visibility, but it implies to create accessors and therefore some code).
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 (always optional) could be very > useful. > > Not really, since PHP is not a compiled language and as such does not > have static type controls. Now not only every foo($bar) can blow up but > also every $foo->bar = $baz. Not very useful. > If the first could be useful, the second could be useful too. Or you are saying that parameters type hinting was a bad idea? You can argue using other languages' design choices, but it shouldn't drive our own choices. Every methods and properties are public in Python; it doesn't mean PHP is doing wrong (nor Python is doing wrong). Last thing: I agree with Clint and you. If it was early checked, it would be better. But the current type hinting is far better than nothing at all. Yes, we can't "lint" it, but it was pretty useful a big number of times in my company. was outlined some 9000 times here on the list. > OK, sorry for the trouble.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
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 PHP, for reasons that were amply explained in 9000 > discussions we had on this topic before. 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. Type hinting in parameters is a really good thing, and it doesn't transformed PHP in a strongly typed language. Doing the same for object properties (always optional) could be very useful.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
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:
> *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) There is no such syntax already in PHP. (And on a more personal note,
> I don't think I've ever seen that syntax in any other language that I've
> worked in before. Which means it's even *more-so* out of people's comfort
> zones.)
>
> The current read/write syntax works, and none of the discussion I've read
> thus far would sway me towards any other option.
>
> That being said, I wouldn't contest to hearing - in more detail - your
> reasoning behind why we should use it instead of the current syntax.
>
>
> On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard wrote:
>
>> 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 fail to implementation
>> > check against an interface.
>> >
>> > I cannot stress enough that properties != accessors in any way except
>> the
>> > syntax in which they are used ($o->xyz) or ($o->xyz = 1), that is their
>> > *only* similarity.
>>
>>
>> I disagree. That's why I said this is a matter of choice. A philosophical
>> choice.
>> I don't see properties and accessors like different things which are
>> accidentally written the same. Accessors are a layer upon properties. It's
>> a magical layer, trying to mimic accessors.
>> It's a bit like aspect-oriented programming: you can add layer but the
>> core
>> is still the same (from a developper point of view, not from the PHP
>> interpreter point of view).
>>
>>
>> See another argument: My proposal for read/write accessibility definition.
>> When I suggested to allow this syntax: "public:private $abc;"
>> some people objected that it's the same than "public $abc { get; private
>> set; }"
>>
>> So, if I understand what you said, for you it's deeply different and
>> comparing them is like comparing apples and oranges. I disagree. I still
>> think my syntax is better (and could be implemented with better
>> performance), but it's normal to compare them, because they (can) offer
>> pretty much the same functionnalities.
>>
>
>
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
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 fail to implementation
> check against an interface.
>
> I cannot stress enough that properties != accessors in any way except the
> syntax in which they are used ($o->xyz) or ($o->xyz = 1), that is their
> *only* similarity.
I disagree. That's why I said this is a matter of choice. A philosophical
choice.
I don't see properties and accessors like different things which are
accidentally written the same. Accessors are a layer upon properties. It's
a magical layer, trying to mimic accessors.
It's a bit like aspect-oriented programming: you can add layer but the core
is still the same (from a developper point of view, not from the PHP
interpreter point of view).
See another argument: My proposal for read/write accessibility definition.
When I suggested to allow this syntax: "public:private $abc;"
some people objected that it's the same than "public $abc { get; private
set; }"
So, if I understand what you said, for you it's deeply different and
comparing them is like comparing apples and oranges. I disagree. I still
think my syntax is better (and could be implemented with better
performance), but it's normal to compare them, because they (can) offer
pretty much the same functionnalities.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
True. But:
1. The code doesn't reflect that. In my previous example, it's true that I
know the Fooable interface details when I write the Bar object. But later,
when I'll read the code of this object, nothing tells me that $abc is an
accessor an not a property. It could be confusing and error-prone.
2. I though the goal of the RFC is to be able to handle properties (well,
some things that look like properties) without caring if there is some code
behind the scene.
If I am the only one to see an issue there, and if the choice was already
done (__get in interfaces), maybe we should stop to discuss this point :-)
2012/10/14 Clint Priest
> Hey Amaury,
>
> ** **
>
> Good points all around, but one last thing to point out, interfaces only
> declare what **must** be supported by an implementer, properties have no
> “implementation”, they just are. Whereas an accessor **has** an
> implementation. So when you see that an interface has an accessor, you can
> rely on the fact that anyone who implements that interface **must**
> implement an accessor of the given name.
>
> ** **
>
> *From:* amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Sunday, October 14, 2012 3:23 AM
> *To:* Clint Priest
> *Cc:* Nikita Popov; Benjamin Eberlei; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> ** **
>
> You are right, we can define __get() in an interface. So, in the end I
> will shut my mouth.
>
> ** **
>
> But still, it's not logical. An interface is a contract which defines the
> capacities of an object. If an interface defines the entry point swim(), we
> know that an object which implements this interface is able to swim. The
> goal is to define what is callable in an implementation (the basics of duck
> typing: if it can swim() and fly(), it's a flying fish).
>
> ** **
>
> In PHP, it was decided that interfaces may not include member variables. I
> guess it's a philosophical choice; you give orders to an object, knowing
> what it can do (thanks to the interface). And orders are given by calling
> methods, not by setting properties.
>
> ** **
>
> As I understand your explanation, you think it's normal to be able to
> define accessors in an interface, because it means there is some code
> behind. But from my point of view, the implementation (in the PHP
> interpreter) is not relevant; it's a design choice first.
>
> ** **
>
> Take a look at this code:
>
> interface Fooable {
>
> public $aaa { get; set; }
>
> }
>
> class Fooer implements Fooable {
>
> public $aaa {
>
> get { /* wathever ... */ }
>
> set { /* ... you want */ }
>
> }
>
> }
>
> class Bar {
>
> public function do() {
>
> $foo = new Fooer();
>
> $foo->aaa = 3;
>
> }
>
> }
>
> ** **
>
> The Bar object doesn't care if $aaa is an attribute or an accessor. It is
> used the same way.
>
> So, if we agree that this code is correct, I understand that something
> like "$foo->aaa" is a valid entry point to communicate with an object
> through an interface. TIt means that an API is not only defined by methods.
>
>
> You can argue that an accessor is different from a property, but again,
> only Fooer knows that, Bar shouldn't have to deal with that.
>
> ** **
>
> Then, for me there is two logical choices:
>
> - Forbid accessors in interfaces, as properties are already forbidden.
>
> - Allow accessors in interfaces => allow properties too. But it is a
> complete redefinition of interfaces in PHP.
>
> ** **
>
> I saw the link you gave to me. Well, as I said before, there is a lot of
> good ideas in C#, but I think PHP is an opinionated language and we can do
> our own choices (see how namespaces work in a very different way from C++
> namespaces, for example).
>
> ** **
>
> ** **
>
> As you point out, __get() implies the choice has already be done. So I
> shut up now :-)
>
> ** **
>
> ** **
>
> 2012/10/14 Clint Priest
>
>
>
> -Clint
>
>
> On Oct 13, 2012, at 4:21 PM, "Amaury Bouchard" wrote:*
> ***
>
> 2012/10/13 Clint Priest
>
> Interfaces are used to define what methods must be present, properties are
> not allowed.
>
>
>
> Yes, so no one should be correct, right?
>
> I mean, yes the first declaration implies some code; but for the
> interface, it's sti
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
You are right, we can define __get() in an interface. So, in the end I will
shut my mouth.
But still, it's not logical. An interface is a contract which defines the
capacities of an object. If an interface defines the entry point swim(), we
know that an object which implements this interface is able to swim. The
goal is to define what is callable in an implementation (the basics of duck
typing: if it can swim() and fly(), it's a flying fish).
In PHP, it was decided that interfaces may not include member variables. I
guess it's a philosophical choice; you give orders to an object, knowing
what it can do (thanks to the interface). And orders are given by calling
methods, not by setting properties.
As I understand your explanation, you think it's normal to be able to
define accessors in an interface, because it means there is some code
behind. But from my point of view, the implementation (in the PHP
interpreter) is not relevant; it's a design choice first.
Take a look at this code:
interface Fooable {
public $aaa { get; set; }
}
class Fooer implements Fooable {
public $aaa {
get { /* wathever ... */ }
set { /* ... you want */ }
}
}
class Bar {
public function do() {
$foo = new Fooer();
$foo->aaa = 3;
}
}
The Bar object doesn't care if $aaa is an attribute or an accessor. It is
used the same way.
So, if we agree that this code is correct, I understand that something like
"$foo->aaa" is a valid entry point to communicate with an object through an
interface. TIt means that an API is not only defined by methods.
You can argue that an accessor is different from a property, but again,
only Fooer knows that, Bar shouldn't have to deal with that.
Then, for me there is two logical choices:
- Forbid accessors in interfaces, as properties are already forbidden.
- Allow accessors in interfaces => allow properties too. But it is a
complete redefinition of interfaces in PHP.
I saw the link you gave to me. Well, as I said before, there is a lot of
good ideas in C#, but I think PHP is an opinionated language and we can do
our own choices (see how namespaces work in a very different way from C++
namespaces, for example).
As you point out, __get() implies the choice has already be done. So I shut
up now :-)
2012/10/14 Clint Priest
>
>
> -Clint
>
> On Oct 13, 2012, at 4:21 PM, "Amaury Bouchard" wrote:
>
> 2012/10/13 Clint Priest
>
>> Interfaces are used to define what methods must be present,
>> properties are not allowed.
>>
>> ** **
>>
>> Yes, so no one should be correct, right?
>>
>> I mean, yes the first declaration implies some code; but for the
>> interface, it's still a property definition.
>>
>> ** **
>>
>> You’re mixing concepts here, it’s an accessor definition, not a property
>> definition. property != accessor, an accessor just happens to look and act
>> like a property (which is the point of accessors).
>>
>
> Interfaces define methods, not properties. Fine.
> But is an accessor (as defined in the RFC) a method? Or should we consider
> that an accessor definition is valid inside an interface? I would say no,
> because it will be used as a property: outside of the object that
> implements the accessor, nobody know if it's an attribute or an accessor
> function.
>
> It's the whole point of the RFC (apart from the asymetric visibility,
> but you know my point of view).
>
>
> So, for me, this code should be incorrect:
> interface Fooable {
> public $abc { get; set; }
> }
>
> Because if an object implements the interface:
> class Fooer implements Fooable {
> public $abc {
> get { /* what you want */ }
> set { /* what you want too */ }
> }
> }
>
> How this code will be used? Like that:
> $foo = new Fooer();
> $foo->abc = 3;
> print($foo->abc);
>
> Everybody will agree with me that $abc is used like a property, not as a
> method. So the language should enforce that.
> There is a real issue here; this is not a fad from me.
>
> An accessor is a method and an interface which defines an accessor is
> indicating that the accessor must be implemented by any using the
> interface.
>
> See: http://msdn.microsoft.com/en-US/library/64syzecx(v=vs.80).aspx
>
> Also, "used like a property" does not mean it is a property, it is a
> method call with the syntax of accessing a property, it is still a method
> call.
>
> I believe __get() may be declared in an interface and if so, then
> accessors should be as well.
>
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/13 Clint Priest
>Interfaces are used to define what methods must be present, properties
> are not allowed.
>
> ** **
>
> Yes, so no one should be correct, right?
>
> I mean, yes the first declaration implies some code; but for the
> interface, it's still a property definition.
>
> ** **
>
> You’re mixing concepts here, it’s an accessor definition, not a property
> definition. property != accessor, an accessor just happens to look and act
> like a property (which is the point of accessors).
>
Interfaces define methods, not properties. Fine.
But is an accessor (as defined in the RFC) a method? Or should we consider
that an accessor definition is valid inside an interface? I would say no,
because it will be used as a property: outside of the object that
implements the accessor, nobody know if it's an attribute or an accessor
function.
It's the whole point of the RFC (apart from the asymetric visibility, but
you know my point of view).
So, for me, this code should be incorrect:
interface Fooable {
public $abc { get; set; }
}
Because if an object implements the interface:
class Fooer implements Fooable {
public $abc {
get { /* what you want */ }
set { /* what you want too */ }
}
}
How this code will be used? Like that:
$foo = new Fooer();
$foo->abc = 3;
print($foo->abc);
Everybody will agree with me that $abc is used like a property, not as a
method. So the language should enforce that.
There is a real issue here; this is not a fad from me.
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/13 Clint Priest
> Interfaces are used to define what methods must be present, properties
> are not allowed.
>
Yes, so no one should be correct, right?
I mean, yes the first declaration implies some code; but for the interface,
it's still a property definition.
> *From:* amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Saturday, October 13, 2012 5:06 AM
> *To:* Nikita Popov
> *Cc:* Benjamin Eberlei; Clint Priest; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
> ** **
>
> 2012/10/13 Nikita Popov
>
> interface Foo {
>
> // this is okay
> public $abc { get; set; }
>
> // this is invalid
> public $abc;
> }
>
> ** **
>
> Sorry, I missed something. Why the first should be correct but not the
> second one?
>
> For me it's exactly the same thing.
>
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/13 Nikita Popov
> interface Foo {
> // this is okay
> public $abc { get; set; }
>
> // this is invalid
> public $abc;
> }
>
Sorry, I missed something. Why the first should be correct but not the
second one?
For me it's exactly the same thing.
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Le 12 oct. 2012 10:37, "Bernhard Schussek" a écrit :
> > As I said, both syntaxes can work together. For example:
> > public:protected $a {
> > get() { return ($this->_prefix . $this->_a); }
> > set($val) { $this->_a = substr($val, 1); }
> > }
>
> A shortcoming of this syntax is that it does not offer a solution for
> the isset() and usset() accessors. Different visibility syntaxes for
> get/set and isset/unset would be unlogical and confusing.
Yes, you're right. But I never ever felt the need to define specific
visibility for __isset. On the other hand, I'm using getters and setters
everyday to manage the visibility of my object's attributes. (more about
isset and unset at the end of this email)
I'm trying to solve the main situation, not the special case.
> Also, public:protected implies an order which does not have to be kept
> in the block AFAIK. What is public and what is protected?
Read it aloud.
public $a { protected set; }
«$a is publicly readable, and protected against writing.»
Exactly the same:
public:protected $a;
«public read, protected write $a»
Seems easy to understand.
> public:protected $a { // ???
> protected isset() { ... }
> private unset() { ... }
> get() { ... }
> set($value) { ... }
> }
I consider that isset() is covered by the attribute's reading visibility,
and unset() is covered by writing visibility. If it's not obvious for you
as it is for me, can you give me some code examples?
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
2012/10/12 Clint Priest
> I guess I didn’t see any other support for it from others
>
Well, I get some bad replies (mainly from Andrew), but good ones too. Some
people (like Matthew) said it was an elegant syntax...
> and it is a subset of what the RFC I am proposing would encompass
>
Yes it's true, my proposal was focusing on a subset of your RFC. But this
subset is - from my experience - the main usage of accessors.
More, both can work together: My syntax could be used to define the
visibility of reading and writing access, while yours is perfect to add
processing on these accesses.
> did I miss something with your original email?
>
I don't know. It's a matter of choice. I prefer to write:
public:protected $a;
protected:const $b;
Rather than:
public $a {
protected set;
}
protected read-only $b;
I saw you removed your new keywords. I think it's a good thing, because
"const" was already here (no need for "read-only").
As I said, both syntaxes can work together. For example:
public:protected $a {
get() { return ($this->_prefix . $this->_a); }
set($val) { $this->_a = substr($val, 1); }
}
The visibility is defined first (how I can use this property?), and then
the code is available if needed (how does it work?). It's the same logic
than when you write "private static function foo() { ... }".
Maybe I'm the only one thinking we can imagine an elegant and
understandable syntax that doesn't need to mimic what C# does. But still.
:-)
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
You really don't want to even think about my idea? It's complementary on
some aspects, you know.
2012/10/11 Clint Priest
> Rather than go to the trouble of finding a reasonable way to hold a vote
> on these issues, is there anyone against the following changes:
>
> 1) Eliminate the ability for an accessor to be called via
> $o->__getHours(), the accessor functions will be completely unavailable for
> use except as property references ($o->Hours)
> 2) Change syntax to use public set($value) { }, public get(), etc. (and
> along with that means no more "magic" $value)
> 2a) If possible, allow for Type Hinting...
> 3) Eliminate automatically implemented get; set;, no automatic backing
> field creation will occur.
> 4) read-only / write-only keywords will be eliminated
> 5) Exceptions thrown from accessors will be made more appropriate (I will
> also check debug_backtrace information, etc)...
>
> If there isn't anyone against the above changes, I will make the changes
> to the RFC and re-present for final agreement...
>
> Or... do ya'll want to vote on the aforementioned changes?
>
> > -Original Message-
> > From: Clint Priest [mailto:cpri...@zerocue.com]
> > Sent: Wednesday, October 10, 2012 7:36 PM
> > To: internals@lists.php.net
> > Subject: RE: [PHP-DEV] [RFC] Propety Accessors v1.1
> >
> > Okay, I would like this to be the last time there are revisions to this
> RFC.
> >
> > To sum up the last few days of conversations, I have these down as
> points of contention:
> >
> > 1. Accessor functions should not be present on the object and callable
> directly, for example, $o->__getHours() should not be
> > allowed.
> > 2. Preferred syntax for accessors should be "public set($value) { ...
> }" with no "magic" $value (with possible type hinting) 3.
> > Automatically implemented get; set; with auto-backing field should be
> eliminated as this is not necessary for PHP and is confusing
> > most everyone.
> > 4. read-only / write-only keywords, keep them or get rid of them?
> There is no directly suitable replacement but I believe a private
> > final set() { } will take care of it, even though it much more verbose.
> > 5. Error handling for thrown exceptions should be made more appropriate
> for accessors 6. The "truth" of reflection. Should it reveal
> > details internal to how PHP works on the inside or should it reflect the
> way PHP presents it as options?
> >
> > Did I miss anything?
> >
> >
> > I will come up with some way for people to vote on the issues at hand
> and we can cast our votes and be done with it, then I will
> > finish the project and get it out the door.
> >
> > -Clint
>
Re: [PHP-DEV] [RFC] Propety Accessors v1.1
Hi,
This summer (july 15) I did another proposal, which has some connections
with yours.
For the main usage of getters/setters, my guess is that we need separate
read/write visibilities. Your RFC goes beyond that, but I think both are
complementary.
Most of the time, we write getters/setters to ensure that a private
attribute can be read but not modified (or modified only as we want to).
Your RFC is pretty powerful in some use cases. Like your example, which is
a "virtual" attribute, created from some processing. But create a new
"read-only" keyword is not a good idea for me: introduce a new keyword
should be avoided when it's not absolutely necessary, and it lacks meaning
(exact visibility information).
Correct me if I'm wrong, but your syntax is similar to the one used in C#.
Not a bad idea, but I think we can imagine for PHP somethink a little more
concise for the general usage.
My idea was to write attribute's visibility like
"read_visiblity:write_visibility $attr;"
public:protected $foo; // public reading, protected writing
public:private $bar; // public reading, private writing
protected:private $aaa; // protected reading, private writing
protected:const $bbb; // protected reading, no writing
With your RFC it will be:
public $foo { get; protected set; }
public $bar { get; private set; }
protected $aaa { get; private set; }
protected read-only $bbb;
When I did my proposal on the internals mailing-list, I got some pretty bad
feedbacks, and some very good ones.
So, maybe we can try to merge some ideas?
My patch: http://github.com/Amaury/php-src
Regards,
Amaury
2012/10/8 Clint Priest
> 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
>
> Example Usage:
>
> class TimePeriod {
> private $Seconds = 3600;
>
> public $Hours {
> get { return $this->Seconds / 3600; }
> set { $this->Seconds = $value; }
> isset { return isset<
> http://www.php.net/isset>($this->Seconds); }
> unset {
> unset($this->Seconds);
> }
> }
> }
>
> Changes / Updates
>
> * isset/unset accessor functions now implemented (object & static
> context, auto implementations, etc)
>
> * static accessor now fully functional
>
> * Reference functionality validated, tests written
>
> * All operators have been tested, tests written
>
> * read-only and write-only keywords: Added explanation of reasons
> for inclusion at the top of the appropriate RFC section
>
> * Tested for speed, approaches or meets __get() speed.
>
> Internally things have changed quite a bit
>
> * cleaned up and simplified
>
> * had been using 4 to 5 additional fn_flag slots, now down to two
> (READ_ONLY and WRITE_ONLY)
>
> * the automatic implementations now compiled internal php code,
> this greatly simplified that part of the code and future proofed it.
>
> The code is available at the url below and is up to date with master, all
> tests pass.
> https://github.com/cpriest/php-src
>
> I'd like to get this project wrapped up in time to make it to the 5.5
> release, only a few things remain to be completed/updated:
>
> * Check on reflection code written prior to major changes (tests
> still pass)
>
> * Add a few more reflection functions that were requested
>
> In total there are 79 tests for this new functionality, if there are any
> others that I have missed, please let me know.
>
> -Clint
>
>
Re: [PHP-DEV] constructor hook
Sounds to me like aspect-oriented programming, applied to object construction.
Take a look at: https://github.com/AOP-PHP/AOP
2012/9/18 Rasmus Schultz :
> 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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is our definition of a "Backward Compatibility Break"
2012/9/10 jpauli : > Based on our recent discussion on #pecl , I'd like we clarify what we > think is a "BCB" (Backward Compatibility Break) as well as what "only > minor BC breaks" could mean. > Stas' recent topic on internals "On BC and interfaces" may serve as a > reflection basis. > As our release process told us that we should not add BCB (but only > "minor" ones ... hum) in any minor release (nor revision), and as 5.5 > release process is going to start soon, I'd like we try to all agree > on that point. > > > What could be qualified as a BCB ? Any modification that change the behaviour of an existing API? Most of libraries change their minor version number when they add a new interface, but they change their major number when an existing interface is modified. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about hashtables implementation
2012/9/2 Sherif Ramadan > To clarify, this particular functionality you're using as an example > "array_unshift" really isn't specific to the internal implementation > of hashtables in PHP. That is to say that this side-effect you're > describing is specific to that function and not necessarily > hashtables' internal implementation. > OK, thanks for the information. It explains why I didn't find anything in the HashTable structure (unlike iterator pointer or the next free key). Essentially, array_unshift() just rebuilds the array. From > http://php.net/array-unshift "All numerical array keys will be > modified to start counting from zero while literal keys won't be > touched" > You're right; I hadn't noticed that. Side effect: add values at the beginning of an array could be very time-consuming, according to its size. If you're interested in a more detailed explanation of the > implementation of PHP's Array type you might find this article by > Nikic useful: > http://nikic.github.com/2012/03/28/Understanding-PHPs-internal-array-implementation.html Thanks again for this link. I have the book of Sara (huge piece of work, btw), and I found some good documentation. But more information wouldn't hurt! :-)
[PHP-DEV] Question about hashtables implementation
Hi all, I have a question about the internal implementation of PHP's hashtables. I did some researches, but I didn't find the answer. Here is an example of what I would like to understand. Start by creating an array: $a = array(); Fill it, using implicit and explicit keys: $a[] = 'cc'; $a[1] = 'dd'; If we look at what's inside, we get: Array ( [0] => cc [1] => dd ) OK, everything is obvious. Now, I add a value at the beginning of the array: array_unshift($a, 'ee'); Do a print_r() again: Array ( [0] => ee [1] => cc [2] => dd ) As you can see, the keys for 'cc' and 'dd' have been recalculated. It works as espected. My question is how does it work? Are all numeric keys computed when the array_shift() is done? Or is the iterator calculating them on-the-fly? Thanks. Amaury
Re: [PHP-DEV] Error handling brainstorming
2012/8/6 Stas Malyshev
> Exceptions are different from PHP errors. For example, if you try to
> open a file and the file isn't there, throwing exception is a very
> annoying behavior (yes I know some languages do that, IMO it's wrong).
> The reason is that it's pretty normal and within normal set of
> situations to which code should be prepared, so you will either have to
> obsessively wrap everything with try/catch blocks or do exception typing
> like Java does. Both options are quite annoying. I think it's much
> better to just open file and check if the result is OK. Converting it to
> exception doesn't really improve situation, as if downstream code didn't
> handle it the upstream probably won't know what to do with that
> exception either. This leads to code like try { whatever(); }
> catch(Exception e) {}. I saw tons of that in Java.
>
Even a simple file opening can fail for different kind of reasons (the file
doesn't exists, it is not readable, on some OS it could be already opened
and thus locked). Most of the time, you don't care the reason, but
sometimes you want to be more precise. With exceptions, we have an elegant
way to manage all failures as a whole, or to differenciate each reason.
But you are right, it could be very annoying to write a lot of try/catch
blocks. Maybe we could think about something inspired from Lua's "protected
call" function [1]. A convenient mean to say «OK, I know this expression
may raise an exception, but I don't care, discard it silently please. I
will check if my variable has been set or not.».
[1] : http://www.lua.org/pil/8.4.html
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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 = trim($value, "«»"); }
}
}
2012/7/24 André Rømcke
> On 7/23/12 12:38 PM, "Amaury Bouchard" wrote:
>
> 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 a new keyword (that should be avoided when not absolutely
> necessary).
> It's pretty easy to understand what it does (it's an attribute with public
> access, but it's not writable), but you loose meanings (visibility).
>
>
> read-only is already mentioned here:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented#read-only_and_write-only_properties
>
> But I see now that it is defined as full read only, not even the class
> itself can write to it, so ignore my code examples.
>
> My point was just; we also have the need for public:protected /
> public:private and would like to avoid the overhead of function calls,
> hence why I looked into if there would be ways to sync the two proposals to
> improve possibility of acceptance (ref feedback in thread).
>
>
>
>
> Hence, writing
> public $a { get; protected set; }
> is more accurate. You recover the lost meaning. But the writing is not
> straightforward.
>
> More, should you write
> public read-only $a;
> or
> public $a { get; private set; }
> ?
>
> Beside, it seems possible to write
> public read-only $a { protected get; private set; }
> but that doesn't means anything.
>
>
> Another examples:
> public read-only $a;
> vs
> public:const $a;
>
> public $a { get; private set; }
> vs
> public:private $a;
>
> public $a { get; protected set; }
> vs
> public:protected $a;
>
> We must be able to choose the attribute's visibility.
> We should be able to read it without having to read some unnecessary code.
> The PHP language should be consistent. I think the visibility
> information shouldn't be distributed on several locations (before the
> attribute; sometimes with a new "read-only" or "write-only" keyword;
> sometimes inside brackets, before a new "get" or "set" keyword).
>
>
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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 a new keyword (that should be avoided when not absolutely
necessary).
It's pretty easy to understand what it does (it's an attribute with public
access, but it's not writable), but you loose meanings (visibility).
Hence, writing
public $a { get; protected set; }
is more accurate. You recover the lost meaning. But the writing is not
straightforward.
More, should you write
public read-only $a;
or
public $a { get; private set; }
?
Beside, it seems possible to write
public read-only $a { protected get; private set; }
but that doesn't means anything.
Another examples:
public read-only $a;
vs
public:const $a;
public $a { get; private set; }
vs
public:private $a;
public $a { get; protected set; }
vs
public:protected $a;
We must be able to choose the attribute's visibility.
We should be able to read it without having to read some unnecessary code.
The PHP language should be consistent. I think the visibility information
shouldn't be distributed on several locations (before the attribute;
sometimes with a new "read-only" or "write-only" keyword; sometimes inside
brackets, before a new "get" or "set" keyword).
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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 proposal).
I would like everybody give 5 minutes to this idea [1] :-)
[1] : http://37signals.com/svn/posts/3124-give-it-five-minutes
2012/7/21 Matthew Weier O'Phinney
> 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 write
> > getters/setters), and think about another syntax for managing reading
> > and writing visibilities.
>
> My first impression, being familiar with the other proposal, was that
> this looked like duplication. However, on looking at the examples, I
> have to admit that I really like the approach -- in many cases, it
> obviates the need for a getter entirely. It would help dry up a lot of
> code, reduce the number of method calls overall, and still enforce
> internal logic when setting the value in the first place.
>
> I like it; it feels elegant.
>
>
> > 2012/7/16 Andrew Faulds
> >
> >> 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
> >> >> common cases. If you do need visibility control, it is possible too:
> >> >>
> >> >> public $property {
> >> >> get { ... }
> >> >> protected set { ... }
> >> >> }
> >> >>
> >> >> So what does this proposal add to it?
> >> >>
> >> >>
> >> > 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, private
> writing")
> >> >
> >> > With the existing RFC:
> >> > public $a {
> >> > private set { $this->a = $value; }
> >> > }
> >> >
> >> > Which one is better? Why should I write code for that?
> >> >
> >> > If you read the existing RFC, you'll see that all examples involve a
> >> > specific case: when you have a "fake" attribute, which manipulates
> date
> >> > stored in other attributes. The given example is an $Hours attributes,
> >> > which is calculated from the private $Seconds attribute.
> >> > Again, it could be very useful. But it doesn't work all the time.
> >>
> >>
> >>
> >> --
> >> Andrew Faulds (AJF)
> >> http://ajf.me/
> >>
> >
> > --f46d0446312cc5e06104c4f42161--
>
>
> --
> Matthew Weier O'Phinney
> Project Lead| matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Make try/catch brackets optinal
2012/7/20 Alex Aulbach > PS: And if without brackets should be forbidden. > If I wanted a coding style-constrained language, I would use Python.
Re: [PHP-DEV] 6.0 And Moving Forward
According to Rasmus' recent talk, a large part of PHP success came from its focus on web ecosystem, on what hosting ISPs are effectively needing. http://talks.php.net/show/supepi/6 (but it's better when you hear Rasmus telling it) 2012/7/20 Andrew Faulds > Whilst I feel some sympathy for you, I must ask if it is really the PHP > project to blame if your hosts use old PHP versions? > On Jul 20, 2012 12:50 PM, "Lester Caine" wrote: > > > Daniel Macedo wrote: > > > >> >One little change in PHP5.3.10 or so wiped out a whole block of mine, > and > >>> >the fix involved a re-writing all the Simply > >>> >because the ISP would not switch back on short tag. > >>> > >> Did you really go through all code manually to change the short tags? > >> You should be smarter than that: > >> https://github.com/danorton/**php_replace_short_tags/< > https://github.com/danorton/php_replace_short_tags/> > >> > > > > If I had easy access to every FTP server and local copies of the code > > bases in each, but we still have not rationalised what we inherited > > structure wise, and the update to PHP5.3 had not even been advised for > > those hosting packages! I think it was a mistake and unfortunate that the > > version they picked had the short_tag regression. > > > > But I want to get these sites BACK to ' > echo' is simply wrong for the style of site and framework that they use. > > I'd been tidying them up to be consistent before they blew up. > > > > One of the reasons major versions are introduced is BC breaks, those > >> don't come around frequently nor are introduced lightly, and you still > >> go through the E_DEPRECATED > .ini setting > disabled > optional > >> extension, for a safe cycle. > >> > >> I like to think we, as smart developers, would like to see complexity > >> reduced, even if we need to input a few man-hours into adapting the > >> old surviving masterpieces. > >> > > > > I've spent many DAYS on the 'strict' updates to other peoples > masterpieces > > So that argument is my main objection to many of these 'complexity > > reductions' as the changes I am making add nothing to the functionality > of > > these sites. > > > > The MAIN problem here is that ISP's do not update supplied versions of > PHP > > even with security fixes, simply because that cause them more problems. > > Many of the hosted sites I still need to move over are still on PHP5.2.? > > and dropping them onto a PHP5.4 machine even with all the ini settings > > correct simply does not work because they need bringing up to date to > > PHP5.3 first. I'm dragging my feet moving some 100 sites off 5.2 simply > > because I don't know what problems it's going to cause :( > > > > The stepping stone approach being pushed for these sorts of changes only > > works if everybody is following on the same stone. I bet 75% of sites are > > still on 5.2 and that moving them up to 5.4 simply would not work > cleanly? > > At least every one needs testing before moving them ... and that takes > time > > ... > > > > -- > > Lester Caine - G8HFL > > - > > Contact - http://lsces.co.uk/wiki/?page=**contact< > http://lsces.co.uk/wiki/?page=contact> > > L.S.Caine Electronic Services - http://lsces.co.uk > > EnquirySolve - http://enquirysolve.com/ > > Model Engineers Digital Workshop - http://medw.co.uk > > Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk< > http://rainbowdigitalmedia.co.uk> > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
Re: [PHP-DEV] 回复： [PHP-DEV] Make try/catch brackets optinal
2012/7/19 Reeze > 在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道： > > > +1 for the consistency of it. It's surprising that: > > > > if ($foo) > > return $bar; > > else > > return 42; > > > > works and: > > > > try > > maybe_dangerous(); > > catch(Dynamite $e) > > handle_error(); > > > > > > There is no condition after `try`, it's really hard to read without > bracket. > it becomes even worse if it didn't format pretty as above. > Bad argument. It's not about the presence of a condition after "try". It's about language consistency. If you were right, we shouldn't be able to write that: $i = 0; do echo($i++); while ($i < 3); PHP allows it. Nobody cares about it, while I think it's a very ugly writing. But everybody is accustomed to it, because it's inherited from C syntax. And bracketless try/catch doesn't exists in other languages, so it shouldn't exists in PHP? More, do not confuse coding conventions (depends on people, changes from time to time) and language syntax (should be stable and consistent).
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
Seems a lot like another syntactic sugar. Like in Lua, where you can write obj:method(12) instead of obj.method(obj, 12) But OOP-like syntax on non-object data is still weird. The question about data manipulation behavior (is it a pointer like other objects or is it a scalar like existing array?) is a tough one. 2012/7/18 Andrew Faulds > OK, ok. Let me clear some things up here. > > We don't want it to make things more object-oriented or whatever. The real > motivation is to give us a chance to make a much cleaner, much nicer array > API without breaking BC. We can keep the legacy array_* and unprefixed > functions, but we can also create "pseudo-object methods" (not objects, but > methods and possibly properties hooked into the method call processing, > checking for non-object types - it's very easy to check (I've done it) for > non-objects, and implementing this seems simple enough but I don't know the > Zend engine well enough). This way we can have array->key, > array->sort(TYPE), etc. for new code to use, instead of the legacy array > and string method mess (the latter needs a cleanup more in particular). > > OK? > On Jul 18, 2012 10:14 AM, "Pierre Joye" wrote: > > > hi, > > > > On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev > > wrote: > > > > > And no, it does not "allow us to clean our APIs" - I again point out > > > using -> has nothing to do with cleaning APIs. Repeating "clean APIs" > > > as if it is some magic spell will not make false statement true, and > the > > > statement that using -> somehow cleans up APIs is false. Cleaning APIs > > > and pseudo-objects are two completely different things, and nobody yet > > > shown any relationship between the two. > > > > You do not see it, your call. But it indeed does and anyone I was > > talking to about this topic agrees with this view but two persons (you > > incl.). > > > > Anyway, it is somehow pointless to argue to death about that as it is > > technically not possible yet. I'm 200% sure it will happen. > > > > Cheers, > > -- > > Pierre > > > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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 clear?
Take this code, for instance:
public read-only $a {
protected get;
private set;
}
Yeah, I know, the "public" should be "protected". But in some years, when
you'll have some legacy code, I'm pretty sure we will see this kind of
code. It should work, the "public" visibility is just overloaded by the
"protected" and "private" visibilities. Anyway, it's perturbing.
Oh, and there is a "read-only" keyword. Damned, I added a private setter, I
forgot it was read-only and I forgot to remove it...
So, I guess it should be like that:
protected $a {
private set;
}
Then, try to read this code aloud. I'm really not sure it's better than a
simple "protected:private $a;", which could be read like "protected
reading, private writing".
2012/7/16 Nikita Popov
> 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, private writing")
> >
> > With the existing RFC:
> > public $a {
> > private set { $this->a = $value; }
> > }
> >
> > Which one is better? Why should I write code for that?
> >
> > If you read the existing RFC, you'll see that all examples involve a
> > specific case: when you have a "fake" attribute, which manipulates date
> > stored in other attributes. The given example is an $Hours attributes,
> which
> > is calculated from the private $Seconds attribute.
> > Again, it could be very useful. But it doesn't work all the time.
>
> You can also just write public $a { get; private set; }. I see that
> the syntax is a bit more verbose, but I definitely prefer it to the
> obscure public:private notation. With the getters/setters the meaning
> is somewhat clear (public get, private set), with the colon notation
> it isn't really clear.
>
> Nikita
>
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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
> 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
> >> common cases. If you do need visibility control, it is possible too:
> >>
> >> public $property {
> >> get { ... }
> >> protected set { ... }
> >> }
> >>
> >> So what does this proposal add to it?
> >>
> >>
> > 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, private writing")
> >
> > With the existing RFC:
> > public $a {
> > private set { $this->a = $value; }
> > }
> >
> > Which one is better? Why should I write code for that?
> >
> > If you read the existing RFC, you'll see that all examples involve a
> > specific case: when you have a "fake" attribute, which manipulates date
> > stored in other attributes. The given example is an $Hours attributes,
> > which is calculated from the private $Seconds attribute.
> > Again, it could be very useful. But it doesn't work all the time.
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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 { ... }
> }
>
> So what does this proposal add to it?
>
>
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, private writing")
With the existing RFC:
public $a {
private set { $this->a = $value; }
}
Which one is better? Why should I write code for that?
If you read the existing RFC, you'll see that all examples involve a
specific case: when you have a "fake" attribute, which manipulates date
stored in other attributes. The given example is an $Hours attributes,
which is calculated from the private $Seconds attribute.
Again, it could be very useful. But it doesn't work all the time.
Re: [PHP-DEV] supporting the final keyword for properties
It could be useful (given the example of Java usage). But still, if the goal is to have read-only attributes, I think my proposal (separate reading and writing visibilities) is more precise and powerful. 2012/7/16 Ferenc Kovacs > Hi, > > The recent > http://www.mail-archive.com/internals@lists.php.net/msg59301.html > discussion > made me wonder why did we decide not supporting the final keywords for > properties as it would provide an easy way for read-only attributes (const > would be a better choice in performance wise, but then you can only set it > in your declaration where no dynamic expression is allowed.) > > I would like it to work the same way as it does in java( > http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4) > eg. > you can set the initial value either in the declaration or later on, but > after it is set, you can't change it, trying to do that would create a > recoverable fatal error (or throwing an exception which extends > RuntimeException). > > What do you think? Would this be viable? Is there any still-present reason > why we shouldn't support that? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
Re: [PHP-DEV] RFC Proposal - Attributes read/write visibility
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 will not allow you to have an attribute readable only by
descendant classes (and by the current class, of course), and at the same
time only writable by the current class.
PHP is an object-oriented language with public/protected private
visibility. Visibility conveys meanings, and we shouldn't loose these
meanings when we add new functionalities.
Once again, the purpose of the get/set syntax RFC is to define getters and
setters directly where attributes are defined. Attributes' visibility is a
distinct question, which deserve a distinct answer (even if there is some
obvious connections).
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 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 ("Property
>> get/set syntax" [1]). Its goal is mainly different, but I'll discuss it
>> lower.
>>
>>
>> THE PROBLEM
>> In my experience, one of the major usage of getters is when you want to
>> have an attribute, readable (but not writable) from outside the object.
>> More, the attribute's visibilty is then chosen between private and
>> protected, depending on your inheritance design.
>>
>> The result is not really satisfying:
>> 1. You have to write getter's code. Maybe, it's just a simple return, but
>> every line of code should be useful, not a workaround.
>> 2. You ended with 2 syntaxes; $obj->attr when the attribute is public, but
>> $obj->getAttr() when you must use a getter. It's a bit schizophrenic.
>>
>>
>> THE IDEA
>> I suggest to be able to separate reading visibility and writing
>> visibility,
>> using a colon to separate them. If only one visibility is given, it will
>> be
>> used for both reading and writing access.
>>
>> For example:
>> class A {
>> public $a; // public reading, public writing
>> public:public $b;// the same
>> public:protected $c; // public reading, protected writing
>> public:private $d; // public reading, private writing
>> public:const $e; // public reading, no writing allowed
>>
>> protected $f; // protected reading, protected writing
>> protected:protected $g; // the same
>> protected:private $h; // protected reading, private writing
>> protected:const $i; // protected reading, no writing allowed
>>
>> private $j; // private reading, private writing
>> private:private $k; // the same
>> private:const $l; // private reading, no writing allowed
>> }
>>
>> As you can see, I think that writing access should be more restrictive
>> than
>> reading access (or equivalent to it). A "private:public" visibility would
>> make no sense.
>>
>>
>> SOURCE CODE
>> I did a patch. It kinda works, but I'm still working on it (because I'm
>> still learning Zend Engine's internals).
>> The code on GitHub: https://github.com/Amaury/php-src
>> All advises are welcome.
>>
>>
>> PRIOR WORK
>> As I said before, the "Property get/set syntax" RFC is in discussion. My
>> proposal doesn't focus on the same goals, but they could be fully
>> compatible.
>>
>> Thus, we would be able to write this kind of code:
>> class A {
>> // $str has public reading and private writing,
>> // and manage french quotes
>> public:private $str {
>> get { return "«" . $this->str . "»"; }
>> set { $this->str = trim($value, "«»"); }
>> }
>> }
>>
>> Maybe you saw that the "Property get/set syntax" RFC has an intended
>> syntax
>> for read-only and write-only attributes. From my point of view, there is a
>> deep and clean separation between a getter/setter syntax and an extended
>> visibility syntax. It shouldn't be in the same RFC.
>> More, the proposed "read-only" and "write-only" keywords are less precise
>> and powerful than what I'm suggesting.
>>
>>
>> I would be happy to discuss all that with you guys.
>>
>> Best regards,
>>
>> Amaury Bouchard
>>
>>
>> [1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
>>
>
>
>
> --
> *Brandon Wamboldt*
> Programmer / Web Developer
>
> StackOverflow Careers
> Profile<http://careers.stackoverflow.com/brandonwamboldt>- GitHub
> Profile <https://github.com/brandonwamboldt> -
> LinkedIn<https://github.com/brandonwamboldt> -
> My Blog <http://brandonwamboldt.ca/>
>
>
[PHP-DEV] RFC Proposal - Attributes read/write visibility
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 ("Property
get/set syntax" [1]). Its goal is mainly different, but I'll discuss it
lower.
THE PROBLEM
In my experience, one of the major usage of getters is when you want to
have an attribute, readable (but not writable) from outside the object.
More, the attribute's visibilty is then chosen between private and
protected, depending on your inheritance design.
The result is not really satisfying:
1. You have to write getter's code. Maybe, it's just a simple return, but
every line of code should be useful, not a workaround.
2. You ended with 2 syntaxes; $obj->attr when the attribute is public, but
$obj->getAttr() when you must use a getter. It's a bit schizophrenic.
THE IDEA
I suggest to be able to separate reading visibility and writing visibility,
using a colon to separate them. If only one visibility is given, it will be
used for both reading and writing access.
For example:
class A {
public $a; // public reading, public writing
public:public $b;// the same
public:protected $c; // public reading, protected writing
public:private $d; // public reading, private writing
public:const $e; // public reading, no writing allowed
protected $f; // protected reading, protected writing
protected:protected $g; // the same
protected:private $h; // protected reading, private writing
protected:const $i; // protected reading, no writing allowed
private $j; // private reading, private writing
private:private $k; // the same
private:const $l; // private reading, no writing allowed
}
As you can see, I think that writing access should be more restrictive than
reading access (or equivalent to it). A "private:public" visibility would
make no sense.
SOURCE CODE
I did a patch. It kinda works, but I'm still working on it (because I'm
still learning Zend Engine's internals).
The code on GitHub: https://github.com/Amaury/php-src
All advises are welcome.
PRIOR WORK
As I said before, the "Property get/set syntax" RFC is in discussion. My
proposal doesn't focus on the same goals, but they could be fully
compatible.
Thus, we would be able to write this kind of code:
class A {
// $str has public reading and private writing,
// and manage french quotes
public:private $str {
get { return "«" . $this->str . "»"; }
set { $this->str = trim($value, "«»"); }
}
}
Maybe you saw that the "Property get/set syntax" RFC has an intended syntax
for read-only and write-only attributes. From my point of view, there is a
deep and clean separation between a getter/setter syntax and an extended
visibility syntax. It shouldn't be in the same RFC.
More, the proposed "read-only" and "write-only" keywords are less precise
and powerful than what I'm suggesting.
I would be happy to discuss all that with you guys.
Best regards,
Amaury Bouchard
[1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
@Michael : I'm not sure to understand what you mean. The "&=" operator does a bitwise AND. But if it was an assignment-by-reference operator, maybe an assignment-by-cloning operator would have seemed a good idea? Some people write code using "=&" like a dedicated operator. For example: $i = 3; $j =& $i; (yes, I know they should write "$j = &$i;") It would be an "inverted equivalent" if we were able to write : $i = new Int(3); $j := $i; 2012/6/30 Michael Morris > Uhm... &= > > On Fri, Jun 29, 2012 at 6:09 PM, Paul Dragoonis > wrote: > > My input is that we should be focusing on features that PHP lacks, or > > fixing bugs rather than adding more sugar syntax just for the sake of > > adding it. > > > > On Fri, Jun 29, 2012 at 7:47 PM, Pierrick Charron >wrote: > > > >> No problem when you'll come in Montreal ! If you need any help don't > >> hesitate. > >> > >> Pierrick > >> > >> On 29 June 2012 14:27, Amaury Bouchard wrote: > >> > >> > Yes, guys. I totally understand your point. As I said, I had this > idea in > >> > a dreamed context (good or bad dream? I don't know). > >> > But still, I think it's intellectually interesting, even if it's not a > >> > good concept for PHP. :-) > >> > > >> > Pierrick, I owe you a beer ;-) > >> > Le 29 juin 2012 19:06, "Pierrick Charron" a > >> écrit : > >> > > >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning
Yes, guys. I totally understand your point. As I said, I had this idea in a dreamed context (good or bad dream? I don't know). But still, I think it's intellectually interesting, even if it's not a good concept for PHP. :-) Pierrick, I owe you a beer ;-) Le 29 juin 2012 19:06, "Pierrick Charron" a écrit :
[PHP-DEV] RFC proposal - Syntactic sugar for cloning
Hello everybody, It's the first time I write on the internals mailing-list, so let me introduce myself quickly. I'm a french and canadian CTO, working in Paris. I lead some PHP projects (mainly the Temma framework and FineFS data replication system). I begin to learn PHP's internal engine, backed by Pierrick Charron. I would like to do an RFC proposal (see below for the associated patch). I was thinking about "what if PHP was a full-object language?". Like, for example, how will we write the simplest code, assuming that objects are handled using pointers since PHP 5. Take a look at this code: $a = 3; $b = $a; $a++; $b still contains the value 3. Now, if we imagine that even the integer data type is managed in an object, the same code will produce two pointers to the same object. Thus, $b will have the value 4, as $a. So, in this imaginary world, we would need to do a lot of object cloning. I wondered how this could be less painful, and I thought about the Pascal language's affectation operator (:=). Then we would be able to write something like that: $a = 3; $b := $a; $c = $a; $a++; $a equals 4, as $c. But $b equals 3. Back in the real world, we are not cloning objects very often. But, like many other syntactic sugars (as the short array syntax), I think it could be handy in some circumstances. There is a patch for this evolution, written by Pierrick. Full source code: https://github.com/adoy/php-src/tree/amaury-clone Code diff: https://github.com/adoy/php-src/commit/5107c0355c50381c7e67230cdc9f563eb3936a15 I'm looking forward to your advices. Cheers! Amaury
