IRCLogs20110127 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110127

lsmith (IP:
01/27/11 18:07:56 (7 years ago)



  • IRCLogs20110127

    v0 v1  
     1= Summary = 
     5== Supporting Doctrine2 in Form/Validator == 
     7== Bundle namespace naming conventions == 
     9== Current state towards RC1 == 
     11== Problems with the design of DI extensions Options == 
     13== Symfony 2's intl extension requirement == 
     15= IRC logs = 
     17Jan 27 11:00:47 <lsmith>        meeting time 
     18Jan 27 11:01:01 <henrikbjorn^ipad>      No beberlei? Damm 
     19Jan 27 11:01:02 <lsmith>        bschussek: are you around? 
     20Jan 27 11:01:03 <lsmith>        [RFC] Supporting Doctrine2 in Form/Validator: 
     21Jan 27 11:01:10 <bschussek>     lsmith: yep 
     22Jan 27 11:01:19 <henrikbjorn^ipad>      Fabpot around? 
     23Jan 27 11:01:22 <fabpot>        yep 
     24Jan 27 11:01:47 *       ozmerk has quit (Ping timeout: 240 seconds) 
     25Jan 27 11:01:58 <henrikbjorn^ipad>      Awesome because i cant type really so both sides is repreented i think 
     26Jan 27 11:02:00 <lsmith>        bschussek: could you introduce the topic to us? 
     27Jan 27 11:02:53 <bschussek>     yes 
     28Jan 27 11:03:09 <lsmith>        i guess there is a pull that goes with this 
     29Jan 27 11:03:19 <bschussek>     the question is whether and how we bundle code that integrates third party libraries in the framework 
     30Jan 27 11:03:21 <henrikbjorn^ipad>      And the ml 
     31Jan 27 11:03:43 <bschussek>     for example, Doctrine DBAL support in the Security component, Doctrine support in the Form component 
     32Jan 27 11:04:18 <bschussek>     right now, these supporting classes are bundled directly in the components. the reason for this is that developers using other frameworks can use the components without limitations 
     33Jan 27 11:04:39 <bschussek>     so far, we identified three alternatives: 
     34Jan 27 11:04:47 <bschussek>     1. do it as it is now, leave the code in the components 
     35Jan 27 11:05:05 <fabpot>        but we also need to keep in mind that not so many people use the components without the framework 
     36Jan 27 11:05:14 <bschussek>     2. push the code in separate subnamespaces in the components (e.g. Form\Extension\Symfony) 
     37Jan 27 11:05:35 <bschussek>     3. use a separate global namespace (e.g. Symfony\Extension\Doctrine\Security\... etc.) 
     38Jan 27 11:05:59 <bschussek>     fabpot: right now this is true. But if we make it easier for other people to use the components, we attract more people to the framework 
     39Jan 27 11:06:03 <fabpot>        we know that 1. works well 
     40Jan 27 11:06:14 <bschussek>     this is how Liip came to Symfony2, and now they contribute a lot 
     41Jan 27 11:06:16 <henrikbjorn^ipad>      I say in the bundles they follow the naming standard, they are small libs ofbtheir own 
     42Jan 27 11:06:48 <fabpot>        my fear with the other solutions is that we will still need to have things in bundles to have the benefit of the container, configuration, ... 
     43Jan 27 11:07:17 <henrikbjorn^ipad>      Like menubundle / gravatar bundle. The only thing that make a bundle not a component extension is the bundle class and dic extension 
     44Jan 27 11:07:17 *       tecbot has quit () 
     45Jan 27 11:07:50 <henrikbjorn^ipad>      If the stuff is kept in the components a bundle would basically onlu be the dic config 
     46Jan 27 11:08:03 <bschussek>     henrikbjorn: exactly 
     47Jan 27 11:08:05 <henrikbjorn^ipad>      With the exception of an apps main bundle 
     48Jan 27 11:08:07 <lsmith>        well a bundle should always be "simple" glue but very Symfony2 specific 
     49Jan 27 11:08:16 <henrikbjorn^ipad>      Lsmith? Why 
     50Jan 27 11:08:20 <lsmith>        but Bundle's might contain code that could be reused 
     51Jan 27 11:08:28 <lsmith>        if it gets to the point where its a lot of code 
     52Jan 27 11:08:36 <lsmith>        its time to move it to a lib 
     53Jan 27 11:08:38 <johanness>     henrikbjorn^ipad, not really a bundle can have dic aware classes, components should not have them 
     54Jan 27 11:08:44 <henrikbjorn^ipad>      Menubundle is a good example i wouldnt have a sep lib for that and a bundle besides it 
     55Jan 27 11:08:50 <lsmith>        like assetic .. 
     56Jan 27 11:09:11 <bschussek>     henrikbjorn^ipad: but if it grows a lot, it would make sense to extract that code into a seperately usable library 
     57Jan 27 11:09:13 <lsmith>        or Ariadne 
     58Jan 27 11:09:13 *       ozmerk (~merk@ has joined #symfony-dev 
     59Jan 27 11:09:17 *       srohweder ( has joined #symfony-dev 
     60Jan 27 11:09:17 <bschussek>     maybe we can proceed clarifying our view of "bundles" and "components" 
     61Jan 27 11:09:31 <henrikbjorn^ipad>      Why isnt beberlei here 
     62Jan 27 11:09:33 *       johnkary (~johnkary@ has joined #symfony-dev 
     63Jan 27 11:09:42 <henrikbjorn^ipad>      A bundle is the same as an extension 
     64Jan 27 11:09:48 <bschussek>     are bundles Symfony2 specific, the "glue" and components the "libraries"? 
     65Jan 27 11:09:48 <lsmith>        but a comonent is reuseable code indepent of Symfony2 .. a bundle isnt 
     66Jan 27 11:09:56 <henrikbjorn^ipad>      And they coumd and should be reused 
     67Jan 27 11:10:26 <bschussek>     henrikbjorn^ipad: but what (from a point of advertisement) is then the difference between bundles and components? 
     68Jan 27 11:10:29 <henrikbjorn^ipad>      Lsmith if doctrine depemdency is in a component it is not independent 
     69Jan 27 11:10:34 *       Dominique_ ( has joined #symfony-dev 
     70Jan 27 11:10:54 <henrikbjorn^ipad>      Components = self contained no outside requirements 
     71Jan 27 11:11:16 <bschussek>     that's not true. some components depend on other components 
     72Jan 27 11:11:27 <fabpot>        henrikbjorn^ipad: yes, no *mandatory* requirements, but we can have *optional* ones for very specific features 
     73Jan 27 11:11:30 <henrikbjorn^ipad>      And a bbundle provide extensions and easy development for them. All of the framework is an extension to the components 
     74Jan 27 11:11:38 <bulatshakirzyano>      form depends on validator, is it optional? 
     75Jan 27 11:11:43 <bschussek>     no 
     76Jan 27 11:12:03 <henrikbjorn^ipad>      Fabot the size will also be massive and have stuff you dont need 
     77Jan 27 11:12:07 <fabpot>        bulatshakirzyano: ok, but Form without Validator does not make any sense 
     78Jan 27 11:12:31 <fabpot>        henrikbjorn^ipad: I'm not arguing one way or the other. I really see pros and cons in all solutions 
     79Jan 27 11:12:37 <henrikbjorn^ipad>      If we add doctrine orm odm propel pcr couchdb should also be in the core namespace 
     80Jan 27 11:12:46 <fabpot>        I just think that solution 2 is the worst one 
     81Jan 27 11:12:50 <bschussek>     henrikbjorn^ipad: why? we would need someone to maintain that 
     82Jan 27 11:13:12 <Seldaek>       henrikbjorn^ipad: you gotta stop worrying about having 10 files more or less on your disk 
     83Jan 27 11:13:17 <henrikbjorn^ipad>      Its widely used in sf2 the odm at least 
     84Jan 27 11:13:31 <bschussek>     henrikbjorn^ipad: again, that's not the question. we need a maintainer 
     85Jan 27 11:13:33 <henrikbjorn^ipad>      Seldeak it wont be just 19 files 
     86Jan 27 11:13:36 <henrikbjorn^ipad>      10 
     87Jan 27 11:13:40 <fabpot>        henrikbjorn^ipad and bschussek have a point: everything we add need to be maintained 
     88Jan 27 11:13:44 <Seldaek>       henrikbjorn^ipad: well, 1000 files, who cares 
     89Jan 27 11:13:46 <bulatshakirzyano>      I think if form depends on validator and everyone accepts that, maybe solution #1 isn't that bad 
     90Jan 27 11:13:56 *       ozmerk has quit (Ping timeout: 250 seconds) 
     91Jan 27 11:14:08 <bulatshakirzyano>      its at least consistent and works for what we need now 
     92Jan 27 11:14:12 <lsmith>        ok .. we are reaching the end of the timebox 
     93Jan 27 11:14:19 <lsmith>        is there anything we can conclude at this point? 
     94Jan 27 11:14:27 <fabpot>        bulatshakirzyano: there is a big difference between dependencies between OUR components and with EXTERNAL dependencies 
     95Jan 27 11:14:28 <henrikbjorn^ipad>      It is way easier to remove a bundle than a component core thing because someone stops maintaining it 
     96Jan 27 11:14:40 *       ozmerk (~merk@ has joined #symfony-dev 
     97Jan 27 11:14:45 <bulatshakirzyano>      fabpot true that 
     98Jan 27 11:14:56 <henrikbjorn^ipad>      See the probelbundle and securitybundle 
     99Jan 27 11:15:20 <Seldaek>       I think this is a topic best discussed on the ml honestly 
     100Jan 27 11:15:26 <henrikbjorn^ipad>      It is 
     101Jan 27 11:15:38 <bschussek>     since we can't really reach a consensus now, should we follow the current way for now? 
     102Jan 27 11:15:39 <fabpot>        but we won't find a consensus 
     103Jan 27 11:15:51 <henrikbjorn^ipad>      But the main problem is that there is a pull request now so we need a decision 
     104Jan 27 11:16:06 <henrikbjorn^ipad>      Bscussek no that is forcing your way 
     105Jan 27 11:16:21 <henrikbjorn^ipad>      And we are close to rc1 after that it wont be chnged 
     106Jan 27 11:16:33 <fabpot>        the current way is to put things in bundles 
     107Jan 27 11:16:44 <bulatshakirzyano>      fabpot +1 
     108Jan 27 11:17:04 <Seldaek>       the one thing I see is that DB/Storage stuff is the main issue, because that is where everyone uses different techs 
     109Jan 27 11:17:08 <bschussek>     fabpot: so move Dbal and the Form\Extension namespace from the components to DoctrineBundle? 
     110Jan 27 11:17:14 <bschussek>     *Security\Acl\Dbal 
     111Jan 27 11:17:18 <Seldaek>       so probably the DoctrineBundle should contain all the Doctrine specifics 
     112Jan 27 11:17:26 <henrikbjorn^ipad>      What was the reason for bundlr refctorin if not reuse outside? 
     113Jan 27 11:17:35 <bulatshakirzyano>      bschussek if there was a form bundle, it could go there 
     114Jan 27 11:17:42 <fabpot>        bschussek: yes 
     115Jan 27 11:17:58 <rande> henrikbjorn^ipad: easier to overwrite … 
     116Jan 27 11:18:00 <bschussek>     fabpot: ok, let's do it like this for now. we can continue the discussion on the ML 
     117Jan 27 11:18:05 <fabpot>        and ACL\DBAL should also be moved to SecurityBundle then 
     118Jan 27 11:18:10 <johanness>     -1 at least for the security unless there is very good reason for not having it in the component 
     119Jan 27 11:18:12 <rande> henrikbjorn^ipad: cleaner code 
     120Jan 27 11:18:26 <lsmith>        hmm ... so we are well over the timebox 
     121Jan 27 11:18:29 <johanness>     we are not providing integration there 
     122Jan 27 11:18:30 <fabpot>        johanness: this is really about consistency 
     123Jan 27 11:18:33 <lsmith>        should we cut the discussion here? 
     124Jan 27 11:18:37 <fabpot>        lsmith: yes 
     125Jan 27 11:18:45 <lsmith>        ok next topic then 
     126Jan 27 11:18:46 <lsmith>        [RFC] Bundle namespace naming conventions: 
     127Jan 27 11:19:47 <fabpot>        we need to determine the best practice for bundle namespaces 
     128Jan 27 11:20:11 <fabpot>        Sensio\FooBundle, Sensio\Bundle\FooBundle, Sensio\Symfony\Bundle\FooBundle, Sensio\SymfonyBundle\FooBundle 
     129Jan 27 11:20:20 <Seldaek>       and class names too it'd be nice to know if vendor is included or not 
     130Jan 27 11:20:22 <fabpot>        of course you can choose whatever you want, but which one do we prefer 
     131Jan 27 11:20:27 <henrikbjorn^ipad>      1 
     132Jan 27 11:20:38 <bschussek>     Sensio\FooBundle +1 
     133Jan 27 11:20:47 *       webPragmatist has quit (Quit: Leaving.) 
     134Jan 27 11:20:58 <fabpot>        Seldaek: I don't think we will change the name of bundles. They must be unique, so the vendor prefix is kind of mandatory 
     135Jan 27 11:21:07 <Seldaek>       ok 
     136Jan 27 11:21:07 *       rooster has quit (Read error: Connection reset by peer) 
     137Jan 27 11:21:34 <Seldaek>       I'd go for 1 too 
     138Jan 27 11:21:38 <iampersistent1>        personally I hate the redundant Bundles so I'm +1 on Sensio\FooBundle 
     139Jan 27 11:21:50 <Stof>  +1 for Sensio\FooBundle 
     140Jan 27 11:21:50 <fabpot>        also, we need to decide what we use in the documentation, which vendor? 
     141Jan 27 11:21:55 <Seldaek>       the rest is just duplicate info, Bundle implies it's symfony already, and having Bundle twice is useless 
     142Jan 27 11:22:13 <bschussek>     fabpot: can you give an example? 
     143Jan 27 11:22:15 <Seldaek>       fabpot: I guess Sensio is alright 
     144Jan 27 11:22:16 <jmikola|w>     lsmith: does this topic include beberlei's point about not reusing Zend as a top-level vendor namespace for things we (Symfonians) create? 
     145Jan 27 11:22:23 <henrikbjorn^ipad>      Sensio? 
     146Jan 27 11:22:26 <fabpot>        bschussek: an example for what? 
     147Jan 27 11:22:34 <bschussek>     ah you mean Sensio, Liip etc. ? 
     148Jan 27 11:22:45 <Seldaek>       yeah just what you use for code examples 
     149Jan 27 11:22:48 <fabpot>        Sensio is just a vendor example 
     150Jan 27 11:22:55 <bschussek>     sure 
     151Jan 27 11:22:56 <bulatshakirzyano>      Sension == Doctrine 
     152Jan 27 11:22:58 <bschussek>     I think Sensio is fine 
     153Jan 27 11:23:08 <bulatshakirzyano>      Sension\FooBundle +1 
     154Jan 27 11:23:23 *       bulatshakirzyano why is there an 'n' at the end? 
     155Jan 27 11:23:29 <fabpot>        bschussek: you mean the namespace for the doc? 
     156Jan 27 11:23:39 <bschussek>     fabpot: yes 
     157Jan 27 11:24:04 <fabpot>        so, to sum up, everybody agrees that the recommend way to name a bundle is Vendor\FooBundle 
     158Jan 27 11:24:07 <fabpot>        right? 
     159Jan 27 11:24:09 <jmikola|w>     bulatshakirzyano: i'm all for omitting Bundle\ in the namespace, beberlei brought up a point that Doctrine\WhateverBundle might not be published by Doctrine team directly, so it shouldn't use that as the top-level vendor 
     160Jan 27 11:24:09 <iampersistent1>        so I'm assuming that we could also do Vendor\Group\FooBundle 
     161Jan 27 11:24:15 <bschussek>     fabpot: +1 
     162Jan 27 11:24:22 <Seldaek>       fabpot: yes, Vendor\FooBundle\VendorFooBundle() 
     163Jan 27 11:24:30 <jmikola|w>     +1 
     164Jan 27 11:24:34 <bulatshakirzyano>      +1 
     165Jan 27 11:24:49 <fabpot>        ok, and Sensio\ as the vendor name for the doc and examples? 
     166Jan 27 11:24:56 <bschussek>     +1 
     167Jan 27 11:24:59 <henrikbjorn^ipad>      Ye 
     168Jan 27 11:25:00 <Seldaek>       jmikola|w: for the DoctrineBundle, if it's community based, I guess it can sit in the Symfony namespace? 
     169Jan 27 11:25:09 <bulatshakirzyano>      jmikola|w gotcha, in that case it could prob'ly be Vendor\Doctrine\BundleName, for third-party doctrine bundles 
     170Jan 27 11:25:19 <fabpot>        Seldaek: yes, it was just an example in my email, but this was misinterpreted 
     171Jan 27 11:25:21 <jmikola|w>     Seldaek: perhaps, beberlei's other example was regarding Zend bundles, too 
     172Jan 27 11:25:21 <lsmith>        yeah .. its Symfony\DoctrineBundle 
     173Jan 27 11:25:28 <fabpot>        lsmith: correct 
     174Jan 27 11:25:38 <fabpot>        lsmith: noooo, Symfony\Bundle\DoctrineBundle 
     175Jan 27 11:25:43 <Seldaek>       fabpot: yeah no problem, but we still have to clarify imo 
     176Jan 27 11:25:46 <bschussek>     lsmith: Symfony is a different case :) 
     177Jan 27 11:26:09 <jmikola|w>     would the bundle name still be SymfonyDoctrineBundle? or just DoctrineBundle? 
     178Jan 27 11:26:15 <lsmith>        hmm .. well using one recommended approach for docs ... and another in your own code is kinda wonky, no? 
     179Jan 27 11:26:15 <Seldaek>       yeah, it violates its own rules, but we love it anyways 
     180Jan 27 11:26:30 <lsmith>        eat your own dog food .. 
     181Jan 27 11:26:31 <fabpot>        jmikola|w: yes, we need the vendor for uniqueness 
     182Jan 27 11:26:44 <Seldaek>       lsmith: the doc can mention the optional category thing 
     183Jan 27 11:26:45 <jmikola|w>     ok, but Bundle\ part of the namespace can be omitted from the generated bundle name 
     184Jan 27 11:26:55 <bschussek>     fabpot: Can't we simply include the namespace? That would be much more elegant... but I guess that's a different topic 
     185Jan 27 11:27:30 <fabpot>        bschussek: what do you mean by "simply include the namespace"? 
     186Jan 27 11:27:47 <lsmith>        i guess we are in this trouble because we are not installing the components into the vendor dir 
     187Jan 27 11:28:04 <bschussek>     fabpot: when referring to a bundle, don't refer to @SensioFooBundle but @Sensio\FooBundle 
     188Jan 27 11:28:14 <lsmith>        then we wouldnt even think of Symfony\Bundle\DoctrineBundle 
     189Jan 27 11:28:17 <bschussek>     we need to resolve which bundles override this bundle either way 
     190Jan 27 11:28:18 <Seldaek>       jmikola|w, fabpot: also can't it be Vendor\FooBundle\VendorFoo ? don't really see the point in typing Bundle every time I want to refer to some resource or template name 
     191Jan 27 11:28:49 <Seldaek>       bschussek: that'd be awful imo for longer namespaces including one or two categories 
     192Jan 27 11:28:57 <jmikola|w>     Seldaek: it may work that way now... is Bundle suffix on the class name enforced (other than being a suggested convention? :) 
     193Jan 27 11:29:03 <Seldaek>       then the bundle name becomes really looong 
     194Jan 27 11:29:05 <lsmith>        ok .. approaching the end of the timebo 
     195Jan 27 11:29:07 <lsmith>        x 
     196Jan 27 11:29:19 <bschussek>     Seldaek: sure, but that's always the case if the bundle name must be unique 
     197Jan 27 11:29:22 <Seldaek>       jmikola|w: everything works, but what about making it the best practice? 
     198Jan 27 11:29:29 <fabpot>        jmikola|w: yes, you can omit the Bundle suffix if you want I think 
     199Jan 27 11:29:47 <Seldaek>       bschussek: no, the \Bundle\ part in the Symfony namespace is irrelevant to name clashes imo, so it shouldn't be in the name 
     200Jan 27 11:30:06 <jmikola|w>     Seldaek: i could see it conflicting with folks that like to put generic services in their top level bundle directory 
     201Jan 27 11:30:25 <bschussek>     Seldaek: the exception of the rule :) we just decided to recommend Vendor\FooBundle without Bundle\ for generic vendors 
     202Jan 27 11:30:33 <Seldaek>       jmikola|w: yes.. I suppose 
     203Jan 27 11:30:59 <Seldaek>       bschussek: yes but in this case what does it matter that we refer to bundles by fully qualified class name? the bundle class name is enough imo 
     204Jan 27 11:31:21 <bschussek>     Seldaek: because the bundle class name must be unique, and the fully qualified class name is always unique 
     205Jan 27 11:31:31 <Seldaek>       bschussek: if you introduce the full namespace in the name, then it goes boom if someone introduces a category namespace in their code 
     206Jan 27 11:31:41 <fabpot>        we have discussed bundle names, and I think there is no good reason to change the current naming convention 
     207Jan 27 11:31:50 <bschussek>     fabpot: ok 
     208Jan 27 11:31:53 <lsmith>        ok .. next topic 
     209Jan 27 11:31:56 <lsmith>        Current state towards RC1 
     210Jan 27 11:32:11 <lsmith>        i guess the big change is the addition of SecurityBundle 
     211Jan 27 11:32:35 <lsmith>        and a lot of refactoring that went into there 
     212Jan 27 11:32:54 <lsmith>        i guess we could release Symfony2 now .. with a stable API .. but unstable API for SecurityBundle? 
     213Jan 27 11:32:58 <fabpot>        let's make a long story short, I think you are all on the same page, except me 
     214Jan 27 11:33:26 <fabpot>        and after thinking about this a lot last night, the best decision is to change the RC1 date to March 6th 
     215Jan 27 11:33:31 <Seldaek>       yes, everyone would be happy to wait for SfLive Paris for the RC1 I guess, but then again it's not us that will burn on a stick for announcing the delay.. 
     216Jan 27 11:33:42 <Seldaek>       fabpot: awesome:) 
     217Jan 27 11:33:45 <fabpot>        it does not mean that we need to slow down 
     218Jan 27 11:33:53 <lsmith>        exactly 
     219Jan 27 11:33:54 *       Garfield-fr has quit (Quit:  ⏏) 
     220Jan 27 11:34:02 *       tecbot ( has joined #symfony-dev 
     221Jan 27 11:34:10 <fabpot>        let's try to have a RC1 that kicks asses 
     222Jan 27 11:34:19 <lsmith>        fabpot: and we will be releasing a stable API in paris then .. its marketing bla bla .. but :) 
     223Jan 27 11:34:20 <bschussek>     fabpot: +1 
     224Jan 27 11:34:33 <fabpot>        I'm about to freeze the low-level API 
     225Jan 27 11:34:45 <bulatshakirzyano>      fabpot +1 
     226Jan 27 11:34:47 <Seldaek>       kicking ass it does already, that's not the question :) 
     227Jan 27 11:34:58 <pgodel_work>   Seldaek: +1 
     228Jan 27 11:35:23 <lsmith>        fabpot: i would really like to see the DI inheritance pull from johanness to make it in 
     229Jan 27 11:35:23 <weaverryan>    aw shucks, it kicks ass because you all are kicking ass :) 
     230Jan 27 11:35:27 <iampersistent1>        +1, its not something you want to do prematurely.  Some people will be pissed, but in 6 months, everyone will have forgotten that month delay, but will be better off because of it 
     231Jan 27 11:35:37 <fabpot>        lsmith: that's not part of the low-level API, so that's fine 
     232Jan 27 11:35:39 <lsmith>        i also bulat's request changes .. 
     233Jan 27 11:35:54 <lsmith>        whats low level then? :) 
     234Jan 27 11:35:58 <Seldaek>       hehe 
     235Jan 27 11:35:59 <lsmith>        Kernel? 
     236Jan 27 11:36:02 *       henrikbjorn^ipad has quit (Ping timeout: 250 seconds) 
     237Jan 27 11:36:15 <bulatshakirzyano>      lsmith, that is not implemented in a likable way yet:) 
     238Jan 27 11:36:29 <fabpot>        the main interfaces for the MVC part: HttpKernelInterface, KernelInterface, EventDispatcherInterface, EventDispatcher, EngineInterface, ControllerResolver, ... 
     239Jan 27 11:36:31 <lsmith>        bulatshakirzyano: yeah .. i also liked kris's approach better 
     240Jan 27 11:36:31 *       henrikbjorn^ipad ( has joined #symfony-dev 
     241Jan 27 11:36:38 <fabpot>        ContainerInterface, ... 
     242Jan 27 11:36:46 <fabpot>        the API is only made of interfaces 
     243Jan 27 11:36:52 <bulatshakirzyano>      lsmith, I personally hate static methods, so I won't comment:) 
     244Jan 27 11:36:54 <fabpot>        this is the contract between Symfony2 and its developers 
     245Jan 27 11:36:58 <bulatshakirzyano>      static method === function 
     246Jan 27 11:37:19 <fabpot>        bulatshakirzyano: I think it's fine here are this is about managing the f***** PHP global vars 
     247Jan 27 11:37:23 <lsmith>        speaking of ControllerResolver .. is it still named correctly? 
     248Jan 27 11:37:31 <Seldaek>       bulatshakirzyano: but method without $this use === function, and many methods are like that 
     249Jan 27 11:37:32 <bulatshakirzyano>      fabpot true that again:) 
     250Jan 27 11:37:36 <fabpot>        lsmith: I think so 
     251Jan 27 11:38:10 <fabpot>        so, everybody is comfortable with RC1 in March? 
     252Jan 27 11:38:11 *       Ases (c2e0c8fe@gateway/web/freenode/ip. has joined #symfony-dev 
     253Jan 27 11:38:18 <pgodel_work>   +1 
     254Jan 27 11:38:22 <lsmith>        +1 
     255Jan 27 11:38:29 <iampersistent1>        +1 
     256Jan 27 11:38:31 <bulatshakirzyano>      _1 
     257Jan 27 11:38:32 <bulatshakirzyano>      Seldaek, yes, the main difference is that you don't know which methods your class depends on when you use statics, so the api is somewhat magical 
     258Jan 27 11:38:36 <bulatshakirzyano>      err +1 
     259Jan 27 11:38:41 <bschussek>     +1 
     260Jan 27 11:38:44 <lsmith>        so moving on .. Problems with the design of DI extensions Options: 
     261Jan 27 11:38:57 <lsmith>        bschussek: think thats another one of your threads 
     262Jan 27 11:39:17 <bschussek>     yes. currently, the DI extensions are a lot of untestable code by design 
     263Jan 27 11:39:32 <bschussek>     if we release this as is, people will use it as a template and do it the same way 
     264Jan 27 11:39:45 <bschussek>     since this is a critical part of every application, I think we need to improve this 
     265Jan 27 11:40:00 <bulatshakirzyano>      +1 
     266Jan 27 11:40:16 <bschussek>     bulatshakirzyano made the excellent suggestion to move much of the logic to factories 
     267Jan 27 11:40:22 <johanness>     why is it untestable? 
     268Jan 27 11:40:35 <bschussek>     johanness: because there is too much happening inside 
     269Jan 27 11:40:45 <fabpot>        bschussek: -1 
     270Jan 27 11:40:46 <bulatshakirzyano>      the premise is simple - those extension creata services dynamically 
     271Jan 27 11:40:50 <johanness>     you can break that down into methods can't you? 
     272Jan 27 11:40:56 <bulatshakirzyano>      *create 
     273Jan 27 11:41:08 <bulatshakirzyano>      what do you use to create other objects? 
     274Jan 27 11:41:11 <bulatshakirzyano>      factories 
     275Jan 27 11:41:11 <fabpot>        weaverryan's work is interesting 
     276Jan 27 11:41:18 <jmikola|w>     johanness: one problem is even after ensuring configLoad() runs only once, the order of things still matters - extensions create services, so if your own bundle extension runs after and tries to override something, it gets ignored 
     277Jan 27 11:41:24 <bschussek>     fabpot: where can I find that? 
     278Jan 27 11:41:27 <fabpot>        bulatshakirzyano: please, don't add yet another layer 
     279Jan 27 11:41:49 <bulatshakirzyano>      fabpot not to the container, this should be the responsibility of the bundle, that creates dynamic services 
     280Jan 27 11:41:56 *       henrikbjorn^ipad has quit () 
     281Jan 27 11:42:09 <fabpot>        bulatshakirzyano: what is a "dynamic service"? 
     282Jan 27 11:42:11 <jmikola|w>     should extensions just do parameter processing, and leave the service definition construction (setting arguments and such) to compiler passes? 
     283Jan 27 11:42:14 *       henrikbjorn ( has joined #symfony-dev 
     284Jan 27 11:42:21 <weaverryan>    bschussek: work-in-progress 
     285Jan 27 11:42:24 <bulatshakirzyano>      fabpot, so doctrine bundle allows many document managers for example 
     286Jan 27 11:42:27 <fabpot>        jmikola|w: I think there is no simple answer: it depends 
     287Jan 27 11:42:35 <bulatshakirzyano>      each is registered in its own services it 
     288Jan 27 11:42:53 <bulatshakirzyano>      default_document_manager === document manager with name 'default' 
     289Jan 27 11:43:04 <fabpot>        bulatshakirzyano: what's the problem? 
     290Jan 27 11:43:06 <weaverryan>    I don't see a problem with that 
     291Jan 27 11:43:15 <weaverryan>    but default_document_manager should not be a DI parameter 
     292Jan 27 11:43:20 <jmikola|w>     from a unit testing perspective, single-purpose compiler passes are pretty straight-foward to test; meanwhile, i'm writing unit tests for FrameworkExtension and it's quite hairy - i imagine securityExtension would be equally so :) 
     293Jan 27 11:43:21 <weaverryan>    it should be a DI extension class option only 
     294Jan 27 11:43:33 *       webPragmatist (~webby@ has joined #symfony-dev 
     295Jan 27 11:43:33 *       webPragmatist has quit (Changing host) 
     296Jan 27 11:43:33 *       webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev 
     297Jan 27 11:44:04 <johanness>     jmikola|w: depends ;) 
     298Jan 27 11:44:12 <fabpot>        what about refactoring the current extensions (see weaverryan work, and the new single call to the config method) and then talk about that later 
     299Jan 27 11:44:26 <bschussek>     weaverryan: could you shortly sum up the benefit of your refactoring? 
     300Jan 27 11:44:28 <bulatshakirzyano>      agreed 
     301Jan 27 11:44:31 <fabpot>        I'm pretty sure, they will be much more easier to understand and to test 
     302Jan 27 11:44:57 <jmikola|w>     i will hopefully be done with FrameworkExtension today (finishing up tests and doing merging) - i'll run through ryan's work before i finish up though 
     303Jan 27 11:45:02 <lsmith>        i also think that with johanness's work on DI inheritance .. we can get rid of some code in the Extensions 
     304Jan 27 11:45:05 <jmikola|w>     lots of good stuff in his pull request 
     305Jan 27 11:45:12 <weaverryan>    The end-result of the refactoring is to remove $container->getParameter() calls from an DI extension class - because if you're using a DI parameter that early, it's not overrideable properly 
     306Jan 27 11:45:30 <bulatshakirzyano>      weaverryan +1 one on spotting that 
     307Jan 27 11:45:42 <bschussek>     weaverryan: thanks 
     308Jan 27 11:45:45 <weaverryan>    it means that some parameters are moved into the class itself - because they were never really been used as parameters in the first place (weren't overridable per the above) 
     309Jan 27 11:46:15 <Seldaek>       fabpot: also another Extension-related issue; there are still those two xml specific methods that imo are a bit pointless, they should be made part of another interface for those that want to implement an xsd etc, otherwise you end up entering junk in the return values and it's not clean either. I can prepare a pull if you're ok with the idea 
     310Jan 27 11:46:22 <fabpot>        weaverryan: jmikola|w: Can you work together to refactor the FrameworkExtension with your ideas? 
     311Jan 27 11:46:41 <weaverryan>    absolutely - I'll first remove the parameter overriding from my pull request that you commented on 
     312Jan 27 11:47:13 <bschussek>     is it possible to abstract the assignment of configuration variables to DI parameteres? there is a lot of code duplication on that part right now 
     313Jan 27 11:47:37 <Stof>  bschussek: see FOS UserBundle 
     314Jan 27 11:47:42 <jmikola|w>     fabpot: will do, i'm anxious to get some extra eyes on my current progress 
     315Jan 27 11:47:56 <Stof>  the remapParameter method makes a good job for this 
     316Jan 27 11:48:08 <lsmith>        bschussek: 
     317Jan 27 11:48:21 <lsmith>        thats the code FOS\UserBundle uses 
     318Jan 27 11:48:32 <lsmith>        ok .. next topic? 
     319Jan 27 11:48:41 <Stof>  (and that I copy/paste in my own extensions) 
     320Jan 27 11:48:48 *       dustinwhittle ( has joined #symfony-dev 
     321Jan 27 11:48:56 <lsmith>        trying to be impartial .. view and intl both got 6 votes .. so since i prefer view, we are going with intl 
     322Jan 27 11:48:58 <lsmith>        Symfony 2's intl extension requirement: 
     323Jan 27 11:48:58 <weaverryan>    If we standardize all the DI extensions, any helper methods will become very apparent and can easily be added later without affecting BC 
     324Jan 27 11:49:04 *       ozmerk has quit (Ping timeout: 246 seconds) 
     325Jan 27 11:49:27 <jmikola|w>     is a wrapping class for Locale stuff still in the works? i recall a post from bschussek about that on ML last week 
     326Jan 27 11:49:39 <bschussek>     jmikola|w: yes 
     327Jan 27 11:49:41 <fabpot>        weaverryan: +1 
     328Jan 27 11:49:42 <jmikola|w>     meanwhile, i did spot on hard dep to \Locale in FrameworkExtension :) 
     329Jan 27 11:49:46 <lsmith>        yeah .. i think its however pontless to create a wrapper 
     330Jan 27 11:49:53 <lsmith>        just implement intl .. 
     331Jan 27 11:50:10 <bschussek>     Eriksen Costa is currently working on that, Tom Boutell also offered his help 
     332Jan 27 11:50:12 <lsmith>        if other people do not check if the ext is loaded and then think they have a real intl loaded 
     333Jan 27 11:50:14 <eriksencosta>  lsmith: implement intl in PHP code? 
     334Jan 27 11:50:16 <lsmith>        then its theur fault 
     335Jan 27 11:50:17 <bschussek>     lsmith: -1 
     336Jan 27 11:50:32 <bschussek>     we can't expect other libraries to do that, and we certainly don't want to break them. ever. 
     337Jan 27 11:50:35 <jmikola|w>     lsmith: wouldn't making a component perpetuate their ignorance? 
     338Jan 27 11:50:38 <lsmith>        eriksencosta: yeah .. a simple API compatible implementation 
     339Jan 27 11:50:50 <jmikola|w>     they wouldn't realize they don't have intl installed if we provide a working implementation :) 
     340Jan 27 11:50:54 <lsmith>        bschussek: so we make our code more complex? 
     341Jan 27 11:51:01 <lsmith>        we make it harder to review code? 
     342Jan 27 11:51:03 <lsmith>        we make it slower? 
     343Jan 27 11:51:07 <bschussek>     slower?? 
     344Jan 27 11:51:11 <bschussek>     you're talking about method delegatoin 
     345Jan 27 11:51:15 <lsmith>        yes 
     346Jan 27 11:51:18 <bschussek>     if that's a problem, we really have a problem 
     347Jan 27 11:51:29 <lsmith>        well you just dont pile on method calls for fun 
     348Jan 27 11:51:30 <henrikbjorn>   Lsmith i agree its core php anyways 
     349Jan 27 11:51:39 <eriksencosta>  lsmith: to me seems simpler, we just need to implement what we need 
     350Jan 27 11:51:52 <lsmith>        its more code to maintain 
     351Jan 27 11:51:52 <bschussek>     lsmith: not for fun, but not breaking third party libraries is a very serious reason to do so 
     352Jan 27 11:51:53 *       ozmerk (~merk@ has joined #symfony-dev 
     353Jan 27 11:51:54 <lsmith>        more bugs to create 
     354Jan 27 11:51:58 <eriksencosta>  lsmith: at least for the 'en' locale 
     355Jan 27 11:52:03 <Seldaek>       bschussek: it's seriously hypothetical too 
     356Jan 27 11:52:07 <jmikola|w>     if we create a Locale wrapper, this would be similar to what Doctrine does for the Mongo classes, no? (cc bulatshakirzyano ) 
     357Jan 27 11:52:12 <lsmith>        then we submit a patch to the 3rd party 
     358Jan 27 11:52:13 <Seldaek>       bschussek: you can always send a patch to said library if a problem occurs 
     359Jan 27 11:52:14 <fabpot>        lsmith: we need a solution for en. We cannot rely on intl being present 
     360Jan 27 11:52:31 <Seldaek>       fabpot: implementing intl is a good solution.. 
     361Jan 27 11:52:31 <jmikola|w>     if Locale isn't injected to our wrapper class, we just return "en" as the default 
     362Jan 27 11:52:33 <lsmith>        fabpot: my point is that we shouldnt implement a wrapper that then decide if to call intl or our fallback 
     363Jan 27 11:52:43 *       kriswallsmith ( has joined #symfony-dev 
     364Jan 27 11:52:43 *       kriswallsmith has quit (Changing host) 
     365Jan 27 11:52:43 *       kriswallsmith (~kriswalls@symfony/developer/kriswallsmith) has joined #symfony-dev 
     366Jan 27 11:52:44 <lsmith>        we should just implement a fallback that implements the intl API in php 
     367Jan 27 11:52:47 <Seldaek>       fabpot: it won't autoload the files if intl is loaded 
     368Jan 27 11:52:51 <lsmith>        that is loaded if you dont have intl 
     369Jan 27 11:52:53 <bulatshakirzyano>      jmikola|w yes 
     370Jan 27 11:52:57 <bschussek>     lsmith: no, it's not compatible 
     371Jan 27 11:53:07 <lsmith>        bschussek: as compatible as we need it 
     372Jan 27 11:53:18 <bschussek>     lsmith: but not as compatible as third party libs need it 
     373Jan 27 11:53:25 <Seldaek>       bschussek: which libs? 
     374Jan 27 11:53:31 <bschussek>     any 
     375Jan 27 11:53:46 <bulatshakirzyano>      jmikola|w, but that wouldn't decouple ODM from mongo:) 
     376Jan 27 11:53:51 <lsmith>        really you are adding a ton of code, a ton of overhead, a ton of complexity for a very theoretical issue that is the fault of the 3rd party 
     377Jan 27 11:53:58 <Seldaek>       bschussek: well, if it's only a wild guess that someone may have done something stupid in their code, I don't think that's a good enough reason 
     378Jan 27 11:54:00 <bulatshakirzyano>      jmikola|w that wasn't the reason for proxying 
     379Jan 27 11:54:02 <bschussek>     lsmith: you are exaggerating 
     380Jan 27 11:54:13 <lsmith>        you are exaggerating the problem :) 
     381Jan 27 11:54:20 <Seldaek>       bschussek: function calls aren't free, D1 suffered heavily from that afaik 
     382Jan 27 11:54:21 <lsmith>        but i guess we just dont agree 
     383Jan 27 11:54:47 <lsmith>        so either we vote .. or we let the person implementing decide :) 
     384Jan 27 11:55:01 *       ornicar (~ornicar@ has joined #symfony-dev 
     385Jan 27 11:55:02 *       kertz_ (~kertz@ has joined #symfony-dev 
     386Jan 27 11:55:20 <bschussek>     the current implementation suggestion is as follows 
     387Jan 27 11:55:21 <lsmith>        for what its worth .. i am -1 on a wrapper, +1 on a compat lib (btw there is PEAR_Compat for this) 
     388Jan 27 11:55:34 <bschussek>     implement interfaces and two implementing classes for each needed class in Locale 
     389Jan 27 11:55:39 <lsmith> 
     390Jan 27 11:55:51 <bschussek>     e.g., NumberFormatterInterface, IntlNumberFormatter, SimplNumberFormatter 
     391Jan 27 11:56:01 <bschussek>     the first implementation delegates everything to a wrapped intl implementation 
     392Jan 27 11:56:20 <bschussek>     the second implementation fakes the results for "en" locale and throws exceptions if unimplemented features are used 
     393Jan 27 11:56:44 *       henrikbj_ ( has joined #symfony-dev 
     394Jan 27 11:56:45 <jmikola|w>     bulatshakirzyano: your proxying extends, but we could make Locale an optionally contained class and proxy methods that way 
     395Jan 27 11:56:51 <bschussek>     we can easily exchange them and don't break any third party libraries. People could even come up with fully compliant implementations of intl in PHP 
     396Jan 27 11:56:58 *       kertz has quit (Ping timeout: 255 seconds) 
     397Jan 27 11:56:58 *       kertz_ is now known as kertz 
     398Jan 27 11:57:19 <Seldaek>       bschussek: sounds much more complex than implementing only the fake intl part imo, and the fake intl could also be fully compliant if someone feels like it 
     399Jan 27 11:57:28 *       Ases has quit (Quit: Page closed) 
     400Jan 27 11:57:33 <jmikola|w>     bschussek: bulatshakirzyano 's symfony live presentation has a great couple of slides about creating classes with optionally-aware deps :) 
     401Jan 27 11:57:43 <bulatshakirzyano>      jmikola|w, true that, but you still need two drvers - one that uses Locale, another one, that doesn't, otherwise you'll have a lot of conditional code 
     402Jan 27 11:57:44 <jmikola|w>     would be a decent model for Locale-aware form fields 
     403Jan 27 11:57:45 *       ozmerk has quit (Ping timeout: 260 seconds) 
     404Jan 27 11:57:45 <lsmith>        thereby duplicate the intl API, add a method call to every intl call 
     405Jan 27 11:58:14 <bulatshakirzyano>      doesn't make sense to re-create intl 
     406Jan 27 11:58:17 <bschussek>     lsmith: exactly. I don't think the performance impact will be serious compared to badly written ORM code 
     407Jan 27 11:58:19 *       henrikbjorn has quit (Ping timeout: 255 seconds) 
     408Jan 27 11:58:19 <lsmith>        the fake intl API would be loaded optionally .. heck maybe the user even has to put it in explicitly .. so if we are breaking other peoples code .. just fix the fake intl layer 
     409Jan 27 11:58:23 <henrikbj_>      If people use sf2 a "pro" framework the would know what intl is and how to install it 
     410Jan 27 11:58:23 <eriksencosta>  lsmith: but this way it will be easier to just drop the classes when intl get in php core 
     411Jan 27 11:58:25 <bschussek>     or badly written queries 
     412Jan 27 11:58:32 <bulatshakirzyano>      I'm with bschussek - two strategies/drivers 
     413Jan 27 11:58:44 <henrikbj_>     Erik it is in core 
     414Jan 27 11:58:52 <Seldaek>       bschussek: it's still adding a performance hit in the badly written symfony then :p 
     415Jan 27 11:58:54 <jmikola|w>     realistically, intl is only a problem for developers, i think most prod environments aren't mac servers and can easily get php5-intl installed as a package :) 
     416Jan 27 11:58:57 <bulatshakirzyano>      either using jmikola|w's suggestion or using two formatters as bschussek suggests 
     417Jan 27 11:58:57 <lsmith>        eriksencosta: easier? once everybody really has intl installed .. you seriously dont want to keep the wrapper? 
     418Jan 27 11:59:11 <lsmith>        but its bundled with 5.3 
     419Jan 27 11:59:15 <lsmith>        just not enabled by default IIRC 
     420Jan 27 11:59:26 <henrikbj_>     Yes 
     421Jan 27 11:59:30 <bschussek>     lsmith: once everybody has intl installed, we can change the implementation 
     422Jan 27 11:59:31 <eriksencosta>  are you sure? 
     423Jan 27 11:59:36 <lsmith>        heh 
     424Jan 27 11:59:37 <eriksencosta>  --enable-intl in ./configure? 
     425Jan 27 11:59:45 *       henrikbj_ is now known as henrikbjornipad 
     426Jan 27 11:59:48 <eriksencosta>  or --with-intl, not sure 
     427Jan 27 11:59:49 <fabpot>        my point of view: we must not rely on intl being installed, we should not have overhead if intl is installed 
     428Jan 27 12:00:05 <Seldaek>       bschussek: dropping the implementation is much easier by faking the intl lib is there 
     429Jan 27 12:00:06 <lsmith>        anyway .. its 18:00 .. quick vote 
     430Jan 27 12:00:06 <bulatshakirzyano>      fabpot +1 
     431Jan 27 12:00:14 <lsmith>        fabpot +1 
     432Jan 27 12:00:21 <Seldaek>       bschussek: the other way might have created dependencies in userland code 
     433Jan 27 12:00:22 <lsmith>        (which means no wrapper) 
     434Jan 27 12:00:23 <pgodel_work>   fabpot: +1 
     435Jan 27 12:00:30 <iampersistent1>        fabpot: +1 
     436Jan 27 12:00:30 <bschussek>     fabpot +1, but rephrase to "considerable overhead" 
     437Jan 27 12:00:37 <fabpot>        bschussek: fine 
     438Jan 27 12:00:44 <eriksencosta>  +1 
     439Jan 27 12:00:47 <Seldaek>       well, then we're not voting on anything anymore 
     440Jan 27 12:00:48 <dustinwhittle> +1 
     441Jan 27 12:00:49 <lsmith>        heh 
     442Jan 27 12:01:05 <Seldaek>       we all agree on not deciding, great 
     443Jan 27 12:01:05 <henrikbjornipad>       -1 
     444Jan 27 12:01:15 <lsmith>        so it goes Seldaek :) 
     445Jan 27 12:01:24 <lsmith>        in the end the person writing the code has the most say 
     446Jan 27 12:01:37 <lsmith>        but i think the rest have experessed their preference 
     447Jan 27 12:01:41 <henrikbjornipad>       Bobthecow have an excelent homebrew formula 
     448Jan 27 12:01:47 <lsmith>        anyway .. thats it for this week