Log of #symfony-dev meeting 20110331 (all times GMT-4)

transcript.txt

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