Development

IRCLogs20110331

You must first sign up to be able to contribute.

Version 2 (modified by lsmith, 7 years ago)
--

Summary

http://www.doodle.com/ceqecvh3p2929nkk#close

Adding the "Bundle" suffix back

Continue discussion about general exception strategy: spl vs. custom, inheritance vs. codes etc

Form Refactoring

Cache Problems: Shell vs Webserver Rights

RFC - Changing translation sources to message keys

changing the expectations for the meetings

[17:01] <lsmith> ok .. fabpot, Seldaek, Stof, kriswallsmith, jmikola, avalanche123 ready
[17:01] <lsmith> i guess bernhard isnt here ..
[17:01] <fabpot> yep
[17:01] <avalanche123> yup
[17:01] <lsmith> hope he will show up
[17:02] <kriswallsmith> i just rolled out of bed
[17:02] <lsmith> Adding the "Bundle" suffix back: http://bit.ly/i2sSPQ
[17:02] <Stof> I'm here
[17:02] <lsmith> first topic (skipping forms in the hopes of a late arrival of bernhard)
[17:03] <lsmith> i guess here the discussion revolves about readding the Bundle suffix as before last week .. or at least for @Resource references
[17:03] <kriswallsmith> :) that's the original patch i had
[17:03] <Seldaek> I think I offered a good compromise at the end, don't know if everyone would agree or not
[17:03] <kriswallsmith> but it was inconsistent in the implementation
[17:03] <marijnh> I found the argument of kris very strong. We're not being consistent
[17:04] <lsmith> is there much to talk?
[17:04] <lsmith> or just vote?
[17:04] <pgodel_work> but the current state is also not consistent
[17:04] <fabpot> lsmith: there is nothing to vote on
[17:04] • bshafs|away is now known as bshafs.
[17:04] <kriswallsmith> we should discuss
[17:04] <fabpot> marijnh: which argument? what is not consistent now?
[17:04] <Seldaek> do we all agree on removing the "Bundle" from the FooBundle:Default:view notation?
[17:05] <Seldaek> that would be a first step at least
[17:05] <Aerialls> yep
[17:05] <Seldaek> then we can discuss the rest..
[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)
[17:05] <fabpot> Seldaek: we remove Bundle in all shortcut notation or nowhere
[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
[17:05] ← Rafix left IRC. (Quit: Leaving)
[17:06] <fabpot> why would we want to remove it for controllers, but not for resources? or the other way around?
[17:06] <Seldaek> fabpot: well, @FooBar/Resources/.. isn't really a shortcut notation imo
[17:06] → phidah joined the channel.
[17:06] <marijnh> so I guess I'm left without an argument. Though I prefer a more verbose notation as it resambles  that path.
[17:06] <pgodel_work> johannes_: that's my point of view too
[17:06] → ajessu joined the channel.
[17:06] <Seldaek> fabpot: it's just a way of abstracting the base path of the controller, not a shortcut
[17:06] → Rafix joined the channel.
[17:06] <Seldaek> while the Foo:Bar:baz notation is a shorthand, and very specific thing
[17:06] <fabpot> johannes_: that's why I'm in favor of reintroducing the Bundle suffix
[17:06] <kriswallsmith> how about we removing the "Bundle" suffix from the last namespace segment?
[17:06] <johannes_> fabpot: me too :)
[17:07] <fabpot> kriswallsmith: nope
[17:07] <jmikola|w> lsmith: sorry, just got in :)
[17:07] <fabpot> we said that the "best practice" is Acme\FooBundle
[17:07] <fabpot> if we remove Bundle, we are left with Acme\Foo
[17:07] <fabpot> How do I know that this is Symfony related?
[17:07] <marijnh> I'm very strongly against removing Bundle from the namespace
[17:08] <kriswallsmith> ok, i see your point
[17:08] <fabpot> so, the only question is whether we re-add Bundle or not
[17:08] <jmikola|w> fabpot: for the shorthand syntax, correct?
[17:08] <avalanche123> I'm not in favor of any decision right now
[17:08] <avalanche123> fabpot, you can still use suffix in that case, but what about OpenSky\Bundle\...Bundle
[17:08] <Seldaek> fabpot: well, I think we're all for re-adding it, except in the shorthand (A:B:c) where opinions diverge
[17:08] <fabpot> jmikola|w: basically reverting Kris commit
[17:09] • lsmith nods to Seldaek
[17:09] <rande> I like the current implementation ;)
[17:09] <johannes_> Seldaek: another option would be to add controller and action as suffix there as well
[17:09] <fabpot> avalanche123: we already had this discussion and I don't see why we need to change the convention now
[17:09] <Seldaek> johannes_: oh please:p
[17:09] <lsmith> another option would be to switch to the array syntax :)
[17:09] <fabpot> avalanche123: for the record I was in favor of keeping a Bundle\ sub-namespace  :P
[17:10] <pgodel_work> if the name of the bundle is FooBundle, it should be references FooBundle everywhere
[17:10] <avalanche123> fabpot right
[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
[17:10] <avalanche123> here is what I mean
[17:10] <jmikola|w> user is certainly free to override that behavior if they change getName()'s behavior
[17:10] <fabpot> jmikola|w: we don't want the developer to mess up with this
[17:10] <fabpot> this is how you reference everything, the convention should be enforced
[17:10] <pgodel_work> agree
[17:10] <kriswallsmith> jmikola: getName is final
[17:10] <avalanche123> I would like to be able to have Company\FacebookBundle or Company\Bundle\SomeOtherName
[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:)
[17:10] <henrikbjorn> johannes_ exactly
[17:11] <avalanche123> can we not support it?
[17:11] <fabpot> avalanche123: you can, no problem
[17:11] <jmikola|w> kriswallsmith: ah, thanks for pointing that out ; didn't realize it was final, fabpot
[17:11] <avalanche123> fabpot without the suffix in the second name?
[17:11] <marijnh> got to go :-(
[17:11] <kriswallsmith> jmikola|w: it's final, but you can still implement the interface yourself and do whatever
[17:11] <fabpot> avalanche123: nope (read too fast)
[17:11] <lsmith> 4mins left in the timebox
[17:11] ← marijnh left the channel.
[17:11] <fabpot> again, the only question is whether we re-add the Bundle suffix or not. Everything else is irrelevant
[17:12] <henrikbjorn> i am +1 for Company\Bundle\BundleName and then remove the bundle suffix
[17:12] <fabpot> do we revert Kris patch or not
[17:12] <kriswallsmith> this decision feels rushed
[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)
[17:12] <Aerialls> I think it's good currently
[17:12] <avalanche123> in cases where companies place bundles in Bundle subnamespace the suffix is redundant IMO
[17:12] <rande> +1 for keeping kris' patch
[17:12] <johannes_> kriswallsmith: maybe the other decision was rushed :)
[17:12] <avalanche123> that was the main reason I proposed getting rid of it
[17:12] <fabpot> ok, let's me say it again: we are not going to change the namespace name convention we have
[17:13] <Seldaek> then +1 on keeping the shorthand for controllers/templates, but -1 on the rest
[17:13] <fabpot> johannes_: I think so
[17:13] <fabpot> Seldaek: that's not an option
[17:13] <Seldaek> fabpot: why?
[17:13] <fabpot> Seldaek: consistency. We must use the bundle name everywhere
[17:14] <fabpot> there is only one bundle name
[17:14] <lsmith> ok .. we are nearing the end of the timebox
[17:14] <Seldaek> well, I don't agree, but that never stopped anything :p
[17:14] <lsmith> shall we continue the discussion on the list for now?
[17:14] <henrikbjorn> Seldaek:  +1 your probosal and i agree
[17:14] <johannes_> how about BlogBundle:PostController:viewAction for consistency?
[17:15] <jmikola|w> lsmith: can we get an extension? :)
[17:15] <henrikbjorn> johannes_ id rather kill my self :)
[17:15] <rande> johannes_: argh .....
[17:15] <lsmith> jmikola|w: we still have other big topics
[17:15] <lsmith> i just send bernhard an sms
[17:15] <Seldaek> let's skip this for now
[17:15] <fabpot> lsmith: this topic is important as reverting is yet another big-bang
[17:15] <johannes_> we shouldn't have this hang for too long
[17:15] <Aerialls> the choice was made last week
[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
[17:15] <fabpot> so, if we need to revert, we need to do it fast
[17:16] <lsmith> fabpot: the damage is done .. but yeah it needs to be figured out before beta1
[17:16] <fabpot> before the next PR, which is next monday
[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?
[17:16] <henrikbjorn> if we have the Bundle subnamespace isnt that explicitly saying its a symfony thing ?
[17:16] → everzet joined the channel.
[17:16] <rande> I don't see the point of having Bundle in a resource
[17:17] <Seldaek> jmikola|w: no, Bundle is just a suffix to help users (maybe).. technically it does nothing
[17:17] <jmikola|w> whether it's the colon-delimited syntax or just other places we refer to bundle names
[17:17] <fabpot> let me bring an example
[17:17] <johannes_> rande: well it's expressing that you're referring to a bundle
[17:17] <fabpot> @Foo/views/foo.html.twig
[17:17] <rande> a resource point to a bundle anyway
[17:17] <fabpot> this is how you reference a resource right now
[17:17] <rande> yes
[17:17] <fabpot> but the file is under FooBundle, not Foo, so this is disturbing
[17:17] <Seldaek> well, in that case, "@" really means "bundle"
[17:18] <fabpot> in app/, you can override templates
[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)
[17:18] <henrikbjorn> so remove the Bundle suffix from the folder name
[17:18] <henrikbjorn> and we can keep the current patch and everyone is happy
[17:18] <johannes_> Seldaek: but that's a convention, not explicit; in a DI file it's referring to a service for example
[17:18] <pgodel_work> no way
[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
[17:19] <vicb> fabpot, I have submitted a PR for that
[17:19] <Seldaek> johannes_: yeah, well that's why I think it should be reverted, but not the controller/template part
[17:19] <jmikola|w> fabpot: why are they stored under Foo/ ? I thought the folder and namespace weren't changing
[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?
[17:20] <Stof> jmikola|w: in app/Resources/ you need to use Foo currently
[17:20] <fabpot> I'm strongly +1 for reverting the patch
[17:20] <pgodel_work> +1
[17:20] <Seldaek> fabpot: for resources, agreed definitely
[17:20] <lsmith> i am with Seldaek
[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
[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?
[17:21] <Seldaek> jmikola|w: yes, this Foo:Bar:baz thing doesn't look anything like a filesystem path
[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)
[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
[17:21] <Seldaek> it skips the Resources/views for the templates, and skips other things for controllers
[17:22] <jmikola|w> fabpot: how do we currently explain that the "Controller" suffix is unnecessary?
[17:22] <Stof> fabpot: in this notation, the doc still explains that Bar references BarController
[17:22] <avalanche123> +1 for consistency, even if it means revert
[17:22] ← krymen left IRC. (Quit: Leaving.)
[17:22] <kriswallsmith> the current solution is consistent
[17:22] → beberlei joined the channel.
[17:22] <kriswallsmith> the bundle name is "Foo"
[17:22] <beberlei> sorry i am late
[17:22] <kriswallsmith> whenever you reference the bundle, use "Foo"
[17:22] <jmikola|w> i'm inclined to use "Bundle" suffix in controller shorthand, if we revert it for resource notation
[17:22] <lsmith> avalanche123: well for the template syntax reverting would be making it inconsistent
[17:23] <pgodel_work> kriswallsmith: but the classname is not
[17:23] <jmikola|w> i think the "it's a file path" argument for resources is significant for new users grasping concepts
[17:23] <avalanche123> lsmith, I thought it is inconsistent now
[17:23] <lsmith> avalanche123: the @Resource is inconsistent
[17:23] <kriswallsmith> pgodel_work: right, this is a "logical" name
[17:23] <avalanche123> lsmith, so it IS inconsisten
[17:23] <pgodel_work> that to me is inconsistent :)
[17:23] <johannes_> we have an inconsistency either way unless to suffix everything, or nothing
[17:23] <lsmith> but FooBundle:Bar:lala.html.twig references FooBundle, BarController and lalaAction
[17:23] <lsmith> how would that be consistent?
[17:24] <kriswallsmith> lala template
[17:24] <everzet> lsmith: +1
[17:24] <avalanche123> that is not
[17:24] <fabpot> How many of you have upgraded their applications to the new notation?
[17:24] <henrikbjorn> me
[17:24] <henrikbjorn> 3 of them
[17:24] <avalanche123> fabpot I haven't
[17:24] <fabpot> me too
[17:24] <lsmith> kriswallsmith: right .. though in most cases it would map to lalaAction
[17:24] <pgodel_work> I did
[17:24] <johannes_> me as well
[17:24] <rande> 6 Bundles ;)
[17:24] <ajessu> me
[17:24] <pgodel_work> lots of search/replace
[17:24] <pgodel_work> it felt weird
[17:24] <Stof> I have for one app and FOS USerBundle
[17:24] <mvrhov> I haven't because I'm using experimental forms
[17:24] <fabpot> those who upgraded can talk about old vs new
[17:24] <lsmith> and of course you can say its not BarController .. but some randomly named dir in the Resources folder
[17:24] <Aerialls> me
[17:25] <johnwards> I've upgraded
[17:25] <henrikbjorn> mvrhov: bschussek have merged with master so you can :)
[17:25] <fabpot> and I can tell you that it also felt weird to me
[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
[17:25] <Stof> for @Resources I prefer the old one
[17:25] <lsmith> well for the most part all i did was s/Bundle:/:/
[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)
[17:25] <johnwards> It felt weird that I wasn't removing the word Bundle from everything
[17:25] <henrikbjorn> fabpot: it feels weird becaus the Bundle part refers mostly to the Bundle folder and not the bundle class
[17:25] <lsmith> ok guys .. we have talked 25mins now
[17:25] <kriswallsmith> ajessu: there's nothing preventing people from creating bundles in a namespace that doesn't end with "Bundle"
[17:25] <henrikbjorn> so SomeBundle maded it logical to look for the resources in SomeBundle/Resources folder
[17:26] <lsmith> we will not come to some magical agreement
[17:26] <pgodel_work> but the bundle class matches the path in the directory, and has to
[17:26] <rande> for me  @Admin = AdminBundle
[17:26] <kriswallsmith> in that case having to add "Bundle" when referencing a resource will be very strange
[17:26] <pgodel_work> lsmith: no :)
[17:26] <kriswallsmith> we need to use the logical bundle name everywhere
[17:26] <henrikbjorn> pgodel_work no it does not, the folder is not VendorBundleName but Vendor/BundleName/
[17:26] <kriswallsmith> whether it has Bundle included or not
[17:26] <fabpot> ok, we won't reach an agreement, which means we have solid pros and cons in both camps
[17:26] <lsmith> i dont think it makes sense to continue talking .. either we vote or we postpone (and postpone might mean reverting)
[17:26] <pgodel_work> but BundleName is FooBundle
[17:27] <henrikbjorn> yes
[17:27] <johnwards> are we talking about Bundles until Bernard turns up?
[17:27] <kriswallsmith> pgodel_work: before the patch, yes
[17:27] <fabpot> we have used the Bundle suffix for a year now, so let's revert and talk about something else
[17:27] <henrikbjorn> but you still reference with VendorFooBundle
[17:27] <kriswallsmith> pgodel_work: but now the bundle name is Foo
[17:27] <lsmith> johnwards: we have more topics
[17:27] <henrikbjorn> g2g
[17:27] ← henrikbjorn left IRC. (Quit: henrikbjorn)
[17:27] <pgodel_work> henrikbjorn: it still is in the class and in the filesystem
[17:27] <lsmith> Continue discussion about general exception strategy: spl vs. custom, inheritance vs. codes etc
[17:27] → daum joined the channel.
[17:27] <lsmith> johannes_: ? take it awat
[17:27] <lsmith> away
[17:28] <fabpot> no consensus means I will take the decision ;)
[17:28] <kriswallsmith> i'm -0 for revert :)
[17:28] <avalanche123> +!
[17:28] <lsmith> fabpot: i think if the current PR doesnt include the change .. we will need to revert before the next PR
[17:28] <Seldaek> fabpot: I think Henrik just raised a very good point there, it's not actually FooBundle, but VendorFooBundle:B:c
[17:28] <lsmith> unless we reach a consensus otherwise
[17:29] <lsmith> ok can we talk about the next topic? :)
[17:29] <Seldaek> yes sorry:p
[17:29] <lsmith> since johannes_ seems afk
[17:29] <lsmith> i think we agreed in general to make use of spl where it makes sense
[17:29] <johannes_> ok, this is basically about having a general strategy for exceptions throughout the framework
[17:30] <lsmith> one thing i noticed is that imho we make little to no use of exception codes
[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
[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.
[17:31] <jmikola|w> what do folks think of Doctrine's exceptions?
[17:31] <fabpot> jmikola|w: please, no
[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
[17:31] <kriswallsmith> -1 for Doctrine style exceptions
[17:31] <jmikola|w> fabpot: :) too much :: ?
[17:31] <jmikola|w> heh
[17:31] <fabpot> jmikola|w: too much Doctrine ;)
[17:31] <lsmith> johannes_: i think we should use spl exceptions as much as possible
[17:31] <kriswallsmith> "throw new" is your friend
[17:32] <lsmith> rather than our own base exceptions
[17:32] <johannes_> lsmith: meaning for example different texts even if the exception type is the same?
[17:32] <fabpot> lsmith: having a base exception per component is nice
[17:32] <lsmith> one thing to note here though .. changing or adding a new exception has an impact on BC
[17:32] <jmikola|w> johannes_: i'm fond of extending spl exceptions and implementing my own exception classes
[17:32] <iAsterisk> I like zend approach
[17:32] <lsmith> and of course with base exceptions you can mitigate that
[17:32] <jmikola|w> so i might have an InvalidArgumentException for my bundle's own exception interface
[17:32] <avalanche123> iAsterisk +1
[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
[17:33] <lsmith> but reusing spl exceptions is also very useful for users
[17:33] <fabpot> I like Zend approach too +1
[17:33] <lsmith> fabpot: but do you want to always extend every spl exception before using it/
[17:33] <lsmith> ?
[17:33] <lsmith> fabpot: ZF1? or ZF2?
[17:33] <jmikola|w> i unknowingly just described the zend implementation, so +1 for those :D thanks avalanche123
[17:33] <johannes_> fabpot: what's the zend approach?
[17:33] <fabpot> ZF2
[17:33] <iAsterisk> zf2
[17:33] <[MA]Pascal> +1 johannes_
[17:34] <fabpot> they have a base exception for each component
[17:34] <kriswallsmith> the zf2 approach is "implements Exception" ?
[17:34] <Stof> johannes_: having an interface for each library and having exceptions taht extend SPL ones and implement the interface
[17:34] <fabpot> and they extend the SPL exceptions
[17:34] <avalanche123> fabpot its an interface
[17:34] <lsmith> fabpot: err how does that work?
[17:34] <lsmith> there is no multiple inheritance
[17:34] <iAsterisk> http://webcache.googleusercontent.com/search?q=cache:zk1HV0MeQu4J:framework.zend.com/wiki/display/ZFDEV2/Proposal%2Bfor%2BExceptions%2Bin%2BZF2+http://framework.zend.com/wiki/display/ZFDEV2/Proposal%2Bfor%2BExceptions%2Bin%2BZF2&cd=1&hl=en&ct=clnk&client=safari&source=www.google.com
[17:34] <Seldaek> meh, I don't like ZF's approach at all, creates billions of classes for nothing
[17:34] <Stof> lsmith: an interface per lib, not a class
[17:34] <lsmith> how can they reuse spl exceptions but use a common base exception?
[17:34] <avalanche123> Symfony\Component\Routing\Exception is an interface
[17:34] <kriswallsmith> lsmith: you can catch the component interface or the base spl class
[17:34] <fabpot> sorry, an interface
[17:34] <lsmith> ah .. interface
[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
[17:35] <everzet> Seldaek: +1
[17:35] <avalanche123> Symfony\Component\Routing\InvalidArgumentException extends InvalidArgumentException and implements Exception
[17:35] <fabpot> the problem right now is that we are again not consistent
[17:35] <jmikola|w> avalanche123 extends \InvalidArugmentException :)
[17:35] <avalanche123> now you can catch InvalidArgumentException or Symfony\Component\Routing\InvalidArgumentException or event Symfony\Component\Routing\Exception
[17:35] <avalanche123> jmikola|w correct
[17:35] <avalanche123> so you can catch all component exception
[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
[17:36] <lsmith> ah .. beberlei are you here?
[17:36] <Seldaek> stuff not having the Symfony namespace doesn't mean it's inconsistent
[17:36] <fabpot> Seldaek: have a deep look and you will definitely see inconsistencies
[17:36] <fabpot> I can tell you who wrote the code just by looking at the exception classes ;)
[17:36] <beberlei> lsmith: yes here now
[17:36] <beberlei> had the worst day at work just raelized its so late now
[17:36] <lsmith> beberlei: bernhard isnt here :( .. i send him an sms
[17:36] <beberlei> oh why?
[17:36] <fabpot> lsmith: I had a chat with him today
[17:36] <beberlei> strange
[17:36] <lsmith> dunno
[17:37] <fabpot> and I will still need a lot of time to review the patch
[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
[17:37] <fabpot> as it is now, I won't merge it. So, we won't be able to merge it anytime soon
[17:37] <lsmith> anyway .. so for exceptions
[17:37] <johannes_> Seldaek: you don't have to
[17:37] <avalanche123> Seldaek you don't have to
[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
[17:38] <avalanche123> you make them once
[17:38] <avalanche123> per spl type
[17:38] <Seldaek> avalanche123: well, once per component per type, yeah
[17:38] <avalanche123> and implement that same interface
[17:38] <avalanche123> yes
[17:38] <avalanche123> how is that a problem?
[17:38] <Seldaek> well I think this is awful
[17:38] <beberlei> fabpot: maybe drop forms from 2.0 alltogether?
[17:38] <Seldaek> but it's ok
[17:38] <beberlei> and only ship it for 2.1?
[17:38] <rande> beberlei: is that a joke ?
[17:38] <avalanche123> it is more work for developers of Symfony2 but much simpler for users
[17:38] <fabpot> beberlei: no, that would be very bad IMO
[17:38] ← kee left IRC. (Remote host closed the connection)
[17:38] <kriswallsmith> beberlei: how about we ship forms 3.0 with symfony 2.1?
[17:39] <beberlei> rande: zend only came with a forms component at 1.5 :)
[17:39] <Seldaek> avalanche123: I don't care about it either way as a user..
[17:39] <rande> zend is zend
[17:39] <beberlei> kk
[17:39] <fabpot> beberlei: and symfony1 had a Form system
[17:39] ← vincentl left the channel.
[17:39] ← meze left IRC. (Ping timeout: 240 seconds)
[17:39] <avalanche123> Seldaek I thought we're aiming at users :)
[17:39] ← ManneW left IRC. (Quit: Leaving.)
[17:39] <Seldaek> exceptions usually shouldn't be abused as "any little error", it's only for developer errors or really bad situations
[17:39] <rande> no form = no real framework imho
[17:39] <[MA]Pascal> +1 rande
[17:39] <rande> we might use Zend_Form ;)
[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
[17:40] <everzet> avalanche123: i've never had a situation, when i was in need to catch InvalidArgumentException in some particular source place. You?
[17:40] <[MA]Pascal> -1 rande
[17:40] <rande> [MA]Pascal: I was joking
[17:40] <[MA]Pascal> +1 rande
[17:40] <Seldaek> catching exception is super rare imo
[17:40] <lsmith> ok .. can we wrap up the exception discussion
[17:40] <lsmith> and then move on to forms
[17:40] <avalanche123> everzet, yeah, good libraries throw exceptions
[17:40] <avalanche123> and you catch them
[17:40] <johannes_> there are cases where the exception class matters
[17:40] <lsmith> from what i saw there was a preferences towards the ZF2 approach
[17:41] <avalanche123> exactly
[17:41] <avalanche123> johannes_ +1
[17:41] <johannes_> we cannot just say exceptions are not important
[17:41] <Seldaek> it's not that it's not important, but the class of most of them doesn't matter
[17:41] <lsmith> what about exception codes?
[17:41] <Seldaek> it's just a way to tell the developer he did something stupid in most cases
[17:41] <avalanche123> Seldaek it is the only way to target them
[17:41] <avalanche123> properly
[17:41] <lsmith> right now it seems for the most part they are unused .. right?
[17:41] <everzet> Seldaek: +10
[17:41] <johannes_> how about AuthenticationException, or AccessDeniedException?
[17:41] <lsmith> should they be used .. should they generally not be used?
[17:41] <fabpot> let's keep the current situation as is. we will be able to do that for 2.1
[17:41] <avalanche123> johannes_ +1
[17:41] <Seldaek> johannes_: well those are *special* use cases, and for those we have unique classes
[17:42] <avalanche123> those are real use cases for exception
[17:42] <avalanche123> not special
[17:42] <Seldaek> johannes_: and if we had Security\SplException\.., you'd still have to create specific classes for those two
[17:42] <johannes_> just one example where the class matters
[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.
[17:42] <[MA]Pascal> +1 fabpot it can be done later
[17:42] <Seldaek> so that's what I'm saying, when it makes sense, create a specific class
[17:43] <avalanche123> you need to be able to differentiate component exceptions from other exceptions
[17:43] <everzet> avalanche123: not always.
[17:43] <avalanche123> its is the same reason you have SPL exception in first place
[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).
[17:43] <avalanche123> everzet nothing is always
[17:43] <avalanche123> but there is the default use case
[17:44] <avalanche123> and that is that
[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
[17:44] <avalanche123> catch exceptions by class
[17:44] <lsmith> next topic then ..
[17:44] <lsmith> Forms Refactoring: http://bit.ly/fcIk9y
[17:44] <everzet> avalanche123: i see no profit in adding custom exception classes for components, where it never be needed
[17:44] <kriswallsmith> we can't change all the exception classes and still maintain BC, can we?
[17:44] <lsmith> what are the key issues fabpot?
[17:44] <johannes_> kriswallsmith: we can, it's np
[17:45] <johannes_> if we use the interface approach at least
[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.
[17:45] <Stof> kriswallsmith: if the custom class extend the SPL one used before, there is no issue
[17:45] <jmikola|w> kriswallsmith: likely - it would mostly depend if interfaces were in the same place as current classe
[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?
[17:45] <fabpot> lsmith: I'm reviewing the patch
[17:45] <kriswallsmith> so for 2.0 we focus on exceptions extending the proper SPL
[17:45] <lsmith> fabpot: yeah .. that is a bit what i raised at the end of the last meeting
[17:45] <fabpot> but the patch is huge
[17:46] <fabpot> and I definitely don't like the Renderer\ stuff
[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..
[17:46] <Seldaek> not that I reviewed it all thoroughly
[17:46] <lsmith> when i said i wasnt entirely happy with the efficiency of the IRC meetings as of late
[17:46] <fabpot> lsmith: exactly
[17:47] <fabpot> Seldaek: Type suffix looks weird to me too
[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
[17:47] <fabpot> but my main concern is the rendering/templating part
[17:47] <beberlei> yes thats a bit heavy weight
[17:47] <fabpot> beberlei: it's not about being powerful. It's about being useable.
[17:47] <fabpot> not just*
[17:48] <fabpot> anyway, I'm not saying that it won't be merged, just that I need more timer
[17:48] → dawinterfeldt joined the channel.
[17:48] <fabpot> I don't want to rush it like we've done for some other things (like the event dispatcher for instance)
[17:48] <lsmith> beberlei: i assume you still could use more helping hands with unit testing?
[17:48] ← jakubzalas left the channel.
[17:48] <beberlei> unit testing most of the test is pretty much covered, we need more feedback about usability in general
[17:49] <johnwards> yes i've been letting the side down this week on it
[17:49] <johnwards> next week I start a 3 dev man sprint using the forms so we'll be using it heavliy
[17:49] <lsmith> ok .. then lets just keep on trucking
[17:49] <lsmith> Cache Problems: Shell vs Webserver Rights: http://bit.ly/hy0qlK
[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
[17:50] <beberlei> fabpot: in combination with twig + php engine or just with the PhpRendering that it defaults to?
[17:51] <fabpot> beberlei: with PHP and Twig engines
[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 :-)
[17:51] <beberlei> that way i can bug him also
[17:51] <johnwards> +1
[17:52] <fabpot> beberlei: ok
[17:52] <beberlei> thanks
[17:52] <johnwards> on the cache problems. is there much that can be done. isn't this a webserver/user issue?
[17:53] <johnwards> other than a handy hint in the way of setting up your user permissions and webserver user?
[17:53] <beberlei> Seldaeks sudo tip is the one i am using now
[17:53] <everzet> johnwards: for me it definetly not issue, but webserver configuration question
[17:53] <Stof> someone should write a cookbook entry about how to configure the webserver permissions
[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
[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
[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
[17:55] <lsmith> ok .. so lets try and make sure to add best practices to the docs
[17:55] <everzet> lsmith: +1
[17:55] <lsmith> let me squeeze in another topic real quick
[17:55] <lsmith> RFC - Changing translation sources to message keys: http://bit.ly/hAhWiz, http://bit.ly/hTHP5C
[17:55] <lsmith> in a way fabpot pushed this topic further quite a bit with https://github.com/fabpot/symfony/tree/api
[17:55] <jmikola|w> Even before API, which is great news btw, I'm all for keys
[17:56] <jmikola|w> many arguments have been aired about maintainability and the headache with using natural language in place of keys
[17:56] <Seldaek> yeah that's not the question I think
[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
[17:56] <Seldaek> everyone is for keys, the only worry was the dependency
[17:56] <everzet> yes, keys is definetly better
[17:56] <lsmith> which in turn means we can start depending on "sometihng" that implements the translation interface
[17:56] → tystr joined the channel.
[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)
[17:57] <lsmith> jmikola|w: yeah .. it would just depend on "something"
[17:58] <lsmith> and we would probably not implement a "dummy" implementation either i would say
[17:58] <lsmith> if someone cares enough they can always supply it later
[17:58] ← jsor left IRC. (Quit: Leaving)
[17:58] <lsmith> fabpot: ok .. with the logs from this meeting ..
[17:58] ← IfSixWasNine left IRC. (Quit: IfSixWasNine)
[17:58] <lsmith> i will announce that we are changing the expectations for the meetings a bit
[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..
[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
[17:59] <lsmith> and then we will just vote ... or acknowledge final decisions by component leads
[17:59] <fabpot> lsmith: yes
[17:59] <lsmith> or realize that the topic needs more discussion
[18:00] <fabpot> and in that case, move back to the ML
[18:00] <lsmith> so that we can move through more topics and that the "meat" of the discussion stays on the ml
[18:00] ← sf__ left IRC. (Quit: ChatZilla 0.9.86.1 [Firefox 4.0/20110318052756])
[18:00] <lsmith> right
[18:00] <lsmith> sounds good to me
[18:00] <everzet> agree
[18:00] <lsmith> ok .. thats it for this meeting then
[18:00] <Seldaek> fabpot: interested in a summary of the bundle naming issue or is that closed for you?
[18:01] <lsmith> in other news .. it looks like an e-learning platform is considering moving to Symfony2 for their very own 2.0 .. http://twitter.com/nautilebleu/statuses/53379135313149952
[18:01] <lsmith> maybe give it some retweet love from the Symfony community :)
[18:01] ← johnwards left IRC. (Quit: johnwards)
[18:01] <fabpot> Seldaek: a summary can help me make the right decision
[18:01] <lsmith> Seldaek: just continue the disussion on the list
[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