Am 13.04.2015 um 15:37 schrieb Johannes Ott:
Hi,
finally I managed to do my first RFC draft.
https://wiki.php.net/rfc/static_class_constructor
I hope I have done everything correct so far and I'm looking forward to
your feedback on it.
As I already mentioned in the prediscussion
Am 14.04.2015 um 00:16 schrieb Levi Morrison:
- IMO, the method should be called when the class is created, just after
every parent class and implemented interfaces are created.
In general I think static class data and static class constructors are
a sign of poorly designed code, which
As the RFC is still in draft status, I will stop for now answering any
issues on the purpose of this RFC. I will now rewrite some things at the
draft, and come back to the discussion in this threads after those changes
I will focus on the following open issues I have identified during the
last
Am 14.04.2015 um 16:33 schrieb Dan Ackroyd:
Here is some feedback then:
From the RFC:
- Trigger for “magic” method call: First call to class, either first call to
__construct(...) or first call to any public or protected static method or
property of the class
I don't think this
Am 13.04.2015 um 18:54 schrieb Johannes Schlüter:
On Mon, 2015-04-13 at 17:23 +0200, Johannes Schlüter wrote:
Why am I saying it makes the language more complex? - Your proposal
seems to miss mentioning when exactly the method is executed. what is
Ah, I missed this
Trigger for
Am 13.04.2015 um 18:48 schrieb Cesar Rodas:
Instead of having a method, why don't we allow body expr to be
evaluated as we see things in the Class definition?
?php
class foobar
{
static protected $conn = new mysqli('localhost', 'my_user',
'my_password', 'my_db');
}
It's cleaner but
Hi,
finally I managed to do my first RFC draft.
https://wiki.php.net/rfc/static_class_constructor
I hope I have done everything correct so far and I'm looking forward to
your feedback on it.
As I already mentioned in the prediscussion thread here:
For being my first change to the PHP core, I
Am 10.04.2015 um 20:57 schrieb Ferenc Kovacs:
On Fri, Apr 10, 2015 at 6:07 PM, Johannes Ott m...@deroetzi.de wrote:
Am 10.04.2015 um 17:54 schrieb Christoph Becker:
Johannes Ott wrote:
Am 13.03.2015 um 16:42 schrieb Johannes Ott:
as you can see at the initial discussion thread
, 2015 at 5:23 PM, Johannes Schlüter johan...@schlueters.de
wrote:
Hi,
On Mon, 2015-04-13 at 15:37 +0200, Johannes Ott wrote:
finally I managed to do my first RFC draft.
https://wiki.php.net/rfc/static_class_constructor
I hope I have done everything correct so far and I'm looking forward
Am 13.04.2015 um 18:02 schrieb François Laupretre:
De : Johannes Ott [mailto:m...@deroetzi.de]
finally I managed to do my first RFC draft.
https://wiki.php.net/rfc/static_class_constructor
I hope I have done everything correct so far and I'm looking forward to
your feedback
Am 15.03.2015 um 11:02 schrieb Crypto Compress:
I think I now get the misunderstanding I had on your destructor question
Sorry for confusion. My points are agnostic about implementation details
and concrete code. It's up to ppl to use this feature as they like.
Okay get your point, but
Am 13.03.2015 um 01:33 schrieb Christoph Becker:
Johannes Ott wrote:
And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname() which is really
unnecessary
Am 15.03.2015 um 19:47 schrieb Rowan Collins:
On 15/03/2015 10:41, Johannes Ott wrote:
Okay get your point, but as already discussed several times, the rfc
should not be declined for the reason a ppl, who doesn't understand when
to use static context or when not to use at all, can do crucial
Am 15.03.2015 um 12:35 schrieb Crypto Compress:
You should reread your mails and keep insults to yourself:
as already discussed several times
ppl, who doesn't understand
some beginner who is doing such horiffic code
maybe think more about what he is doing
doing 15 years of
Am 14.03.2015 um 18:34 schrieb Crypto Compress:
So I do not see the need of a explicit class deconstructor, because the
language should already react correctly on this issues as I can see so
far
The language cannot know the order of dependencies and how to destruct
them.
A dependcy between
Am 14.03.2015 um 18:34 schrieb Crypto Compress:
So I do not see the need of a explicit class deconstructor, because the
language should already react correctly on this issues as I can see so
far
The language cannot know the order of dependencies and how to destruct
them.
A dependcy between
Am 14.03.2015 um 06:41 schrieb Levi Morrison:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to
Am 14.03.2015 um 07:49 schrieb Crypto Compress:
Am 13.03.2015 um 11:30 schrieb Johannes Ott:
Am 13.03.2015 um 07:45 schrieb Crypto Compress:
Hello Johannes,
in other mails you argue with Rowan about global state. I think it's
better to focus on innovation of class context in global scope
Am 13.03.2015 um 01:33 schrieb Christoph Becker:
Johannes Ott wrote:
And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname() which is really
unnecessary
Am 13.03.2015 um 14:36 schrieb Rowan Collins:
Sorry, replying to myself to add a couple of thoughts / clarifications:
Rowan Collins wrote on 13/03/2015 11:53:
Johannes Ott wrote on 13/03/2015 09:53:
Why are in your opinion static members are not allowed to hold more
complexe datastructures
Hi there,
as you can see at the initial discussion thread with the subject static
constructor I'm planing to do a Draft for a RFC for the suggested feature.
How do I get the karma to create this RFC on wiki?
Regards,
--
DerOetzi
--
PHP Internals - PHP Runtime Development Mailing List
To
Thanks for the clear statement, which lights up the fog a little bit for.
Watching out for a scalar typehints feature for round about 10 years
without knowing about this internal list, I always was wondering what
can be so complicated to implement it, because I already evaluated some
different
Am 11.03.2015 um 17:21 schrieb Rowan Collins:
My reasoning is that code that is ambiguous is hard to read. If $foo
can mean either a local variable called $foo or a property of the
current object called $foo, then you have to know which it is in order
to understand what code is doing.
So
Am 11.03.2015 um 14:03 schrieb Rowan Collins:
Johannes Ott wrote on 10/03/2015 20:46:
okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
What about inheritance?
I think dynamic class-constructor would make much more sense.
A function which can analyse real class and do initialisation.
class A
{
protected static function __class_construct()
{
echo get_called_class().” class is defined\n;
}
}
Am 12.03.2015 um 05:17 schrieb Levi Morrison:
On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 11/03/2015 23:21, Johannes Ott wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here
Most of these examples are just crying out to be real objects, not
static classes. You might not want to be creating them every time you
use them, but that's what patterns like Singletons and Dependency
Injection are for.
I really disagree to this. Singletons are a typical
Am 12.03.2015 um 12:40 schrieb Niklas Keller:
How would it behave for the second call? If the first initialize fails due
to some exception, should that static constructor be executed again?
I think there a two different solutions and I do not know which one I
prefer at the moment:
1. No
Am 12.03.2015 um 16:57 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm (For example conditions
or read from filesystem). That should be encapsulated inside
Am 12.03.2015 um 18:55 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 17:05:
Am 12.03.2015 um 16:57 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 14:51:
That is nearly like initializing a class constant, but in my opinion a
constant should not have a complex algorithm
Am 12.03.2015 um 20:34 schrieb Rowan Collins:
Patrick Schaaf wrote on 12/03/2015 18:40:
Am 12.03.2015 18:56 schrieb Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com:
Johannes Ott wrote on 12/03/2015 17:05:
So doing a null check each time
is a overhead
Am 12.03.2015 um 21:33 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 19:45:
All of the magic methods are doing like this.
I thought you might say that, but the only thing remotely similar I can
think of is a destructor, which gets called when an object goes out of
scope
Am 12.03.2015 um 12:16 schrieb Crypto Compress:
Hello Johannes,
class Foo {
private static function __static() {
throw new Exception(boom);
}
}
while(true) {
try {
$foo = new Foo;
} catch (Exception ex) {}
}
Would this code be valid?
Have to think
Am 11.03.2015 um 18:12 schrieb Rowan Collins:
Johannes Ott wrote on 11/03/2015 16:46:
Am 11.03.2015 um 17:21 schrieb Rowan Collins:
My reasoning is that code that is ambiguous is hard to read. If $foo
can mean either a local variable called $foo or a property of the
current object called
Am 11.03.2015 um 22:28 schrieb Bob Weinand:
Hi all,
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
Am 11.03.2015 um 15:05 schrieb Niklas Keller:
You have to input internals@lists.php.net, that changed some time ago.
I've just updated https://wiki.php.net/rfc/howto
See
https://github.com/php/web-wiki/commit/583d2c1b39a8b88960ab94e56ba4a4608ddb2353
Regards, Niklas
Thanks that helped.
Am 12.03.2015 um 00:30 schrieb Marco Pivetta:
Hey Johannes,
Why can't this be done at autoloading time?
In my opinion this should not be done on autoloading time, but as a own
method inside the class for two reasons.
1. Not every class is loaded with autoload-functions, but although
directly
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some
Am 11.03.2015 um 14:25 schrieb Christoph Becker:
Johannes Ott wrote:
BTW:
I'm trying to register a wiki account. But somehow it does not work.
When posting the formular the page is reloading, but nothing else
happens. No success or no error message is shown.
Maybe I'm doing something
Hi,
sorry I did the wrong order, starting to discuss already without
introducing me first:
My name is Johannes Ott. I am 31 years old. I'm developing with PHP since
2004, I have written my thesis about Testdriven development of a PHP-
Framework with namespaces and 'typesafety' as implemented
Hi,
okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
and more declaratively properties concept in my opinion.
So I would suggest for now
Hey
as developing both Java and PHP, I would suggest a solution similar to
Java. As long as there is no conflict to a local variable the keyword
$this should be the default.
Regards
DerOetzi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
42 matches
Mail list logo
