hi Jamie,
Please post patch or publish pull requests first :)
Cheers,
On Fri, Oct 12, 2012 at 2:12 AM, Jamie Taylor ja...@dr0id.in wrote:
PHP Trunk, developing bug fixes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Hi Clint,
I would like to urge you again to consider implementing the array
access methods. Without that, this very neat feature becomes
essentially unusable for modelling one-to-many, many-to-one and
many-to-many object relations, as I tried to explain in the previous
topic.
Objects and
Clint Priest wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make sure I have all of your concerns correctly
addressed and we can leave this open for the two week waiting
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
hi Lester,
On Fri, Oct 12, 2012 at 10:22 AM, Lester Caine les...@lsces.co.uk wrote:
Clint Priest wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make sure I have all of
Pierre Joye wrote:
hi Lester,
On Fri, Oct 12, 2012 at 10:22 AM, Lester Caine les...@lsces.co.uk wrote:
Clint Priest wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make
On Fri, Oct 12, 2012 at 10:49 AM, Lester Caine les...@lsces.co.uk wrote:
Sorry , but if the complexity was any good, why does it need to be changed?
Simply scrap the whole lot and get back to a more sane solution. I'm sorry
but this is just the whole problem with PHP 'development' ...
We know
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request $request, Closure $onFound);
}
An implementation of the interface could be as
On Oct 12, 2012 10:59 AM, Christian Kaps christian.k...@mohiva.com
wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request
Pierre Joye wrote:
Sorry , but if the complexity was any good, why does it need to be changed?
Simply scrap the whole lot and get back to a more sane solution. I'm sorry
but this is just the whole problem with PHP 'development' ...
We know that you don't like modern solutions, we really know it
On Fri, Oct 12, 2012 at 7:23 AM, Clint Priest cpri...@zerocue.com wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make sure I have all of your concerns correctly
Le 12/10/2012 11:48, Nikita Popov a écrit :
I've been thinking a bit about the automatic properties again, and
noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context, so
that you can write public $foo { get; protected set;
paf!
On vrijdag 12 oktober 2012 13:50:34, Cal wrote:
Le 12/10/2012 11:48, Nikita Popov a écrit :
I've been thinking a bit about the automatic properties again, and
noticed that I forgot to name one use case: Asymmetric accessor
visibility. Automatic properties may be useful in that context,
Good hint, Nikita.
I like the feature of automatic properies. For the problems with unauthorized
access: What about signing automated generated variables, so that they are
only accessable through the property?
@Lester Caine: This properties do not break backward compatibility. If you do
not
Please ignore me... i'm a n00b and my mail programme F*cked me...
my bad
Regards,
Robin Speekenbrink
Kingsquare BV
On vrijdag 12 oktober 2012 13:50:34, Cal wrote:
Le 12/10/2012 11:48, Nikita Popov a écrit :
I've been thinking a bit about the automatic properties again, and
noticed that I
Christian Stoller wrote:
@Lester Caine: This properties do not break backward compatibility. If you do
not want to use it, you do not need.
I like them because they offer an easy, short and well readable way to
protected object or class variables.
The problem is not my own use Christian ...
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
On Thu, Oct 11, 2012 at 11:23 PM, Clint Priest cpri...@zerocue.com wrote:
Alright, here is the updated RFC as per discussions for the last few days:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
If you could read it over, make sure I have all of your concerns correctly
Nuked dr0id
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Now if you pass a closure to the scan method which doesn't follow the
signature of the __invoke method, the engine should throw an error.
What do you think?
You are trying to take typing way beyond what PHP (or probably any
mainstream dynamic language that exists now) provides. There
On Fri, Oct 12, 2012 at 10:58 AM, Christian Kaps
christian.k...@mohiva.com wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request
I must have missed taking that part out of the RFC, they would not be needed
any more with those keywords being removed.
-Original Message-
From: Levi Morrison [mailto:morrison.l...@gmail.com]
Sent: Friday, October 12, 2012 9:45 AM
To: Clint Priest
Cc: internals@lists.php.net
The problem with that Nikita is that it would need a variable storage location,
which would mean a hidden, auto-implemented property. You were dead-set
against that from the get go. Keep in mind that property accessors are not
properties, real properties will take over the accessor, this
Yeah, if you check out the section in the RFC on static properties I give
examples of both of these cases, I have not tested the use of static::$zz
though come to think of it, I will put it on my todo list.
From: Jazzer Dane [mailto:tbprogram...@gmail.com]
Sent: Friday, October 12, 2012 12:32
Hey Bernhard,
I see a few problems with the proposal:
1) If you're adding all of the ArrayAccess functions, what about all of the
Iterator functions? How about other SPL aspects, like Countable, etc.
2) The use case can still be handled with an actual object which implements
ArrayAccess and
25 matches
Mail list logo
