Removing the Hooks class

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Removing the Hooks class

Jeroen De Dauw-2
Hey,

I'm curious what the list thinks of deprecating and eventually removing the
Hooks class. Some relevant info:

/**
 * Hooks class.
 *
 * Used to supersede $wgHooks, because globals are EVIL.
 *
 * @since 1.18
 */

https://github.com/wikimedia/mediawiki-core/blob/master/includes/Hooks.php#L30

I personally find the comment hilarious and hope you see why when looking
at the "class". Looks like usage in core and extensions is not to
extensive, so switching to something more sane seems quite feasible.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Chad
On Wed, Apr 3, 2013 at 9:51 PM, Jeroen De Dauw <[hidden email]> wrote:

> Hey,
>
> I'm curious what the list thinks of deprecating and eventually removing the
> Hooks class. Some relevant info:
>
> /**
>  * Hooks class.
>  *
>  * Used to supersede $wgHooks, because globals are EVIL.
>  *
>  * @since 1.18
>  */
>
> https://github.com/wikimedia/mediawiki-core/blob/master/includes/Hooks.php#L30
>
> I personally find the comment hilarious and hope you see why when looking
> at the "class". Looks like usage in core and extensions is not to
> extensive, so switching to something more sane seems quite feasible.
>

It's like a global, only slower :D

If you've got any better ideas, I'm all for it.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Tyler Romeo
In reply to this post by Jeroen De Dauw-2
On Apr 3, 2013 9:52 PM, "Jeroen De Dauw" <[hidden email]> wrote:
>
> Hey,
>
> I'm curious what the list thinks of deprecating and eventually removing
the

> Hooks class. Some relevant info:
>
> /**
>  * Hooks class.
>  *
>  * Used to supersede $wgHooks, because globals are EVIL.
>  *
>  * @since 1.18
>  */
>
>
https://github.com/wikimedia/mediawiki-core/blob/master/includes/Hooks.php#L30

>
> I personally find the comment hilarious and hope you see why when looking
> at the "class". Looks like usage in core and extensions is not to
> extensive, so switching to something more sane seems quite feasible.
>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Can this please please please be done *after* my patch clarifying hook
execution logic is merged? I'll include a link when I'm on my desktop, but
if I have to rebase it again it's never going to get through.

Also, what alternative implementation are you considering?
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
In reply to this post by Jeroen De Dauw-2
On Wed, 03 Apr 2013 18:51:54 -0700, Jeroen De Dauw  
<[hidden email]> wrote:

> Hey,
>
> I'm curious what the list thinks of deprecating and eventually removing  
> the Hooks class.

I see no reason to get rid of the hooks class. We use static classes other  
places in core. And there's no reason to revert to hideous functions like  
we had before. There's enough code logic there to justify packaging it  
into a static class.

Interfaces like these have really slow uptake because extensions always  
wait a long time to pick them up because using them fundamentally means  
dropping compatibility with a version of MW earlier than the one it was  
introduced in.

Hooks was only added in 1.18 and extensions have a habit of retaining  
compatibility for old versions of MediaWiki for a significant time even  
after we make that version EOL. It's not unexpected to see extensions not  
using the interface yet.


Quite frankly:
Hooks::register( 'BeforePageDisplay', 'MyExt::pageDisplay' );

Is quite nicer than the backcompat:
$wgHooks['BeforePageDisplay'][] = 'MyExt::pageDisplay';

In the event of a global typo it'll error out instead of silently not  
working. The argument structure is cleaner and you can't inadvertently  
break everything by forgetting to add the "[]" which to the casual  
extension author may not be totally apparent.
Oh... ;) and no spending hours trying to find out why your hook isn't  
being called cause you moved your hook call to an extension function so  
you could vary by user config but forgot to add `global $wgHooks;` to your  
function.
If in the future we require core and extensions to register the hooks they  
call it also leaves the possibility of warning extension authors when they  
typo a hook name, with a proper trace where they made the mistake.

And it gives us room to consider the possibility of doing something like  
turning:
Hooks::register( 'BeforePageDisplay', array( 'MyExt::pageDisplay', $data )  
);

Into just:
Hooks::register( 'BeforePageDisplay', 'MyExt::pageDisplay', $data );


> ""Used to supersede $wgHooks, because globals are EVIL.""
>
> I personally find the comment hilarious and hope you see why when looking
> at the "class". Looks like usage in core and extensions is not to
> extensive, so switching to something more sane seems quite feasible.

Btw, I hope you're not finding the comment funny by misreading "Used" as  
"In the past" when it's actually the action "to use".

> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Jeroen De Dauw-2
Hey,

> I see no reason to get rid of the hooks class.

Given you also do not understand why I think the comment is funny, I
recommend you read up on why writing static code is harmful. And on how
global state can hide in static "classes".

> We use static classes other places in core.

https://yourlogicalfallacyis.com/bandwagon

In almost all such cases I have seen in core this kind of use of static is
bad.

> And there's no reason to revert to hideous functions like we had before.

No one is suggesting that.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Dmitriy Sintsov

> 4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw ([hidden email]) написал:
>
> Hey,
> > I see no reason to get rid of the hooks class.
> Given you also do not understand why I think the comment is funny, I
> recommend you read up on why writing static code is harmful. And on how
> global state can hide in static "classes".
> > We use static classes other places in core.
> https://yourlogicalfallacyis.com/bandwagon
> In almost all such cases I have seen in core this kind of use of static is
> bad.
> > And there's no reason to revert to hideous functions like we had before.
> No one is suggesting that.
> Cheers
> --
>
Why the hooks should not be static? Multi-site (farm) built-in support in core without $wgConf? Common page table across multiple sites?
Dmitriy

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov <[hidden email]>  
wrote:

>
>> 4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw  
>> ([hidden email]) написал:
>>  Hey,
>> > I see no reason to get rid of the hooks class.
>> Given you also do not understand why I think the comment is funny, I
>> recommend you read up on why writing static code is harmful. And on how
>> global state can hide in static "classes".
>> > We use static classes other places in core.
>> https://yourlogicalfallacyis.com/bandwagon
>> In almost all such cases I have seen in core this kind of use of static  
>> is
>> bad.
>> > And there's no reason to revert to hideous functions like we had  
>> before.
>> No one is suggesting that.
>> Cheers
>> --
>>
> Why the hooks should not be static? Multi-site (farm) built-in support  
> in core without $wgConf? Common page table across multiple sites?
> Dmitriy

How do you envision non-static hooks working and supporting multiple wikis?

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Dmitriy Sintsov

> 4 Апрель 2013 г. 10:11:44 пользователь Daniel Friesen ([hidden email]) написал:
>
> On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov <[hidden email]>    
> wrote:
> >
> >> 4 Апрель 2013 г. 9:16:49 пользовате­ль Jeroen De Dauw    
> >> ([hidden email]) написал:
> >>    Hey,
> >> > I see no reason to get rid of the hooks class.
> >> Given you also do not understand why I think the comment is funny, I
> >> recommend you read up on why writing static code is harmful. And on how
> >> global state can hide in static "classes".
> >> > We use static classes other places in core.
> >> https://yourlogicalfallacyis.com/bandwagon
> >> In almost all such cases I have seen in core this kind of use of static    
> >> is
> >> bad.
> >> > And there's no reason to revert to hideous functions like we had    
> >> before.
> >> No one is suggesting that.
> >> Cheers
> >> --
> >>
> > Why the hooks should not be static? Multi-site (farm) built-in support    
> > in core without $wgConf? Common page table across multiple sites?
> > Dmitriy
> How do you envision non-static hooks working and supporting multiple wikis?
>
If hooks will be non-static, should the hooks become the members of RequestContext, maybe?
Dmitriy

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
On Wed, 03 Apr 2013 23:43:20 -0700, Dmitriy Sintsov <[hidden email]>  
wrote:

>
>> 4 Апрель 2013 г. 10:11:44 пользователь Daniel Friesen  
>> ([hidden email]) написал:
>>  On Wed, 03 Apr 2013 22:23:41 -0700, Dmitriy Sintsov  
>> <[hidden email]>   wrote:
>> >
>> >> 4 Апрель 2013 г. 9:16:49 пользователь Jeroen De Dauw   >>  
>> ([hidden email]) написал:
>> >>    Hey,
>> >> > I see no reason to get rid of the hooks class.
>> >> Given you also do not understand why I think the comment is funny, I
>> >> recommend you read up on why writing static code is harmful. And on  
>> how
>> >> global state can hide in static "classes".
>> >> > We use static classes other places in core.
>> >> https://yourlogicalfallacyis.com/bandwagon
>> >> In almost all such cases I have seen in core this kind of use of  
>> static   >> is
>> >> bad.
>> >> > And there's no reason to revert to hideous functions like we had    
>> >> before.
>> >> No one is suggesting that.
>> >> Cheers
>> >> --
>> >>
>> > Why the hooks should not be static? Multi-site (farm) built-in  
>> support   > in core without $wgConf? Common page table across multiple  
>> sites?
>> > Dmitriy
>> How do you envision non-static hooks working and supporting multiple  
>> wikis?
>>
> If hooks will be non-static, should the hooks become the members of  
> RequestContext, maybe?
> Dmitriy

No, hooks are not a request thing. Hooks are at a level more global than  
the request context and are also relevant in places where there is no  
request context such as maintenance scripts, parsing, and things that  
should be isolated and not tied to a request.

RequestContext also uses the hook system.

Think of it this way. A request context is for a request. Pretending we  
handle multiple requests in one script run we would have a separate  
request for each. However hooks are something done at the level of  
extensions. The level this part of extensions are part of is environment  
init, along with the loading of executable code into memory. You do this  
once at the start of the script execution. Not each request.
If we were to run MediaWiki in a daemon like way of serving requests like  
python and ruby support where the application is loaded into a process and  
request after request is passed to it. We'd still load hooks once at the  
start not once per request. (and we'd probably kill off the lame stuff we  
have to do to avoid stuff from being initialized when it's not used in a  
particular request since in a daemon it's only initialized once).

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Tyler Romeo
I still fully maintain that entirely static classes is the most useless
thing and is just an extremely crude method of hiding global context. We're
using PHP 5.3 in the core, might as well just use namespaces at that point,
because that's what a static class is: a namespace with global variables
and functions. It entirely defeats the purpose of object oriented
programming.

Nonetheless, I don't see any other good way to implement Hooks other than
as a global state. Even though there are times where hooks are executing in
a context, like Daniel said, there are times where they are not, e.g.,
maintenance scripts or any other place outside the normal request/response
workflow.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Max Semenik
On 04.04.2013, 16:04 Tyler wrote:

> I still fully maintain that entirely static classes is the most useless
> thing and is just an extremely crude method of hiding global context. We're
> using PHP 5.3 in the core, might as well just use namespaces at that point,
> because that's what a static class is: a namespace with global variables
> and functions. It entirely defeats the purpose of object oriented
> programming.

There's a difference: static classes can have private variables,
allowing to hide implementation.

--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Chad
On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik <[hidden email]> wrote:

> On 04.04.2013, 16:04 Tyler wrote:
>
>> I still fully maintain that entirely static classes is the most useless
>> thing and is just an extremely crude method of hiding global context. We're
>> using PHP 5.3 in the core, might as well just use namespaces at that point,
>> because that's what a static class is: a namespace with global variables
>> and functions. It entirely defeats the purpose of object oriented
>> programming.
>
> There's a difference: static classes can have private variables,
> allowing to hide implementation.
>

And variables inside a global function are also scoped, so they
don't leak implementation either. The point is semi-valid for
functions, though.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Max Semenik
On 04.04.2013, 19:17 Chad wrote:

> On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik <[hidden email]> wrote:
>> On 04.04.2013, 16:04 Tyler wrote:
>>
>>> I still fully maintain that entirely static classes is the most useless
>>> thing and is just an extremely crude method of hiding global context. We're
>>> using PHP 5.3 in the core, might as well just use namespaces at that point,
>>> because that's what a static class is: a namespace with global variables
>>> and functions. It entirely defeats the purpose of object oriented
>>> programming.
>>
>> There's a difference: static classes can have private variables,
>> allowing to hide implementation.
>>

> And variables inside a global function are also scoped, so they
> don't leak implementation either. The point is semi-valid for
> functions, though.

Yeah, but what if you need more than one global function? ;)

--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Chad
On Thu, Apr 4, 2013 at 11:28 AM, Max Semenik <[hidden email]> wrote:

> On 04.04.2013, 19:17 Chad wrote:
>
>> On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik <[hidden email]> wrote:
>>> On 04.04.2013, 16:04 Tyler wrote:
>>>
>>>> I still fully maintain that entirely static classes is the most useless
>>>> thing and is just an extremely crude method of hiding global context. We're
>>>> using PHP 5.3 in the core, might as well just use namespaces at that point,
>>>> because that's what a static class is: a namespace with global variables
>>>> and functions. It entirely defeats the purpose of object oriented
>>>> programming.
>>>
>>> There's a difference: static classes can have private variables,
>>> allowing to hide implementation.
>>>
>
>> And variables inside a global function are also scoped, so they
>> don't leak implementation either. The point is semi-valid for
>> functions, though.
>
> Yeah, but what if you need more than one global function? ;)
>

It makes it easier to support PHP4.

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
In reply to this post by Chad
The case for a static class I see:

Over functions:
* Uses the AutoLoader when needed, no explicit require
* Nicely groups the entire implementation of hooks into a compartment

Over namespaced functions:
* Uses the AutoLoader when needed, no explicit require
* Gives us proper state across methods when we need it. Last I checked PHP  
does not allow namespace scoped semi-globals.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
In reply to this post by Jeroen De Dauw-2
On Wed, 03 Apr 2013 22:15:27 -0700, Jeroen De Dauw
<[hidden email]> wrote:

> Hey,
>
>> I see no reason to get rid of the hooks class.
>
> Given you also do not understand why I think the comment is funny, I
> recommend you read up on why writing static code is harmful. And on how
> global state can hide in static "classes".

Maybe you should try linking to a specific reason.

I understand perfectly fine that globals and static classes both have
global state. But I also understand that classes even when static still
have advantages over functions and global variables.

Hook registration is a matter of connecting core code paths to extension
code paths. It is pretty much inherently a static operation.

I was also trying to make sure that you were in fact commenting on
"globals are evil" and not mistaking "Used to supersede $wgHooks" for
something like "This was written to supersede $wgHooks but no-one uses it
so it doesn't supersede $wgHooks anymore".


>> We use static classes other places in core.
>
> https://yourlogicalfallacyis.com/bandwagon
>
> In almost all such cases I have seen in core this kind of use of static  
> is bad.

Linker, Html, and Xml included?

MWNamespace could use some instance methods.

But registering hooks is pretty much a static operation when extensions
themselves are basically static things that we don't load as an instance.

In any case you're cherry picking sentences from a paragraph of things
that belong together. That borders on
https://yourlogicalfallacyis.com/strawman and maybe
https://yourlogicalfallacyis.com/the-fallacy-fallacy

I never implied that just because we use static classes elsewhere in core
that it alone was a reason to use a static class.
"We use static classes other places in core. And there's no reason to
revert to hideous functions like we had before."
Was supposed to be read together. And was meant to indicate that using
static methods instead of functions is not out of step with our coding
guidelines.


>> And there's no reason to revert to hideous functions like we had before.
>
> No one is suggesting that.

Then instead of talking about removing the Hooks class why don't you try
instead talking about what kind of hooks system we should create to
supersede the Hooks class.

Usually when someone talks about deprecating and "removing" something
static that replaces something static they're not talking about replacing
it with something non-static. Nothing about your message read as "Lets
replace Hooks with something non-static". It read much more clearly as "No
one is using Hooks, how about we kill it".


> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
In reply to this post by Jeroen De Dauw-2
On Wed, 03 Apr 2013 22:15:27 -0700, Jeroen De Dauw
<[hidden email]> wrote:

> Hey,
>
>> I see no reason to get rid of the hooks class.
>
> Given you also do not understand why I think the comment is funny, I
> recommend you read up on why writing static code is harmful. And on how
> global state can hide in static "classes".

Maybe you should try linking to a specific reason.

I understand perfectly fine that globals and static classes both have
global state. But I also understand that classes even when static still
have advantages over functions and global variables.

Hook registration is a matter of connecting core code paths to extension
code paths. It is pretty much inherently a static operation.

I was also trying to make sure that you were in fact commenting on
"globals are evil" and not mistaking "Used to supersede $wgHooks" for
something like "This was written to supersede $wgHooks but no-one uses it
so it doesn't supersede $wgHooks anymore".


>> We use static classes other places in core.
>
> https://yourlogicalfallacyis.com/bandwagon
>
> In almost all such cases I have seen in core this kind of use of static  
> is bad.

Linker, Html, and Xml included?

MWNamespace could use some instance methods.

But registering hooks is pretty much a static operation when extensions
themselves are basically static things that we don't load as an instance.

In any case you're cherry picking sentences from a paragraph of things
that belong together. That borders on
https://yourlogicalfallacyis.com/strawman and maybe
https://yourlogicalfallacyis.com/the-fallacy-fallacy

I never implied that just because we use static classes elsewhere in core
that it alone was a reason to use a static class.
"We use static classes other places in core. And there's no reason to
revert to hideous functions like we had before."
Was supposed to be read together. And was meant to indicate that using
static methods instead of functions is not out of step with our coding
guidelines.


>> And there's no reason to revert to hideous functions like we had before.
>
> No one is suggesting that.

Then instead of talking about removing the Hooks class why don't you try
instead talking about what kind of hooks system we should create to
supersede the Hooks class.

Usually when someone talks about deprecating and "removing" something
static that replaces something static they're not talking about replacing
it with something non-static. Nothing about your message read as "Lets
replace Hooks with something non-static". It read much more clearly as "No
one is using Hooks, how about we kill it".


> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

vitalif
In reply to this post by Jeroen De Dauw-2
> Hey,
>
> I'm curious what the list thinks of deprecating and eventually
> removing the
> Hooks class. Some relevant info:
>
> /**
>  * Hooks class.
>  *
>  * Used to supersede $wgHooks, because globals are EVIL.
>  *
>  * @since 1.18
>  */
>
>
> https://github.com/wikimedia/mediawiki-core/blob/master/includes/Hooks.php#L30
>
> I personally find the comment hilarious and hope you see why when
> looking
> at the "class". Looks like usage in core and extensions is not to
> extensive, so switching to something more sane seems quite feasible.

I second that!

Also I have an idea: maybe it would be good for mediawiki it the
"initialisation state" along with all constants/global
variables/extension metadata/preinitialised parser/preloaded PHP files,
could be cached somewhere as the whole and just loaded on each request
instead of being sequentially initialised? (extension metadata =
hooks/special pages/i18n files/resource modules/credits/etc)
If it's a good idea then I think sequential setting of hooks via a
method call is not that good? (because hooks become even less
"declarative"?)
Or it's not worth it and the initialisation overhead is small?


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Daniel Friesen-2
On Thu, 04 Apr 2013 13:57:42 -0700, <[hidden email]> wrote:

> I second that!
>
> Also I have an idea: maybe it would be good for mediawiki it the  
> "initialisation state" along with all constants/global  
> variables/extension metadata/preinitialised parser/preloaded PHP files,  
> could be cached somewhere as the whole and just loaded on each request  
> instead of being sequentially initialised? (extension metadata =  
> hooks/special pages/i18n files/resource modules/credits/etc)
> If it's a good idea then I think sequential setting of hooks via a  
> method call is not that good? (because hooks become even less  
> "declarative"?)
> Or it's not worth it and the initialisation overhead is small?

You can't cache program state and loaded code like that in PHP. We  
explicitly have to abuse the autoloader and develop other patterns to  
avoid loading unused portions of code because if we don't our  
initialization is unreasonably long.

In other languages of course like python and ruby. The application runs  
more like a daemon. Initialization can be done once when the program  
starts up. Then many requests are handled by the same process.
But PHP pretends to be CGI even when not CGI.

HipHop is an improvement. But we're not quite there yet and most people  
probably won't try using it or need it.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Hooks class

Tyler Romeo
On Thu, Apr 4, 2013 at 9:22 PM, Daniel Friesen
<[hidden email]>wrote:

> In other languages of course like python and ruby. The application runs
> more like a daemon. Initialization can be done once when the program starts
> up. Then many requests are handled by the same process.
> But PHP pretends to be CGI even when not CGI.
>
> HipHop is an improvement. But we're not quite there yet and most people
> probably won't try using it or need it.
>

*sigh* how I wish PHP would do something like Python and Ruby. Also, does
MW even work at all with HipHop anymore?

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12