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.
>
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 t
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 two
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, whic
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?
>
>
> class foobar
> {
> static protected $conn = new mysqli('localhost', 'my_user',
'my_password', 'my_db');
> }
>
> It's cleaner bu
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
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'
class_constructor
Thanks for feedback
> On Mon, Apr 13, 2015 at 5:23 PM, Johannes Schlüter
> 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
Am 10.04.2015 um 20:57 schrieb Ferenc Kovacs:
> On Fri, Apr 10, 2015 at 6:07 PM, Johannes Ott wrote:
>
>> Am 10.04.2015 um 17:54 schrieb Christoph Becker:
>>> Johannes Ott wrote:
>>>
>>>> Am 13.03.2015 um 16:42 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 thread here:
For being my first change to the PHP core, I w
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
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
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() whi
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,
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 r
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.
>
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.
>
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
>>> b
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 way
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 uns
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 t
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, as
> it's impossible to reason the disadvantages of global state away.
> (Discussions on va
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() whi
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 g
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" > <mailto:rowan.coll...@gmail.com>>:
>> >
>> > Johannes Ott wrote on 12/03/2015 17:05:
>> >
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
>>&g
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 filesyste
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. N
>
> 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 FactoryP
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
>
> 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
> 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 righ
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 a
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 do
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
direct
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 st
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:
>
> https://wiki.php.net/
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 l
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 he
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 succes
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 wrong?!
Regards
--
DerOetzi
--
PHP Internals - PHP Runtime Development Mailin
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
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&
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: http://www.php.net/uns
44 matches
Mail list logo
