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
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
For what it's worth, some time ago I prototyped something like that, without
modifying the language, in the form of a Universal class that you may
inherit from without defining __contruct/__destruct yourself.
See class definition below. In a using class (herarchy) define static methods
I suggest you read this recent thread for related commentary.
http://www.serverphorums.com/read.php?7,71
In there, I refer to your proposal as Contractual Call Super and I
find it an interesting concept that helps avoid the advisory call
super antipattern.
However --
If the
On 03.07.2013 20:05, Sanford Whiteman wrote:
a new keyword is problematic, perhaps this same
behaviour could be enacted in cases where an inheriting class has a
constructor and the base class' constructor is defined as final i.e. rather
than causing an error, the final constructor is executed
Most often if I need a super __construct(), I don't need it exactly
before or exactly after the bottom constructor but at a specific point
where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly implemented, the Call Super
antipattern by putting
On 03.07.2013 20:48, Sanford Whiteman wrote:
Most often if I need a super __construct(), I don't need it exactly
before or exactly after the bottom constructor but at a specific point
where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly
No, that's why I am asking. Why is it an anti-pattern to call a known
super constructor?
Guess I'd send you to my comments in the earlier thread as I think I
exhausted my ability to dismantle (advisory a..k.a. pretty please)
Call Super there. Or ?call super antipattern.
Of course, most every
Hello community,
This is my first post here. I hope to improve my participation in the
community and give back to the technology that has done so much for my
career. My first attempt is to propose an additional syntax for the
Foreach statement.
Background:
There are times in our code where we
Welcome Chris,
As a `plain` user of PHP, i'd like to advocate not to allow anymore
aliasing of ways to do stuff...
Your example should just read foreach(array_keys($array) as $key) {} That's
the only way to convey the actual intent of working with keys and
explicitly leaving out the values ;)
On Wed, Jul 3, 2013 at 10:01 PM, Chris London m...@chrislondon.co wrote:
Hello community,
This is my first post here. I hope to improve my participation in the
community and give back to the technology that has done so much for my
career. My first attempt is to propose an additional syntax
Not that it would be an argument but just for understanding: Do you know
any scripting language which has this?
Dropping the scripting part... IIRC, C++ calls ctors without
arguments automatically like in my 'sequentialBefore' napkin sketch.
C# has language-level support for
On Wed, Jul 3, 2013 at 11:10 PM, Sanford Whiteman
swhitemanlistens-softw...@cypressintegrated.com wrote:
Not that it would be an argument but just for understanding: Do you know
any scripting language which has this?
Dropping the scripting part... IIRC, C++ calls ctors without
arguments
I've been thinking about this for a bit and even if you are right
about being nice to have a way to call a function always after
constructor. It could happen. You could have a DB class and in
constructor the user/pass/host/options and then a separate method for
init().
But that's not Call
Hi Ralph,
I still like the proposal.
Am 08.09.2012 um 07:12 schrieb Ralph Schindler ra...@ralphschindler.com:
[...]
But yes, I agree that runtime resolution only duplicates existing
behavior, so it isn't really necessary (you could argue thought that
self::class similarly also only replicates
What I find absolutely confusing is the use of Class vs. CLASS vs. class for
constant names. Let’s limit the translation to FQCN.
I will clean up the proposal make the examples more consistent (all lower
case). It's worth noting though, that this is reusing the reserved keyword
class which
Hi Ralph,
Am 08.09.2012 um 20:03 schrieb Ralph Schindler ra...@ralphschindler.com:
[...]
What I find absolutely confusing is the use of Class vs. CLASS vs. class for
constant names. Let’s limit the translation to FQCN.
I will clean up the proposal make the examples more consistent (all
I need to address Stas's concerns.
Is there a particular time frame I should be aware of?
-ralph
On 6/19/12 12:19 PM, Nikita Popov wrote:
On Tue, Apr 17, 2012 at 4:54 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
I've also added an RFC page, any thoughts on improving the RFC?
*
Hi!
I need to address Stas's concerns.
Is there a particular time frame I should be aware of?
For 5.5, no rush so far but I imagine we'd want to start figuring out
5.5 feature set in a couple of months, so if you want it there you may
want to have it ready by then.
--
Stanislav Malyshev,
On Tue, Apr 17, 2012 at 4:54 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
I've also added an RFC page, any thoughts on improving the RFC?
* https://wiki.php.net/rfc/class_name_scalars
-ralph
What's the state of this RFC?
Nikita
--
PHP Internals - PHP Runtime Development Mailing
@Nicolas: wouldn't __CLASS__ introduce a bit of confusion with the existing
constant?
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 17 April 2012 11:17, Nikita Popov nikita@googlemail.com wrote:
On Sat, Apr 14, 2012 at 9:50 PM, Ralph Schindler
Hi Nikita,
A quick note on the patch: As the class name is compile-time
resolvable it should in my eyes also be available as a
`static_scalar`, so that it can be used in initialization lists:
public function doFoo($withClass = ABC::class) {
new $withClass; // or whatever
}
On 2012-04-17, Ralph Schindler ra...@ralphschindler.com wrote:
Hi Nikita,
A quick note on the patch: As the class name is compile-time
resolvable it should in my eyes also be available as a
`static_scalar`, so that it can be used in initialization lists:
public function
Hi Ralph,
On 17/04/12 10:54, Ralph Schindler wrote:
I've also added an RFC page, any thoughts on improving the RFC?
* https://wiki.php.net/rfc/class_name_scalars
Are you sure that the example section is correct? Because your first
var_dump is Moo::CLASS but the symbol Moo does not exist
var_dump is Moo::CLASS but the symbol Moo does not exist yet, only the
class Foo\Bar\Baz was declared at this point.
It could exist. It could be a class name handled by an autoloader
somewhere else.
This method of class name resolving operates in the spirit of how our
namespace
On Sat, Apr 14, 2012 at 12:50 PM, Ralph Schindler
ra...@ralphschindler.comwrote:
Hi all,
There are many different use cases were in code we expect classes names as
arguments to functions as fully qualified names. We do this in ZF a lot
with our Service Location and DI components, but also
On Tue, Apr 17, 2012 at 9:36 PM, Galen Wright-Watson ww.ga...@gmail.com wrote:
Would it be easy to have a patch that simply allows use of the class name,
or is the ::class suffix necessary to resolve some ambiguity? Example
usage:
$mock = $this-getMock(A\Namespaced\**ClassName);
# or
Would changing the definition for class_name_scalar be sufficient?
class_name_scalar:
class_name { zend_resolve_class_name($1, ZEND_FETCH_CLASS_GLOBAL,
1 TSRMLS_CC); $$ = $1; }
;
To my eye, this is the least surprising syntax.
As far as I can tell, this rule will not
2012/4/16 Ralph Schindler ra...@ralphschindler.com
I am not quite following. There is no functional difference between
class, CLASS, or Class. The parser is case insensitive with regards
to keywords, which class or T_CLASS is on of. The code snipped I showed
there was from the .phpt test
Hey Simon,
As the class-definition for Moo is missing, I think it's an empty
class (like Baz) on the root-level defined somewhere else, right?
Otherwise this should do something else than guessing the class-name.
If you look at the patch, this feature is not doing anything PHP doesn't
2012/4/16 Ralph Schindler ra...@ralphschindler.com
... PHP does not invoke the autoloader to determine if the class name
actually exists as a declaration somewhere, it simply resolves it according
to some very specific rules (in the case of this patch, carried out by
I used to implement `public static function getClass() { return
get_called_class(); }`, so I really like this one, makes it also easier
for IDEs when refactoring code :)
Oh completely, that is one of the major benefits. My current workflow
for refactoring is to refactor with the built-in
Hi Ralph, hi everybody,
given the clear use case and the simplicity of the patch, a very good idea.
With regards,
Lars
Am 15.04.2012 um 16:13 schrieb Ralph Schindler:
I used to implement `public static function getClass() { return
get_called_class(); }`, so I really like this one, makes
2012/4/14 Ralph Schindler ra...@ralphschindler.com:
Hi all,
There are many different use cases were in code we expect classes names as
arguments to functions as fully qualified names. We do this in ZF a lot
with our Service Location and DI components, but also with our code
reflection API,
One thing I personally dislike in this implementation is the
difference between CLASS and class ... One with and one without
namespaces ...
I am not quite following. There is no functional difference between
class, CLASS, or Class. The parser is case insensitive with
regards to keywords,
Hi all,
There are many different use cases were in code we expect classes names
as arguments to functions as fully qualified names. We do this in ZF a
lot with our Service Location and DI components, but also with our code
reflection API, etc. A more interesting use case I would like to
I used to implement `public static function getClass() { return
get_called_class(); }`, so I really like this one, makes it also easier for
IDEs when refactoring code :)
I was wondering about `class A { const CLASS = 'hello'; }` but that would
cause an unexpected `T_CLASS`, so I guess there's no
Am 14.04.2012 23:14, schrieb Marco Pivetta:
I used to implement `public static function getClass() { return
get_called_class(); }`, so I really like this one, makes it also easier for
IDEs when refactoring code :)
I was wondering about `class A { const CLASS = 'hello'; }` but that would
cause
hi,
i think it would be really handy to introduce the with() feature from
JavaScript (and probably other OOP languages) into php. so for sample the
following
---
$class=new class;
$class-do_something();
$class-do_more();
$class-do();
---
could
Richard Black wrote:
[...]
for me it doesn't add any value - only potential confusion.
+0.9
it makes sense as a convenience tool if used correctly
but can create a hell of a maintenance nightmare if not
Almost as bad as GOTO maintenance wise but without the
benefits in edge cases.
When
[mailto:[EMAIL PROTECTED]
Sent: 09 October 2007 20:12
To: internals@lists.php.net
Subject: [PHP-DEV] new feature - with()
hi,
i think it would be really handy to introduce the with() feature from
JavaScript (and probably other OOP languages) into php. so for sample
the following
Hartmut Holzgraefe wrote:
When reading foreign C++ code a lot you learn to love
the explicit nature of PHP naming scopes even though
it is extra typing as it is clear at first sight whether
you are looking at a variable, member variable, function,
object method ...
Lets do not weaken this
Richard Black wrote:
I'm usually a lurker on here, but thought I'd through in my 2p on this
one...
Delphi (Object Pascal) has a similar feature, that I've had some
experience of using, and I never liked it. Why? Because it only leads to
confusion, mainly because the separation of object and
---
$class=new class;
with($class)
{
do_something();
do_more();
do();
}
What more value does this hold over implementing fluent interfaces which
are already possible?
Assuming
class Foo {
public function doSomething() { /**code**/ return $this; }
Stut wrote:
It may not be clear to some people, but there are many things in the
every language that aren't necessarily obvious and I don't think that's
a reason not to implement something.
I think that is one of the strongest reasons not to implement something
actually. If there is a way to
Rasmus Lerdorf wrote:
Stut wrote:
It may not be clear to some people, but there are many things in the
every language that aren't necessarily obvious and I don't think that's
a reason not to implement something.
I think that is one of the strongest reasons not to implement something
actually.
Rasmus Lerdorf skrev:
I think that is one of the strongest reasons not to implement something
actually. If there is a way to do something in a clear and concise
syntax, adding an alternate less clear syntax that isn't immediately
obvious to everyone simply obfuscates the language.
The other
47 matches
Mail list logo
