Re: [PHP-DEV] supporting the final keyword for properties
2013/5/28 Maciek Sokolewicz maciek.sokolew...@gmail.com 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] supporting the final keyword for properties
2013/5/28 Sebastian Krebs krebs@gmail.com 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 Sebastian Krebs krebs@gmail.com 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] Continued try blocks
2013/4/29 Stas Malyshev smalys...@sugarcrm.com 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 unrea...@gmail.com
On Apr 28, 2013, at 17:27, Julien Pauli jpa...@php.net wrote:
On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard ama...@amaury.net
wrote:
2013/4/27 Ferenc Kovacs tyr...@gmail.com
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 Ferenc Kovacs tyr...@gmail.com
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/27 Daniel Macedo admac...@gmail.com 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
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 p...@bof.de
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] Continued try blocks
2013/4/26 Andreas Heigl andr...@heigl.org
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] Re: Was Reflection annotations reader - We Need A Vision
2013/1/11 dukeofgaming dukeofgam...@gmail.com 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 lis...@rafaeldohms.com.br 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 somme...@gmail.com 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 ircmax...@gmail.com 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 smalys...@sugarcrm.com 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
2012/10/21 Levi Morrison morrison.l...@gmail.com 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
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 cpri...@zerocue.com 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
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 cpri...@zerocue.com
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] [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 cpri...@zerocue.com 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
2012/10/20 Nikita Popov nikita@gmail.com
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 : read-only / write-only keywords
2012/10/20 Derick Rethans der...@php.net 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] [PHP-DEV [RFC] Property Accessors v1.2 : Typehints / Accessor Syntax
2012/10/17 Stas Malyshev smalys...@sugarcrm.com 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 : Interfaces
2012/10/15 Clint Priest cpri...@zerocue.com
Also, your should be valid statement implies that you feel properties
and accessors are the same and they are not, internally. When a class
attempts to implement an interface a function check is done and since
there is no __getXX() function defined 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
This discussion is opened in the dedicated thread. I used my proposal as an
example to illustrate my point of view, not to pollute this thread.
2012/10/16 Jazzer Dane tbprogram...@gmail.com
I prefer the current syntax to your proposal because:
1) It is not at all obvious which side is which. 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 ama...@amaury.netwrote:
2012/10/15 Clint Priest cpri...@zerocue.com
Also, your should be valid statement implies that you feel properties
and accessors are the same and they are not, internally. When a class
attempts to implement an interface a function check is done and since
there is no __getXX() function defined 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 : Typehints / Accessor Syntax
2012/10/16 Stas Malyshev smalys...@sugarcrm.com public DateTime $date; This is *real* progress, even if under the hood all it does is wrap I think it's a movement in wrong direction. Again, it is an attempt to make PHP a strongly typed language, which would not work well in a dynamic 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 : Typehints / Accessor Syntax
2012/10/16 Stas Malyshev smalys...@sugarcrm.com Also, the fact is that other dynamic languages do not have strong typing. It may be they just aren't smart enough to recognize everybody needs it - or there may be a reason why it doesn't happen. I think there is a reason Doing the same for 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
2012/10/16 Clint Priest cpri...@zerocue.com In this regard, I have yet to see any proposal that is as clear or concise as public read-only $abc. What is the big problem with adding read-only and write-only keywords? Once they are in the language they could be expanded to plain properties. 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 Rasmus Lerdorf ras...@lerdorf.com The rule in PHP for any sort of type hinting is that it is only done for non-coercable types. In cases where there is simply no way to recover from passing the wrong type, it is good to catch it as early as possible. Extending this to also cover 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
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 cpri...@zerocue.com
-Clint
On Oct 13, 2012, at 4:21 PM, Amaury Bouchard ama...@amaury.net wrote:
2012/10/13 Clint Priest cpri...@zerocue.com
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
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 cpri...@zerocue.com
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 cpri...@zerocue.com
-Clint
On Oct 13, 2012, at 4:21 PM, Amaury Bouchard ama...@amaury.net wrote:*
***
2012/10/13 Clint Priest cpri...@zerocue.com
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
Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
2012/10/13 Nikita Popov nikita@gmail.com
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 Clint Priest cpri...@zerocue.com
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 nikita@gmail.com
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 Clint Priest cpri...@zerocue.com
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] [RFC] Propety Accessors v1.1
2012/10/12 Clint Priest cpri...@zerocue.com
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
Le 12 oct. 2012 10:37, Bernhard Schussek bschus...@gmail.com 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
You really don't want to even think about my idea? It's complementary on
some aspects, you know.
2012/10/11 Clint Priest cpri...@zerocue.com
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 cpri...@zerocue.com
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; }
issethttp://www.php.net/isset { return isset
http://www.php.net/isset($this-Seconds); }
unsethttp://www.php.net/unset {
unsethttp://www.php.net/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 ras...@mindplay.dk:
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:
?php
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 jpa...@php.net: 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
[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] Question about hashtables implementation
2012/9/2 Sherif Ramadan theanomaly...@gmail.com 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! :-)
Re: [PHP-DEV] Error handling brainstorming
2012/8/6 Stas Malyshev smalys...@sugarcrm.com
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 andre.rom...@ez.no
On 7/23/12 12:38 PM, Amaury Bouchard ama...@amaury.net wrote:
2012/7/23 André Rømcke 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, 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 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, 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 weierophin...@php.net
On 2012-07-16, Amaury Bouchard ama...@amaury.net 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 ajf...@googlemail.com
How much syntactic sugar do we really need? Why add two ways to do
something?
On 16 July 2012 16:24, Amaury Bouchard ama...@amaury.net wrote:
2012/7/16 Nikita Popov nikita@gmail.com
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] 回复： [PHP-DEV] Make try/catch brackets optinal
2012/7/19 Reeze reeze@gmail.com 在 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] 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 ajf...@googlemail.com 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 les...@lsces.co.uk 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 ?= code across many pages. 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 '?=' format as well since '?php 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] Make try/catch brackets optinal
2012/7/20 Alex Aulbach alex.aulb...@gmail.com PS: And if without brackets should be forbidden. If I wanted a coding style-constrained language, I would use Python.
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 ajf...@googlemail.com 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 pierre@gmail.com wrote: hi, On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev smalys...@sugarcrm.com 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] 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 tyr...@gmail.com 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/16 Nikita Popov nikita@gmail.com
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] 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 ajf...@googlemail.com
How much syntactic sugar do we really need? Why add two ways to do
something?
On 16 July 2012 16:24, Amaury Bouchard ama...@amaury.net wrote:
2012/7/16 Nikita Popov nikita@gmail.com
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
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 nikita@gmail.com
On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard ama...@amaury.net
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
[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 - Attributes read/write visibility
2012/7/15 Brandon Wamboldt brandon.wambo...@gmail.com
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 ama...@amaury.net 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
Profilehttp://careers.stackoverflow.com/brandonwamboldt- GitHub
Profile https://github.com/brandonwamboldt -
LinkedInhttps://github.com/brandonwamboldt -
My Blog http://brandonwamboldt.ca/
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 dmgx.mich...@gmail.com Uhm... = On Fri, Jun 29, 2012 at 6:09 PM, Paul Dragoonis dragoo...@gmail.com 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 pierr...@webstart.fr 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 ama...@amaury.net 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 pierr...@webstart.fr a écrit : -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[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
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 pierr...@webstart.fr a écrit :
