-Clint
On Oct 13, 2012, at 4:21 PM, "Amaury Bouchard"
mailto:ama...@amaury.net>> wrote:
2012/10/13 Clint Priest mailto: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
2012/10/13 Clint Priest
>Interfaces are used to define what methods must be present, properties
> are not allowed.
>
> ** **
>
> Yes, so no one should be correct, right?
>
> I mean, yes the first declaration implies some code; but for the
> interface, it's still a property definition.
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
> > On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest wrote:
> > 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.
> What I was mainly against was the particul
2012/10/13 Clint Priest
> Interfaces are used to define what methods must be present, properties
> are not allowed.
>
Yes, so no one should be correct, right?
I mean, yes the first declaration implies some code; but for the interface,
it's still a property definition.
> *From:* amaury.bouc
Interfaces are used to define what methods must be present, properties are not
allowed.
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.ph
Am 12.10.2012 23:06, schrieb Nikita Popov:
On Fri, Oct 12, 2012 at 10:58 AM, Christian Kaps
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 funct
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 are
lan
2012/10/13 Nikita Popov
> interface Foo {
> // this is okay
> public $abc { get; set; }
>
> // this is invalid
> public $abc;
> }
>
Sorry, I missed something. Why the first should be correct but not the
second one?
For me it's exactly the same thing.
On Sat, Oct 13, 2012 at 11:29 AM, Nikita Popov wrote:
> On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei
> wrote:
> > Can we discuss the removal of automatic get; set; again? For me that was
> > the best feature of the whole RFC, essentially allowing to define a
> > property with getter/setter
On Sat, Oct 13, 2012 at 6:47 AM, Clint Priest wrote:
> 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.
What I was mainly against was the particular way how a
On Sat, Oct 13, 2012 at 10:06 AM, Benjamin Eberlei wrote:
> Can we discuss the removal of automatic get; set; again? For me that was
> the best feature of the whole RFC, essentially allowing to define a
> property with getter/setter in 1 LOC. Allowing future overriding of that
> getter/Setter if t
On Fri, Oct 12, 2012 at 7:23 AM, 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
13 matches
Mail list logo
