On Fri, Sep 27, 2013 at 11:26 AM, Joe Watkins wrote:
> On 09/27/2013 10:42 AM, Terence Copestake wrote:
>
>> Just ... Isn't that something, we can simply keep out of _this_ RFC and
>>> create separate RFC(s) for it later? Like it was done with "$this in
>>
> Just ... Isn't that something, we can simply keep out of _this_ RFC and
> create separate RFC(s) for it later? Like it was done with "$this in
> Closures"?
Do we want another 5.3/5.4 closures situation? Why not iron it all out to
begin with?
If there's a sound, logical reason not to implement
> 1) Anonymous classes in PHP would support a constructor, so I don't see
> the need for use to be utilized here, it would just clutter declarations
> and the patch.
This works, but it's more effort for the programmer and arguably just
moving the "clutter" from the declaration to the constructor.
I'm growing to like the idea myself. It may create new opportunities for
bad practices, but I don't think it's the concern of internals to police
how people may or may not use a feature. There are also I think a few
things that would need to be addressed before this would be ready for the
real worl
Playing devil's advocate here, could this feature make the language more
expressive?
Take for example an API where you'd typically wrap a method call in
try/catch blocks to handle the various "outcomes" e.g. a user login, you'd
maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception,
In less than 10 posts, this thread descended into people bashing each
other. Perhaps that's telling of something.
I won't comment on the point about forums or anything else, but a concern
brought up repeatedly both here and in various blogs is the lack of
direction or vision. There's a conflict be
Hello again.
I think we can condense the issues raised in the thread so far down to:
- What purpose would this feature serve in the face of design/pattern-based
alternatives?
- In what order should the constructor(s) be called?
- How to approach overriding these constructors if necessary?
- How w
Hello, all.
On one or two occasions I've encountered a problem when designing a base
class, where I wish to implement important set-up functionality in the
constructor, but am limited in how to ensure that the base constructor
functionality is unmolested whilst not restricting any inheriting class
