Ralph,
to write. This is one of the reasons that traits are so heralded.
>> Because problems that are easy to solve with decorators (in general) are
>> difficult to solve with PHP, so people wind up writing copy/paste
>>
>
> If what you're trying to do is decorate an instance of a particular
> con
Hey Anthony,
There's a lot here, so I'm only going to address a few things.
It sounds to me like you haven't tried to use decorators for any complex
logic. Making it type equivalent leads to very vebose code. And a PITA
I actually have used both Decorators and Proxies (it's cousin) a number
Ralph,
On Tue, Aug 14, 2012 at 3:30 PM, Ralph Schindler
wrote:
>
> Well, I like it at first glance. There are two main problems that I see
>> with it:
>>
>> 1. It still requires a separate decorator class for every combination of
>> interfaces you want to decorate. So, for example if you wanted
On Tue, Aug 14, 2012 at 10:54 PM, Ferenc Kovacs wrote:
>
>
> On Tue, Aug 14, 2012 at 9:19 PM, Kris Craig wrote:
>
>> >
>> > Put that aside, I think that someone should create a guidelines in the
>> > wiki about how to post an RFC without an account...
>> >
>>
>> Ironically, I think we'd need to
Hi!
> Simply because your object responds to all the same methods of, for
> example, the FooInterface, does not make it a FooInterface subtype. It
> just means that in the "duck typing" sense of the phrase, it can act
> like a FooInterface for people that are not necessarily concerned that
>
On Tue, Aug 14, 2012 at 9:19 PM, Kris Craig wrote:
> >
> > Put that aside, I think that someone should create a guidelines in the
> > wiki about how to post an RFC without an account...
> >
>
> Ironically, I think we'd need to create an RFC for that. ;)
>
> --Kris
>
1. fill out https://wik
Well, I like it at first glance. There are two main problems that I see
with it:
1. It still requires a separate decorator class for every combination of
interfaces you want to decorate. So, for example if you wanted to
decorate a Foo interface, but sometimes it's used with Iterator as well.
Th
>
> Put that aside, I think that someone should create a guidelines in the
> wiki about how to post an RFC without an account...
>
Ironically, I think we'd need to create an RFC for that. ;)
--Kris
On Tue, Aug 14, 2012 at 9:47 PM, Kris Craig wrote:
>
>
> On Tue, Aug 14, 2012 at 10:28 AM, Yahav Gindi Bar wrote:
>
>> Hi,
>>
>> I believe its a newbie question, but because I only replied to mails and
>> didn't create any RFC page yet I wish to confirm.
>>
>> I wish to create an RFC page for a f
On Tue, Aug 14, 2012 at 10:28 AM, Yahav Gindi Bar wrote:
> Hi,
>
> I believe its a newbie question, but because I only replied to mails and
> didn't create any RFC page yet I wish to confirm.
>
> I wish to create an RFC page for a feature discussion, but I can't do it
> from the wiki page (think i
Ralph,
On Tue, Aug 14, 2012 at 12:49 PM, Ralph Schindler
wrote:
> In general, I think it would be nice to have something that does this for
> you, but I am not necessarily a fan of changing the meaning of instanceof.
>
>
> That's a lot of boilerplate for each possible iteration. This is one
>> r
On 8/14/12 10:36 AM, Stas Malyshev wrote:
Hi!
That said, rewind() should behave consistently. I don't feel it makes
sense to have rewind() succeed at one point, and fail at another. It
would only cause confusion when not familiar with the behavior. Either
allow it, or don't. Not both.
It does,
Hi!
> That said, rewind() should behave consistently. I don't feel it makes
> sense to have rewind() succeed at one point, and fail at another. It
> would only cause confusion when not familiar with the behavior. Either
> allow it, or don't. Not both.
It does, since foreach uses rewind. So fir
Hi,
I believe its a newbie question, but because I only replied to mails and
didn't create any RFC page yet I wish to confirm.
I wish to create an RFC page for a feature discussion, but I can't do it
from the wiki page (think it's lack of permissions issue).
I've looked at the mailing list logs a
Hi!
> I agree with you. The one case where this syntax may be very useful is if
> we want to implement class casting. So introduce a pair of magic methods
I do not think we want to implement class casting. I'm not sure how
class casting even makes sense - if the object is of one class, how can
yo
In general, I think it would be nice to have something that does this
for you, but I am not necessarily a fan of changing the meaning of
instanceof.
That's a lot of boilerplate for each possible iteration. This is one reason
people like traits so much, as it's easier to just do automated copy/
On 8/13/12 9:09 AM, Nikita Popov wrote:
On Sun, Aug 12, 2012 at 10:08 PM, Brian Moon wrote:
Also, not allowing rewinding is unintuitive for something that is an
iterator in PHP. If I can foreach() it and I can call next() on it, I expect
to be able to reset() it as well. IMO, you would need to
Levi,
On Tue, Aug 14, 2012 at 9:51 AM, Levi Morrison wrote:
> On Tue, Aug 14, 2012 at 1:46 AM, Stan Vass wrote:
> > I've felt the need for this for some time.
> >
> > Proposed syntax:
> > -
> >
> > $x = (InterfaceName) $container->service;
>
> I'm against this. Let's be
If I may chime in, not all iterators support rewind, at least not as outlined.
There exists also the NoRewindIterator which you can just use to decorate an
iterator out of a generator to not make it do a fatal.
However as far as a generator is concerned, it probably should just behave like
NoRe
Proposed syntax:
-
$x = (InterfaceName) $container->service;
I'm against this. Let's be honest, how different is this that an
optionally static type?
InterfaceName $x = $container->service;
To be clear, I WANT optionally static typing. For the most part,
type-hinting
On Tue, Aug 14, 2012 at 1:46 AM, Stan Vass wrote:
> I've felt the need for this for some time.
>
> Proposed syntax:
> -
>
> $x = (InterfaceName) $container->service;
I'm against this. Let's be honest, how different is this that an
optionally static type?
InterfaceName $x
2012/8/13 Nikita Popov :
> * After first yield: Recoverable fatal error
>
> So this would allow you to call ->rewind() after creating the
> generator, but will throw an error if you try to do so later.
Hm. I think this looks like a workaround over conceptual problems.
The (in my eyes) "right" beh
2012/8/13 Anthony Ferrara :
> It's absolutely something that takes getting used to. But it's also quite
> intuitive once you think about it. You're not "returning" back to the
> parent scope (exiting your scope), you're "yielding" a value to the parent
> scope, expecting to continue on later (think
hi Anthony,
On Sun, Aug 12, 2012 at 8:17 PM, Anthony Ferrara wrote:
> What do you think? Is this a route that I should continue down? Or is there
> something fundamental that I'm missing here? I know that Reflection,
> get_interfaces(), etc would need to be updated to account for this.
>
> Thoug
Would this work with methods which take arguments by reference or return by
reference?
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Aug 14, 2012 at 8:36 AM, Stas Malyshev wrote:
> Hi!
>
> > 2. Move instanceof to a handler from the current standalone function.
> Then
> > each (pecl level) class could choose its own implementation if it is
> > needed. The function could still exist for BC reasons, but would proxy to
> >
On Tue, Aug 14, 2012 at 12:46 AM, Stan Vass wrote:
> I've felt the need for this for some time.
>
> Proposed syntax:
> -
>
> $x = (InterfaceName) $container->service;
>
> Proposed behavior:
> ---
>
> Checks if the instance if an instance of the give
I've felt the need for this for some time.
Proposed syntax:
-
$x = (InterfaceName) $container->service;
Proposed behavior:
---
Checks if the instance if an instance of the given class/interfaces. If yes,
does nothing, if not, issues a fatal error
28 matches
Mail list logo
