IRCLogs20110331 (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of IRCLogs20110331

lsmith (IP:
03/31/11 18:06:17 (7 years ago)



  • IRCLogs20110331

    v0 v1  
     1= Summary = 
     5== Adding the "Bundle" suffix back == 
     7== Continue discussion about general exception strategy: spl vs. custom, inheritance vs. codes etc == 
     9== Form Refactoring == 
     11== Cache Problems: Shell vs Webserver Rights == 
     13== RFC - Changing translation sources to message keys == 
     15== changing the expectations for the meetings == 
     17[17:01] <lsmith> ok .. fabpot, Seldaek, Stof, kriswallsmith, jmikola, avalanche123 ready 
     18[17:01] <lsmith> i guess bernhard isnt here .. 
     19[17:01] <fabpot> yep 
     20[17:01] <avalanche123> yup 
     21[17:01] <lsmith> hope he will show up 
     22[17:02] <kriswallsmith> i just rolled out of bed 
     23[17:02] <lsmith> Adding the "Bundle" suffix back: 
     24[17:02] <Stof> I'm here 
     25[17:02] <lsmith> first topic (skipping forms in the hopes of a late arrival of bernhard) 
     26[17:03] <lsmith> i guess here the discussion revolves about readding the Bundle suffix as before last week .. or at least for @Resource references 
     27[17:03] <kriswallsmith> :) that's the original patch i had 
     28[17:03] <Seldaek> I think I offered a good compromise at the end, don't know if everyone would agree or not 
     29[17:03] <kriswallsmith> but it was inconsistent in the implementation 
     30[17:03] <marijnh> I found the argument of kris very strong. We're not being consistent 
     31[17:04] <lsmith> is there much to talk? 
     32[17:04] <lsmith> or just vote? 
     33[17:04] <pgodel_work> but the current state is also not consistent 
     34[17:04] <fabpot> lsmith: there is nothing to vote on 
     35[17:04] • bshafs|away is now known as bshafs. 
     36[17:04] <kriswallsmith> we should discuss 
     37[17:04] <fabpot> marijnh: which argument? what is not consistent now? 
     38[17:04] <Seldaek> do we all agree on removing the "Bundle" from the FooBundle:Default:view notation? 
     39[17:05] <Seldaek> that would be a first step at least 
     40[17:05] <Aerialls> yep 
     41[17:05] <Seldaek> then we can discuss the rest.. 
     42[17:05] <marijnh> Well, I was in favor of changing but Kris brought it to my attention that we were not being consistent in the first place (we remove Controller and Action as well) 
     43[17:05] <fabpot> Seldaek: we remove Bundle in all shortcut notation or nowhere 
     44[17:05] <johannes_> the inconsistency right now is why we would have the bundle in the folder name, when we don't use it to reference it 
     45[17:05] ← Rafix left IRC. (Quit: Leaving) 
     46[17:06] <fabpot> why would we want to remove it for controllers, but not for resources? or the other way around? 
     47[17:06] <Seldaek> fabpot: well, @FooBar/Resources/.. isn't really a shortcut notation imo 
     48[17:06] → phidah joined the channel. 
     49[17:06] <marijnh> so I guess I'm left without an argument. Though I prefer a more verbose notation as it resambles  that path. 
     50[17:06] <pgodel_work> johannes_: that's my point of view too 
     51[17:06] → ajessu joined the channel. 
     52[17:06] <Seldaek> fabpot: it's just a way of abstracting the base path of the controller, not a shortcut 
     53[17:06] → Rafix joined the channel. 
     54[17:06] <Seldaek> while the Foo:Bar:baz notation is a shorthand, and very specific thing 
     55[17:06] <fabpot> johannes_: that's why I'm in favor of reintroducing the Bundle suffix 
     56[17:06] <kriswallsmith> how about we removing the "Bundle" suffix from the last namespace segment? 
     57[17:06] <johannes_> fabpot: me too :) 
     58[17:07] <fabpot> kriswallsmith: nope 
     59[17:07] <jmikola|w> lsmith: sorry, just got in :) 
     60[17:07] <fabpot> we said that the "best practice" is Acme\FooBundle 
     61[17:07] <fabpot> if we remove Bundle, we are left with Acme\Foo 
     62[17:07] <fabpot> How do I know that this is Symfony related? 
     63[17:07] <marijnh> I'm very strongly against removing Bundle from the namespace 
     64[17:08] <kriswallsmith> ok, i see your point 
     65[17:08] <fabpot> so, the only question is whether we re-add Bundle or not 
     66[17:08] <jmikola|w> fabpot: for the shorthand syntax, correct? 
     67[17:08] <avalanche123> I'm not in favor of any decision right now 
     68[17:08] <avalanche123> fabpot, you can still use suffix in that case, but what about OpenSky\Bundle\...Bundle 
     69[17:08] <Seldaek> fabpot: well, I think we're all for re-adding it, except in the shorthand (A:B:c) where opinions diverge 
     70[17:08] <fabpot> jmikola|w: basically reverting Kris commit 
     71[17:09] • lsmith nods to Seldaek 
     72[17:09] <rande> I like the current implementation ;) 
     73[17:09] <johannes_> Seldaek: another option would be to add controller and action as suffix there as well 
     74[17:09] <fabpot> avalanche123: we already had this discussion and I don't see why we need to change the convention now 
     75[17:09] <Seldaek> johannes_: oh please:p 
     76[17:09] <lsmith> another option would be to switch to the array syntax :) 
     77[17:09] <fabpot> avalanche123: for the record I was in favor of keeping a Bundle\ sub-namespace  :P 
     78[17:10] <pgodel_work> if the name of the bundle is FooBundle, it should be references FooBundle everywhere 
     79[17:10] <avalanche123> fabpot right 
     80[17:10] <jmikola|w> i'm all for shorthand not having the bundle suffix, and having getName() return a "Bundle"-less suffix; but having a suffix in the class name, I agree with - as a convention 
     81[17:10] <avalanche123> here is what I mean 
     82[17:10] <jmikola|w> user is certainly free to override that behavior if they change getName()'s behavior 
     83[17:10] <fabpot> jmikola|w: we don't want the developer to mess up with this 
     84[17:10] <fabpot> this is how you reference everything, the convention should be enforced 
     85[17:10] <pgodel_work> agree 
     86[17:10] <kriswallsmith> jmikola: getName is final 
     87[17:10] <avalanche123> I would like to be able to have Company\FacebookBundle or Company\Bundle\SomeOtherName 
     88[17:10] <Seldaek> fabpot: well, I was mostly against the subnamespace because it introduced repetition, if the namespace would be: Foo\Bundle\Bar\FooBarBundle(.php) then I'm happy with the subnamespace:) 
     89[17:10] <henrikbjorn> johannes_ exactly 
     90[17:11] <avalanche123> can we not support it? 
     91[17:11] <fabpot> avalanche123: you can, no problem 
     92[17:11] <jmikola|w> kriswallsmith: ah, thanks for pointing that out ; didn't realize it was final, fabpot 
     93[17:11] <avalanche123> fabpot without the suffix in the second name? 
     94[17:11] <marijnh> got to go :-( 
     95[17:11] <kriswallsmith> jmikola|w: it's final, but you can still implement the interface yourself and do whatever 
     96[17:11] <fabpot> avalanche123: nope (read too fast) 
     97[17:11] <lsmith> 4mins left in the timebox 
     98[17:11] ← marijnh left the channel. 
     99[17:11] <fabpot> again, the only question is whether we re-add the Bundle suffix or not. Everything else is irrelevant 
     100[17:12] <henrikbjorn> i am +1 for Company\Bundle\BundleName and then remove the bundle suffix 
     101[17:12] <fabpot> do we revert Kris patch or not 
     102[17:12] <kriswallsmith> this decision feels rushed 
     103[17:12] <Seldaek> what do you think? Acme\Bundle\Blog everywhere and no more Bundle suffix in the names anywhere? (i.e. keep current state + rename stuff) 
     104[17:12] <Aerialls> I think it's good currently 
     105[17:12] <avalanche123> in cases where companies place bundles in Bundle subnamespace the suffix is redundant IMO 
     106[17:12] <rande> +1 for keeping kris' patch 
     107[17:12] <johannes_> kriswallsmith: maybe the other decision was rushed :) 
     108[17:12] <avalanche123> that was the main reason I proposed getting rid of it 
     109[17:12] <fabpot> ok, let's me say it again: we are not going to change the namespace name convention we have 
     110[17:13] <Seldaek> then +1 on keeping the shorthand for controllers/templates, but -1 on the rest 
     111[17:13] <fabpot> johannes_: I think so 
     112[17:13] <fabpot> Seldaek: that's not an option 
     113[17:13] <Seldaek> fabpot: why? 
     114[17:13] <fabpot> Seldaek: consistency. We must use the bundle name everywhere 
     115[17:14] <fabpot> there is only one bundle name 
     116[17:14] <lsmith> ok .. we are nearing the end of the timebox 
     117[17:14] <Seldaek> well, I don't agree, but that never stopped anything :p 
     118[17:14] <lsmith> shall we continue the discussion on the list for now? 
     119[17:14] <henrikbjorn> Seldaek:  +1 your probosal and i agree 
     120[17:14] <johannes_> how about BlogBundle:PostController:viewAction for consistency? 
     121[17:15] <jmikola|w> lsmith: can we get an extension? :) 
     122[17:15] <henrikbjorn> johannes_ id rather kill my self :) 
     123[17:15] <rande> johannes_: argh ..... 
     124[17:15] <lsmith> jmikola|w: we still have other big topics 
     125[17:15] <lsmith> i just send bernhard an sms 
     126[17:15] <Seldaek> let's skip this for now 
     127[17:15] <fabpot> lsmith: this topic is important as reverting is yet another big-bang 
     128[17:15] <johannes_> we shouldn't have this hang for too long 
     129[17:15] <Aerialls> the choice was made last week 
     130[17:15] <jmikola|w> johannes_: if controllers are services, the method name might not have Action suffix, but I think in general that level of verbosity might become taxing 
     131[17:15] <fabpot> so, if we need to revert, we need to do it fast 
     132[17:16] <lsmith> fabpot: the damage is done .. but yeah it needs to be figured out before beta1 
     133[17:16] <fabpot> before the next PR, which is next monday 
     134[17:16] <jmikola|w> realistically, are there any places where bundle names are used - say doctrine mapping configs, template names, where removing "Bundle" suffix would make notation ambiguous? 
     135[17:16] <henrikbjorn> if we have the Bundle subnamespace isnt that explicitly saying its a symfony thing ? 
     136[17:16] → everzet joined the channel. 
     137[17:16] <rande> I don't see the point of having Bundle in a resource 
     138[17:17] <Seldaek> jmikola|w: no, Bundle is just a suffix to help users (maybe).. technically it does nothing 
     139[17:17] <jmikola|w> whether it's the colon-delimited syntax or just other places we refer to bundle names 
     140[17:17] <fabpot> let me bring an example 
     141[17:17] <johannes_> rande: well it's expressing that you're referring to a bundle 
     142[17:17] <fabpot> @Foo/views/foo.html.twig 
     143[17:17] <rande> a resource point to a bundle anyway 
     144[17:17] <fabpot> this is how you reference a resource right now 
     145[17:17] <rande> yes 
     146[17:17] <fabpot> but the file is under FooBundle, not Foo, so this is disturbing 
     147[17:17] <Seldaek> well, in that case, "@" really means "bundle" 
     148[17:18] <fabpot> in app/, you can override templates 
     149[17:18] <jmikola|w> fabpot: one ambiguity is that resources more closely match a file path, and controller references don't (since controllers have their suffix removed) 
     150[17:18] <henrikbjorn> so remove the Bundle suffix from the folder name 
     151[17:18] <henrikbjorn> and we can keep the current patch and everyone is happy 
     152[17:18] <johannes_> Seldaek: but that's a convention, not explicit; in a DI file it's referring to a service for example 
     153[17:18] <pgodel_work> no way 
     154[17:18] <fabpot> and now, they are stored under Foo/, not FooBundle -- the current implementation will lead to WTF problems as we have introduced yet another name 
     155[17:19] <vicb> fabpot, I have submitted a PR for that 
     156[17:19] <Seldaek> johannes_: yeah, well that's why I think it should be reverted, but not the controller/template part 
     157[17:19] <jmikola|w> fabpot: why are they stored under Foo/ ? I thought the folder and namespace weren't changing 
     158[17:19] <fabpot> jmikola|w: exactly, but the fact that now we have 2 notations introduce inconsistencies like that. Why the name is Foo and why the directory is FooBundle? 
     159[17:20] <Stof> jmikola|w: in app/Resources/ you need to use Foo currently 
     160[17:20] <fabpot> I'm strongly +1 for reverting the patch 
     161[17:20] <pgodel_work> +1 
     162[17:20] <Seldaek> fabpot: for resources, agreed definitely 
     163[17:20] <lsmith> i am with Seldaek 
     164[17:20] <mvrhov> I'm +1 for reverting, but I relally like the Seldaek's idea of getting rid of Bundle when we are talking about a template name 
     165[17:21] <jmikola|w> Seldaek: if we do it for resources (and i recognize the argument for it), you're against it for controller/action references? 
     166[17:21] <Seldaek> jmikola|w: yes, this Foo:Bar:baz thing doesn't look anything like a filesystem path 
     167[17:21] <lsmith> the bundle:controller:action.format.engine syntax is consistent now .. reverting would make it inconsistent .. unless we go with johannes_'s proposal (which would be insane) 
     168[17:21] <fabpot> try to think about how to explain that in the documentation: the bundle name is FooBundle. This is how you reference the bundle. Oh by the way, not for controllers where you should use jsut Foo. for Resources? yes, keep the suffix. That's a nightmare 
     169[17:21] <Seldaek> it skips the Resources/views for the templates, and skips other things for controllers 
     170[17:22] <jmikola|w> fabpot: how do we currently explain that the "Controller" suffix is unnecessary? 
     171[17:22] <Stof> fabpot: in this notation, the doc still explains that Bar references BarController 
     172[17:22] <avalanche123> +1 for consistency, even if it means revert 
     173[17:22] ← krymen left IRC. (Quit: Leaving.) 
     174[17:22] <kriswallsmith> the current solution is consistent 
     175[17:22] → beberlei joined the channel. 
     176[17:22] <kriswallsmith> the bundle name is "Foo" 
     177[17:22] <beberlei> sorry i am late 
     178[17:22] <kriswallsmith> whenever you reference the bundle, use "Foo" 
     179[17:22] <jmikola|w> i'm inclined to use "Bundle" suffix in controller shorthand, if we revert it for resource notation 
     180[17:22] <lsmith> avalanche123: well for the template syntax reverting would be making it inconsistent 
     181[17:23] <pgodel_work> kriswallsmith: but the classname is not 
     182[17:23] <jmikola|w> i think the "it's a file path" argument for resources is significant for new users grasping concepts 
     183[17:23] <avalanche123> lsmith, I thought it is inconsistent now 
     184[17:23] <lsmith> avalanche123: the @Resource is inconsistent 
     185[17:23] <kriswallsmith> pgodel_work: right, this is a "logical" name 
     186[17:23] <avalanche123> lsmith, so it IS inconsisten 
     187[17:23] <pgodel_work> that to me is inconsistent :) 
     188[17:23] <johannes_> we have an inconsistency either way unless to suffix everything, or nothing 
     189[17:23] <lsmith> but FooBundle:Bar:lala.html.twig references FooBundle, BarController and lalaAction 
     190[17:23] <lsmith> how would that be consistent? 
     191[17:24] <kriswallsmith> lala template 
     192[17:24] <everzet> lsmith: +1 
     193[17:24] <avalanche123> that is not 
     194[17:24] <fabpot> How many of you have upgraded their applications to the new notation? 
     195[17:24] <henrikbjorn> me 
     196[17:24] <henrikbjorn> 3 of them 
     197[17:24] <avalanche123> fabpot I haven't 
     198[17:24] <fabpot> me too 
     199[17:24] <lsmith> kriswallsmith: right .. though in most cases it would map to lalaAction 
     200[17:24] <pgodel_work> I did 
     201[17:24] <johannes_> me as well 
     202[17:24] <rande> 6 Bundles ;) 
     203[17:24] <ajessu> me 
     204[17:24] <pgodel_work> lots of search/replace 
     205[17:24] <pgodel_work> it felt weird 
     206[17:24] <Stof> I have for one app and FOS USerBundle 
     207[17:24] <mvrhov> I haven't because I'm using experimental forms 
     208[17:24] <fabpot> those who upgraded can talk about old vs new 
     209[17:24] <lsmith> and of course you can say its not BarController .. but some randomly named dir in the Resources folder 
     210[17:24] <Aerialls> me 
     211[17:25] <johnwards> I've upgraded 
     212[17:25] <henrikbjorn> mvrhov: bschussek have merged with master so you can :) 
     213[17:25] <fabpot> and I can tell you that it also felt weird to me 
     214[17:25] <ajessu> I agree with seldaek and kris as well.. @FooBundle/resources/... looks like a path, this is the one that looks weird to me without bundle 
     215[17:25] <Stof> for @Resources I prefer the old one 
     216[17:25] <lsmith> well for the most part all i did was s/Bundle:/:/ 
     217[17:25] <ajessu> but the A:B:c is a symfony specific notation for controllers, which it looks fine without the bundle (though I see that it'll create another consistency) 
     218[17:25] <johnwards> It felt weird that I wasn't removing the word Bundle from everything 
     219[17:25] <henrikbjorn> fabpot: it feels weird becaus the Bundle part refers mostly to the Bundle folder and not the bundle class 
     220[17:25] <lsmith> ok guys .. we have talked 25mins now 
     221[17:25] <kriswallsmith> ajessu: there's nothing preventing people from creating bundles in a namespace that doesn't end with "Bundle" 
     222[17:25] <henrikbjorn> so SomeBundle maded it logical to look for the resources in SomeBundle/Resources folder 
     223[17:26] <lsmith> we will not come to some magical agreement 
     224[17:26] <pgodel_work> but the bundle class matches the path in the directory, and has to 
     225[17:26] <rande> for me  @Admin = AdminBundle 
     226[17:26] <kriswallsmith> in that case having to add "Bundle" when referencing a resource will be very strange 
     227[17:26] <pgodel_work> lsmith: no :) 
     228[17:26] <kriswallsmith> we need to use the logical bundle name everywhere 
     229[17:26] <henrikbjorn> pgodel_work no it does not, the folder is not VendorBundleName but Vendor/BundleName/ 
     230[17:26] <kriswallsmith> whether it has Bundle included or not 
     231[17:26] <fabpot> ok, we won't reach an agreement, which means we have solid pros and cons in both camps 
     232[17:26] <lsmith> i dont think it makes sense to continue talking .. either we vote or we postpone (and postpone might mean reverting) 
     233[17:26] <pgodel_work> but BundleName is FooBundle 
     234[17:27] <henrikbjorn> yes 
     235[17:27] <johnwards> are we talking about Bundles until Bernard turns up? 
     236[17:27] <kriswallsmith> pgodel_work: before the patch, yes 
     237[17:27] <fabpot> we have used the Bundle suffix for a year now, so let's revert and talk about something else 
     238[17:27] <henrikbjorn> but you still reference with VendorFooBundle 
     239[17:27] <kriswallsmith> pgodel_work: but now the bundle name is Foo 
     240[17:27] <lsmith> johnwards: we have more topics 
     241[17:27] <henrikbjorn> g2g 
     242[17:27] ← henrikbjorn left IRC. (Quit: henrikbjorn) 
     243[17:27] <pgodel_work> henrikbjorn: it still is in the class and in the filesystem 
     244[17:27] <lsmith> Continue discussion about general exception strategy: spl vs. custom, inheritance vs. codes etc 
     245[17:27] → daum joined the channel. 
     246[17:27] <lsmith> johannes_: ? take it awat 
     247[17:27] <lsmith> away 
     248[17:28] <fabpot> no consensus means I will take the decision ;) 
     249[17:28] <kriswallsmith> i'm -0 for revert :) 
     250[17:28] <avalanche123> +! 
     251[17:28] <lsmith> fabpot: i think if the current PR doesnt include the change .. we will need to revert before the next PR 
     252[17:28] <Seldaek> fabpot: I think Henrik just raised a very good point there, it's not actually FooBundle, but VendorFooBundle:B:c 
     253[17:28] <lsmith> unless we reach a consensus otherwise 
     254[17:29] <lsmith> ok can we talk about the next topic? :) 
     255[17:29] <Seldaek> yes sorry:p 
     256[17:29] <lsmith> since johannes_ seems afk 
     257[17:29] <lsmith> i think we agreed in general to make use of spl where it makes sense 
     258[17:29] <johannes_> ok, this is basically about having a general strategy for exceptions throughout the framework 
     259[17:30] <lsmith> one thing i noticed is that imho we make little to no use of exception codes 
     260[17:30] <johannes_> for example, in the DI component, we had different places where a circular reference exception was thrown, with different texts; i have refactored this to an extra class which has the text embedded 
     261[17:30] <iAsterisk> +1 for revert. I got a lot of wtf's from developers why folders have bundle suffix and and bundle alias'es not. 
     262[17:31] <jmikola|w> what do folks think of Doctrine's exceptions? 
     263[17:31] <fabpot> jmikola|w: please, no 
     264[17:31] <johannes_> the question is if we want to make these things consistently throughout the framework, like adding a base exception for each component (or an interface), or only use spl exceptions 
     265[17:31] <kriswallsmith> -1 for Doctrine style exceptions 
     266[17:31] <jmikola|w> fabpot: :) too much :: ? 
     267[17:31] <jmikola|w> heh 
     268[17:31] <fabpot> jmikola|w: too much Doctrine ;) 
     269[17:31] <lsmith> johannes_: i think we should use spl exceptions as much as possible 
     270[17:31] <kriswallsmith> "throw new" is your friend 
     271[17:32] <lsmith> rather than our own base exceptions 
     272[17:32] <johannes_> lsmith: meaning for example different texts even if the exception type is the same? 
     273[17:32] <fabpot> lsmith: having a base exception per component is nice 
     274[17:32] <lsmith> one thing to note here though .. changing or adding a new exception has an impact on BC 
     275[17:32] <jmikola|w> johannes_: i'm fond of extending spl exceptions and implementing my own exception classes 
     276[17:32] <iAsterisk> I like zend approach 
     277[17:32] <lsmith> and of course with base exceptions you can mitigate that 
     278[17:32] <jmikola|w> so i might have an InvalidArgumentException for my bundle's own exception interface 
     279[17:32] <avalanche123> iAsterisk +1 
     280[17:32] <fabpot> lsmith: not really. If we only use SPL exceptions, we will be able to add our own that extend SPL later on 
     281[17:33] <lsmith> but reusing spl exceptions is also very useful for users 
     282[17:33] <fabpot> I like Zend approach too +1 
     283[17:33] <lsmith> fabpot: but do you want to always extend every spl exception before using it/ 
     284[17:33] <lsmith> ? 
     285[17:33] <lsmith> fabpot: ZF1? or ZF2? 
     286[17:33] <jmikola|w> i unknowingly just described the zend implementation, so +1 for those :D thanks avalanche123 
     287[17:33] <johannes_> fabpot: what's the zend approach? 
     288[17:33] <fabpot> ZF2 
     289[17:33] <iAsterisk> zf2 
     290[17:33] <[MA]Pascal> +1 johannes_ 
     291[17:34] <fabpot> they have a base exception for each component 
     292[17:34] <kriswallsmith> the zf2 approach is "implements Exception" ? 
     293[17:34] <Stof> johannes_: having an interface for each library and having exceptions taht extend SPL ones and implement the interface 
     294[17:34] <fabpot> and they extend the SPL exceptions 
     295[17:34] <avalanche123> fabpot its an interface 
     296[17:34] <lsmith> fabpot: err how does that work? 
     297[17:34] <lsmith> there is no multiple inheritance 
     298[17:34] <iAsterisk> 
     299[17:34] <Seldaek> meh, I don't like ZF's approach at all, creates billions of classes for nothing 
     300[17:34] <Stof> lsmith: an interface per lib, not a class 
     301[17:34] <lsmith> how can they reuse spl exceptions but use a common base exception? 
     302[17:34] <avalanche123> Symfony\Component\Routing\Exception is an interface 
     303[17:34] <kriswallsmith> lsmith: you can catch the component interface or the base spl class 
     304[17:34] <fabpot> sorry, an interface 
     305[17:34] <lsmith> ah .. interface 
     306[17:35] <Seldaek> I don't care about catching this or that specific exception from that component.. this is never a use case imo in php 
     307[17:35] <everzet> Seldaek: +1 
     308[17:35] <avalanche123> Symfony\Component\Routing\InvalidArgumentException extends InvalidArgumentException and implements Exception 
     309[17:35] <fabpot> the problem right now is that we are again not consistent 
     310[17:35] <jmikola|w> avalanche123 extends \InvalidArugmentException :) 
     311[17:35] <avalanche123> now you can catch InvalidArgumentException or Symfony\Component\Routing\InvalidArgumentException or event Symfony\Component\Routing\Exception 
     312[17:35] <avalanche123> jmikola|w correct 
     313[17:35] <avalanche123> so you can catch all component exception 
     314[17:35] <Seldaek> fabpot: I don't see the inconsistency.. There are a few base exception classes, and when they are not descriptive enough or flexible enough we add our own 
     315[17:36] <lsmith> ah .. beberlei are you here? 
     316[17:36] <Seldaek> stuff not having the Symfony namespace doesn't mean it's inconsistent 
     317[17:36] <fabpot> Seldaek: have a deep look and you will definitely see inconsistencies 
     318[17:36] <fabpot> I can tell you who wrote the code just by looking at the exception classes ;) 
     319[17:36] <beberlei> lsmith: yes here now 
     320[17:36] <beberlei> had the worst day at work just raelized its so late now 
     321[17:36] <lsmith> beberlei: bernhard isnt here :( .. i send him an sms 
     322[17:36] <beberlei> oh why? 
     323[17:36] <fabpot> lsmith: I had a chat with him today 
     324[17:36] <beberlei> strange 
     325[17:36] <lsmith> dunno 
     326[17:37] <fabpot> and I will still need a lot of time to review the patch 
     327[17:37] <Seldaek> I just think it's a huge hassle to have to create exception classes whenever you want to throw an exception somewhere 
     328[17:37] <fabpot> as it is now, I won't merge it. So, we won't be able to merge it anytime soon 
     329[17:37] <lsmith> anyway .. so for exceptions 
     330[17:37] <johannes_> Seldaek: you don't have to 
     331[17:37] <avalanche123> Seldaek you don't have to 
     332[17:37] <Seldaek> that's the kind of friction that makes me want to stop contributing code and rather do "ugly stuff" in my corner - I know it's stupid but that's how it is 
     333[17:38] <avalanche123> you make them once 
     334[17:38] <avalanche123> per spl type 
     335[17:38] <Seldaek> avalanche123: well, once per component per type, yeah 
     336[17:38] <avalanche123> and implement that same interface 
     337[17:38] <avalanche123> yes 
     338[17:38] <avalanche123> how is that a problem? 
     339[17:38] <Seldaek> well I think this is awful 
     340[17:38] <beberlei> fabpot: maybe drop forms from 2.0 alltogether? 
     341[17:38] <Seldaek> but it's ok 
     342[17:38] <beberlei> and only ship it for 2.1? 
     343[17:38] <rande> beberlei: is that a joke ? 
     344[17:38] <avalanche123> it is more work for developers of Symfony2 but much simpler for users 
     345[17:38] <fabpot> beberlei: no, that would be very bad IMO 
     346[17:38] ← kee left IRC. (Remote host closed the connection) 
     347[17:38] <kriswallsmith> beberlei: how about we ship forms 3.0 with symfony 2.1? 
     348[17:39] <beberlei> rande: zend only came with a forms component at 1.5 :) 
     349[17:39] <Seldaek> avalanche123: I don't care about it either way as a user.. 
     350[17:39] <rande> zend is zend 
     351[17:39] <beberlei> kk 
     352[17:39] <fabpot> beberlei: and symfony1 had a Form system 
     353[17:39] ← vincentl left the channel. 
     354[17:39] ← meze left IRC. (Ping timeout: 240 seconds) 
     355[17:39] <avalanche123> Seldaek I thought we're aiming at users :) 
     356[17:39] ← ManneW left IRC. (Quit: Leaving.) 
     357[17:39] <Seldaek> exceptions usually shouldn't be abused as "any little error", it's only for developer errors or really bad situations 
     358[17:39] <rande> no form = no real framework imho 
     359[17:39] <[MA]Pascal> +1 rande 
     360[17:39] <rande> we might use Zend_Form ;) 
     361[17:40] <beberlei> i agree its a bad idea, just its delaying the release pretty much alone, and i am a bit worried about pushing it through so late at a point 
     362[17:40] <everzet> avalanche123: i've never had a situation, when i was in need to catch InvalidArgumentException in some particular source place. You? 
     363[17:40] <[MA]Pascal> -1 rande 
     364[17:40] <rande> [MA]Pascal: I was joking 
     365[17:40] <[MA]Pascal> +1 rande 
     366[17:40] <Seldaek> catching exception is super rare imo 
     367[17:40] <lsmith> ok .. can we wrap up the exception discussion 
     368[17:40] <lsmith> and then move on to forms 
     369[17:40] <avalanche123> everzet, yeah, good libraries throw exceptions 
     370[17:40] <avalanche123> and you catch them 
     371[17:40] <johannes_> there are cases where the exception class matters 
     372[17:40] <lsmith> from what i saw there was a preferences towards the ZF2 approach 
     373[17:41] <avalanche123> exactly 
     374[17:41] <avalanche123> johannes_ +1 
     375[17:41] <johannes_> we cannot just say exceptions are not important 
     376[17:41] <Seldaek> it's not that it's not important, but the class of most of them doesn't matter 
     377[17:41] <lsmith> what about exception codes? 
     378[17:41] <Seldaek> it's just a way to tell the developer he did something stupid in most cases 
     379[17:41] <avalanche123> Seldaek it is the only way to target them 
     380[17:41] <avalanche123> properly 
     381[17:41] <lsmith> right now it seems for the most part they are unused .. right? 
     382[17:41] <everzet> Seldaek: +10 
     383[17:41] <johannes_> how about AuthenticationException, or AccessDeniedException? 
     384[17:41] <lsmith> should they be used .. should they generally not be used? 
     385[17:41] <fabpot> let's keep the current situation as is. we will be able to do that for 2.1 
     386[17:41] <avalanche123> johannes_ +1 
     387[17:41] <Seldaek> johannes_: well those are *special* use cases, and for those we have unique classes 
     388[17:42] <avalanche123> those are real use cases for exception 
     389[17:42] <avalanche123> not special 
     390[17:42] <Seldaek> johannes_: and if we had Security\SplException\.., you'd still have to create specific classes for those two 
     391[17:42] <johannes_> just one example where the class matters 
     392[17:42] <iAsterisk> I've already worked with zf2 exception approach on one project and I have to agree with Seldaek  that it was very rare case when you were caching component specific exceptions, though there were some cases. It definitely adds flexibility. 
     393[17:42] <[MA]Pascal> +1 fabpot it can be done later 
     394[17:42] <Seldaek> so that's what I'm saying, when it makes sense, create a specific class 
     395[17:43] <avalanche123> you need to be able to differentiate component exceptions from other exceptions 
     396[17:43] <everzet> avalanche123: not always. 
     397[17:43] <avalanche123> its is the same reason you have SPL exception in first place 
     398[17:43] <fabpot> Seldaek: let's do that. For now, in components where it makes sense, let's add specific exceptions (and we already have them anyway). 
     399[17:43] <avalanche123> everzet nothing is always 
     400[17:43] <avalanche123> but there is the default use case 
     401[17:44] <avalanche123> and that is that 
     402[17:44] <lsmith> ok .. so if someone makes a PR .. it might be considered for 2.0 .. otherwise we revisit the topic for 2.1 
     403[17:44] <avalanche123> catch exceptions by class 
     404[17:44] <lsmith> next topic then .. 
     405[17:44] <lsmith> Forms Refactoring: 
     406[17:44] <everzet> avalanche123: i see no profit in adding custom exception classes for components, where it never be needed 
     407[17:44] <kriswallsmith> we can't change all the exception classes and still maintain BC, can we? 
     408[17:44] <lsmith> what are the key issues fabpot? 
     409[17:44] <johannes_> kriswallsmith: we can, it's np 
     410[17:45] <johannes_> if we use the interface approach at least 
     411[17:45] <fabpot> lsmith: I think we need to change the topics discussed here. The discussion should happen on the mailing-list and the meeting should just be about finalizing the discussion and take decisions. 
     412[17:45] <Stof> kriswallsmith: if the custom class extend the SPL one used before, there is no issue 
     413[17:45] <jmikola|w> kriswallsmith: likely - it would mostly depend if interfaces were in the same place as current classe 
     414[17:45] <lsmith> i mean it seems bernhard, beberlei and johnwards have been working on it quite hard .. so i am wondering if the "architecture" of the change is still impossible to review? 
     415[17:45] <fabpot> lsmith: I'm reviewing the patch 
     416[17:45] <kriswallsmith> so for 2.0 we focus on exceptions extending the proper SPL 
     417[17:45] <lsmith> fabpot: yeah .. that is a bit what i raised at the end of the last meeting 
     418[17:45] <fabpot> but the patch is huge 
     419[17:46] <fabpot> and I definitely don't like the Renderer\ stuff 
     420[17:46] <Seldaek> yeah not sure about the renderer part, not sure about the Type name, but other than that it seems like an improvement.. 
     421[17:46] <Seldaek> not that I reviewed it all thoroughly 
     422[17:46] <lsmith> when i said i wasnt entirely happy with the efficiency of the IRC meetings as of late 
     423[17:46] <fabpot> lsmith: exactly 
     424[17:47] <fabpot> Seldaek: Type suffix looks weird to me too 
     425[17:47] <beberlei> several people already reviewed and tested the forms stuff quite in detail, there are some rough edges to address but the overall architecture is pretty powerful 
     426[17:47] <fabpot> but my main concern is the rendering/templating part 
     427[17:47] <beberlei> yes thats a bit heavy weight 
     428[17:47] <fabpot> beberlei: it's not about being powerful. It's about being useable. 
     429[17:47] <fabpot> not just* 
     430[17:48] <fabpot> anyway, I'm not saying that it won't be merged, just that I need more timer 
     431[17:48] → dawinterfeldt joined the channel. 
     432[17:48] <fabpot> I don't want to rush it like we've done for some other things (like the event dispatcher for instance) 
     433[17:48] <lsmith> beberlei: i assume you still could use more helping hands with unit testing? 
     434[17:48] ← jakubzalas left the channel. 
     435[17:48] <beberlei> unit testing most of the test is pretty much covered, we need more feedback about usability in general 
     436[17:49] <johnwards> yes i've been letting the side down this week on it 
     437[17:49] <johnwards> next week I start a 3 dev man sprint using the forms so we'll be using it heavliy 
     438[17:49] <lsmith> ok .. then lets just keep on trucking 
     439[17:49] <lsmith> Cache Problems: Shell vs Webserver Rights: 
     440[17:50] <fabpot> beberlei: right now, I'm trying to use it outside of a Symfony2 context. That helps me understand the architecture and if the component is really useable without the Symfony2 DIC 
     441[17:50] <beberlei> fabpot: in combination with twig + php engine or just with the PhpRendering that it defaults to? 
     442[17:51] <fabpot> beberlei: with PHP and Twig engines 
     443[17:51] <beberlei> could you post your feedback to the list aswell? bernhard is kinda stressed all the time, so i am getting less feedback fro mhim also :-) 
     444[17:51] <beberlei> that way i can bug him also 
     445[17:51] <johnwards> +1 
     446[17:52] <fabpot> beberlei: ok 
     447[17:52] <beberlei> thanks 
     448[17:52] <johnwards> on the cache problems. is there much that can be done. isn't this a webserver/user issue? 
     449[17:53] <johnwards> other than a handy hint in the way of setting up your user permissions and webserver user? 
     450[17:53] <beberlei> Seldaeks sudo tip is the one i am using now 
     451[17:53] <everzet> johnwards: for me it definetly not issue, but webserver configuration question 
     452[17:53] <Stof> someone should write a cookbook entry about how to configure the webserver permissions 
     453[17:53] <beberlei> the topic for me was kind of a question on how others do it and whats the best-practice, because i run into trouble with that all the time 
     454[17:54] <johnwards> yeah that is the solution, I've yet to sit down and figure it out and just bounce backwards and forwards chmodding stuff as and when i break something 
     455[17:55] <everzet> beberlei: webserver and deployer/cli-runner should be in the same group and that group should have full access to app/cache, app/logs 
     456[17:55] <lsmith> ok .. so lets try and make sure to add best practices to the docs 
     457[17:55] <everzet> lsmith: +1 
     458[17:55] <lsmith> let me squeeze in another topic real quick 
     459[17:55] <lsmith> RFC - Changing translation sources to message keys:, 
     460[17:55] <lsmith> in a way fabpot pushed this topic further quite a bit with 
     461[17:55] <jmikola|w> Even before API, which is great news btw, I'm all for keys 
     462[17:56] <jmikola|w> many arguments have been aired about maintainability and the headache with using natural language in place of keys 
     463[17:56] <Seldaek> yeah that's not the question I think 
     464[17:56] <lsmith> by moving the interfaces out of the components .. we can get around having to implement dummy components just for the sake of being decoupled 
     465[17:56] <Seldaek> everyone is for keys, the only worry was the dependency 
     466[17:56] <everzet> yes, keys is definetly better 
     467[17:56] <lsmith> which in turn means we can start depending on "sometihng" that implements the translation interface 
     468[17:56] → tystr joined the channel. 
     469[17:57] <jmikola|w> lsmith: depending on those interfaces doesn't mean validation would need to include a stub translator, would it? (thinking like forms and locale here) 
     470[17:57] <lsmith> jmikola|w: yeah .. it would just depend on "something" 
     471[17:58] <lsmith> and we would probably not implement a "dummy" implementation either i would say 
     472[17:58] <lsmith> if someone cares enough they can always supply it later 
     473[17:58] ← jsor left IRC. (Quit: Leaving) 
     474[17:58] <lsmith> fabpot: ok .. with the logs from this meeting .. 
     475[17:58] ← IfSixWasNine left IRC. (Quit: IfSixWasNine) 
     476[17:58] <lsmith> i will announce that we are changing the expectations for the meetings a bit 
     477[17:59] <Seldaek> I think we focus a bit too much on those hypothetical people that will reuse components out of the framework, but I won't oppose the change since it's just moving existing files around.. 
     478[17:59] <lsmith> aka the aim is to mostly use the meetings just to ensure that the arguments on the list are probably understood by everyone 
     479[17:59] <lsmith> and then we will just vote ... or acknowledge final decisions by component leads 
     480[17:59] <fabpot> lsmith: yes 
     481[17:59] <lsmith> or realize that the topic needs more discussion 
     482[18:00] <fabpot> and in that case, move back to the ML 
     483[18:00] <lsmith> so that we can move through more topics and that the "meat" of the discussion stays on the ml 
     484[18:00] ← sf__ left IRC. (Quit: ChatZilla [Firefox 4.0/20110318052756]) 
     485[18:00] <lsmith> right 
     486[18:00] <lsmith> sounds good to me 
     487[18:00] <everzet> agree 
     488[18:00] <lsmith> ok .. thats it for this meeting then 
     489[18:00] <Seldaek> fabpot: interested in a summary of the bundle naming issue or is that closed for you? 
     490[18:01] <lsmith> in other news .. it looks like an e-learning platform is considering moving to Symfony2 for their very own 2.0 .. 
     491[18:01] <lsmith> maybe give it some retweet love from the Symfony community :) 
     492[18:01] ← johnwards left IRC. (Quit: johnwards) 
     493[18:01] <fabpot> Seldaek: a summary can help me make the right decision 
     494[18:01] <lsmith> Seldaek: just continue the disussion on the list 
     495[18:01] <lsmith> if we do not find an agreement before the next PR .. we will revert for now .. that seems to be the decision atm