Log of #symfony-dev meeting 20110127 (all times GMT-5)

transcript.txt

Jan 27 11:00:47 <lsmith>	meeting time
Jan 27 11:01:01 <henrikbjorn^ipad>	No beberlei? Damm
Jan 27 11:01:02 <lsmith>	bschussek: are you around?
Jan 27 11:01:03 <lsmith>	[RFC] Supporting Doctrine2 in Form/Validator: http://bit.ly/eD3TIj
Jan 27 11:01:10 <bschussek>	lsmith: yep
Jan 27 11:01:19 <henrikbjorn^ipad>	Fabpot around?
Jan 27 11:01:22 <fabpot>	yep
Jan 27 11:01:47 *	ozmerk has quit (Ping timeout: 240 seconds)
Jan 27 11:01:58 <henrikbjorn^ipad>	Awesome because i cant type really so both sides is repreented i think
Jan 27 11:02:00 <lsmith>	bschussek: could you introduce the topic to us?
Jan 27 11:02:53 <bschussek>	yes
Jan 27 11:03:09 <lsmith>	i guess there is a pull that goes with this https://github.com/fabpot/symfony/pull/524
Jan 27 11:03:19 <bschussek>	the question is whether and how we bundle code that integrates third party libraries in the framework
Jan 27 11:03:21 <henrikbjorn^ipad>	And the ml
Jan 27 11:03:43 <bschussek>	for example, Doctrine DBAL support in the Security component, Doctrine support in the Form component
Jan 27 11:04:18 <bschussek>	right now, these supporting classes are bundled directly in the components. the reason for this is that developers using other frameworks can use the components without limitations
Jan 27 11:04:39 <bschussek>	so far, we identified three alternatives:
Jan 27 11:04:47 <bschussek>	1. do it as it is now, leave the code in the components
Jan 27 11:05:05 <fabpot>	but we also need to keep in mind that not so many people use the components without the framework
Jan 27 11:05:14 <bschussek>	2. push the code in separate subnamespaces in the components (e.g. Form\Extension\Symfony)
Jan 27 11:05:35 <bschussek>	3. use a separate global namespace (e.g. Symfony\Extension\Doctrine\Security\... etc.)
Jan 27 11:05:59 <bschussek>	fabpot: right now this is true. But if we make it easier for other people to use the components, we attract more people to the framework
Jan 27 11:06:03 <fabpot>	we know that 1. works well
Jan 27 11:06:14 <bschussek>	this is how Liip came to Symfony2, and now they contribute a lot
Jan 27 11:06:16 <henrikbjorn^ipad>	I say in the bundles they follow the naming standard, they are small libs ofbtheir own
Jan 27 11:06:48 <fabpot>	my fear with the other solutions is that we will still need to have things in bundles to have the benefit of the container, configuration, ...
Jan 27 11:07:17 <henrikbjorn^ipad>	Like menubundle / gravatar bundle. The only thing that make a bundle not a component extension is the bundle class and dic extension
Jan 27 11:07:17 *	tecbot has quit ()
Jan 27 11:07:50 <henrikbjorn^ipad>	If the stuff is kept in the components a bundle would basically onlu be the dic config
Jan 27 11:08:03 <bschussek>	henrikbjorn: exactly
Jan 27 11:08:05 <henrikbjorn^ipad>	With the exception of an apps main bundle
Jan 27 11:08:07 <lsmith>	well a bundle should always be "simple" glue but very Symfony2 specific
Jan 27 11:08:16 <henrikbjorn^ipad>	Lsmith? Why
Jan 27 11:08:20 <lsmith>	but Bundle's might contain code that could be reused
Jan 27 11:08:28 <lsmith>	if it gets to the point where its a lot of code
Jan 27 11:08:36 <lsmith>	its time to move it to a lib
Jan 27 11:08:38 <johanness>	henrikbjorn^ipad, not really a bundle can have dic aware classes, components should not have them
Jan 27 11:08:44 <henrikbjorn^ipad>	Menubundle is a good example i wouldnt have a sep lib for that and a bundle besides it
Jan 27 11:08:50 <lsmith>	like assetic ..
Jan 27 11:09:11 <bschussek>	henrikbjorn^ipad: but if it grows a lot, it would make sense to extract that code into a seperately usable library
Jan 27 11:09:13 <lsmith>	or Ariadne
Jan 27 11:09:13 *	ozmerk (~merk@119.15.97.227) has joined #symfony-dev
Jan 27 11:09:17 *	srohweder (~srohweder@kiel-d9bfd9ae.pool.mediaWays.net) has joined #symfony-dev
Jan 27 11:09:17 <bschussek>	maybe we can proceed clarifying our view of "bundles" and "components"
Jan 27 11:09:31 <henrikbjorn^ipad>	Why isnt beberlei here
Jan 27 11:09:33 *	johnkary (~johnkary@24.225.109.185) has joined #symfony-dev
Jan 27 11:09:42 <henrikbjorn^ipad>	A bundle is the same as an extension
Jan 27 11:09:48 <bschussek>	are bundles Symfony2 specific, the "glue" and components the "libraries"?
Jan 27 11:09:48 <lsmith>	but a comonent is reuseable code indepent of Symfony2 .. a bundle isnt
Jan 27 11:09:56 <henrikbjorn^ipad>	And they coumd and should be reused
Jan 27 11:10:26 <bschussek>	henrikbjorn^ipad: but what (from a point of advertisement) is then the difference between bundles and components?
Jan 27 11:10:29 <henrikbjorn^ipad>	Lsmith if doctrine depemdency is in a component it is not independent
Jan 27 11:10:34 *	Dominique_ (~chatzilla@AToulouse-152-1-30-233.w82-125.abo.wanadoo.fr) has joined #symfony-dev
Jan 27 11:10:54 <henrikbjorn^ipad>	Components = self contained no outside requirements
Jan 27 11:11:16 <bschussek>	that's not true. some components depend on other components
Jan 27 11:11:27 <fabpot>	henrikbjorn^ipad: yes, no *mandatory* requirements, but we can have *optional* ones for very specific features
Jan 27 11:11:30 <henrikbjorn^ipad>	And a bbundle provide extensions and easy development for them. All of the framework is an extension to the components
Jan 27 11:11:38 <bulatshakirzyano>	form depends on validator, is it optional?
Jan 27 11:11:43 <bschussek>	no
Jan 27 11:12:03 <henrikbjorn^ipad>	Fabot the size will also be massive and have stuff you dont need
Jan 27 11:12:07 <fabpot>	bulatshakirzyano: ok, but Form without Validator does not make any sense
Jan 27 11:12:31 <fabpot>	henrikbjorn^ipad: I'm not arguing one way or the other. I really see pros and cons in all solutions
Jan 27 11:12:37 <henrikbjorn^ipad>	If we add doctrine orm odm propel pcr couchdb should also be in the core namespace
Jan 27 11:12:46 <fabpot>	I just think that solution 2 is the worst one
Jan 27 11:12:50 <bschussek>	henrikbjorn^ipad: why? we would need someone to maintain that
Jan 27 11:13:12 <Seldaek>	henrikbjorn^ipad: you gotta stop worrying about having 10 files more or less on your disk
Jan 27 11:13:17 <henrikbjorn^ipad>	Its widely used in sf2 the odm at least
Jan 27 11:13:31 <bschussek>	henrikbjorn^ipad: again, that's not the question. we need a maintainer
Jan 27 11:13:33 <henrikbjorn^ipad>	Seldeak it wont be just 19 files
Jan 27 11:13:36 <henrikbjorn^ipad>	10
Jan 27 11:13:40 <fabpot>	henrikbjorn^ipad and bschussek have a point: everything we add need to be maintained
Jan 27 11:13:44 <Seldaek>	henrikbjorn^ipad: well, 1000 files, who cares
Jan 27 11:13:46 <bulatshakirzyano>	I think if form depends on validator and everyone accepts that, maybe solution #1 isn't that bad
Jan 27 11:13:56 *	ozmerk has quit (Ping timeout: 250 seconds)
Jan 27 11:14:08 <bulatshakirzyano>	its at least consistent and works for what we need now
Jan 27 11:14:12 <lsmith>	ok .. we are reaching the end of the timebox
Jan 27 11:14:19 <lsmith>	is there anything we can conclude at this point?
Jan 27 11:14:27 <fabpot>	bulatshakirzyano: there is a big difference between dependencies between OUR components and with EXTERNAL dependencies
Jan 27 11:14:28 <henrikbjorn^ipad>	It is way easier to remove a bundle than a component core thing because someone stops maintaining it
Jan 27 11:14:40 *	ozmerk (~merk@119.15.97.227) has joined #symfony-dev
Jan 27 11:14:45 <bulatshakirzyano>	fabpot true that
Jan 27 11:14:56 <henrikbjorn^ipad>	See the probelbundle and securitybundle
Jan 27 11:15:20 <Seldaek>	I think this is a topic best discussed on the ml honestly
Jan 27 11:15:26 <henrikbjorn^ipad>	It is
Jan 27 11:15:38 <bschussek>	since we can't really reach a consensus now, should we follow the current way for now?
Jan 27 11:15:39 <fabpot>	but we won't find a consensus
Jan 27 11:15:51 <henrikbjorn^ipad>	But the main problem is that there is a pull request now so we need a decision
Jan 27 11:16:06 <henrikbjorn^ipad>	Bscussek no that is forcing your way
Jan 27 11:16:21 <henrikbjorn^ipad>	And we are close to rc1 after that it wont be chnged
Jan 27 11:16:33 <fabpot>	the current way is to put things in bundles
Jan 27 11:16:44 <bulatshakirzyano>	fabpot +1
Jan 27 11:17:04 <Seldaek>	the one thing I see is that DB/Storage stuff is the main issue, because that is where everyone uses different techs
Jan 27 11:17:08 <bschussek>	fabpot: so move Dbal and the Form\Extension namespace from the components to DoctrineBundle?
Jan 27 11:17:14 <bschussek>	*Security\Acl\Dbal
Jan 27 11:17:18 <Seldaek>	so probably the DoctrineBundle should contain all the Doctrine specifics
Jan 27 11:17:26 <henrikbjorn^ipad>	What was the reason for bundlr refctorin if not reuse outside?
Jan 27 11:17:35 <bulatshakirzyano>	bschussek if there was a form bundle, it could go there
Jan 27 11:17:42 <fabpot>	bschussek: yes
Jan 27 11:17:58 <rande>	henrikbjorn^ipad: easier to overwrite …
Jan 27 11:18:00 <bschussek>	fabpot: ok, let's do it like this for now. we can continue the discussion on the ML
Jan 27 11:18:05 <fabpot>	and ACL\DBAL should also be moved to SecurityBundle then
Jan 27 11:18:10 <johanness>	-1 at least for the security unless there is very good reason for not having it in the component
Jan 27 11:18:12 <rande>	henrikbjorn^ipad: cleaner code
Jan 27 11:18:26 <lsmith>	hmm ... so we are well over the timebox
Jan 27 11:18:29 <johanness>	we are not providing integration there
Jan 27 11:18:30 <fabpot>	johanness: this is really about consistency
Jan 27 11:18:33 <lsmith>	should we cut the discussion here?
Jan 27 11:18:37 <fabpot>	lsmith: yes
Jan 27 11:18:45 <lsmith>	ok next topic then
Jan 27 11:18:46 <lsmith>	[RFC] Bundle namespace naming conventions: http://bit.ly/fo3ryG
Jan 27 11:19:47 <fabpot>	we need to determine the best practice for bundle namespaces
Jan 27 11:20:11 <fabpot>	Sensio\FooBundle, Sensio\Bundle\FooBundle, Sensio\Symfony\Bundle\FooBundle, Sensio\SymfonyBundle\FooBundle
Jan 27 11:20:20 <Seldaek>	and class names too it'd be nice to know if vendor is included or not
Jan 27 11:20:22 <fabpot>	of course you can choose whatever you want, but which one do we prefer
Jan 27 11:20:27 <henrikbjorn^ipad>	1
Jan 27 11:20:38 <bschussek>	Sensio\FooBundle +1
Jan 27 11:20:47 *	webPragmatist has quit (Quit: Leaving.)
Jan 27 11:20:58 <fabpot>	Seldaek: I don't think we will change the name of bundles. They must be unique, so the vendor prefix is kind of mandatory
Jan 27 11:21:07 <Seldaek>	ok
Jan 27 11:21:07 *	rooster has quit (Read error: Connection reset by peer)
Jan 27 11:21:34 <Seldaek>	I'd go for 1 too
Jan 27 11:21:38 <iampersistent1>	personally I hate the redundant Bundles so I'm +1 on Sensio\FooBundle
Jan 27 11:21:50 <Stof>	+1 for Sensio\FooBundle
Jan 27 11:21:50 <fabpot>	also, we need to decide what we use in the documentation, which vendor?
Jan 27 11:21:55 <Seldaek>	the rest is just duplicate info, Bundle implies it's symfony already, and having Bundle twice is useless
Jan 27 11:22:13 <bschussek>	fabpot: can you give an example?
Jan 27 11:22:15 <Seldaek>	fabpot: I guess Sensio is alright
Jan 27 11:22:16 <jmikola|w>	lsmith: does this topic include beberlei's point about not reusing Zend as a top-level vendor namespace for things we (Symfonians) create?
Jan 27 11:22:23 <henrikbjorn^ipad>	Sensio?
Jan 27 11:22:26 <fabpot>	bschussek: an example for what?
Jan 27 11:22:34 <bschussek>	ah you mean Sensio, Liip etc. ?
Jan 27 11:22:45 <Seldaek>	yeah just what you use for code examples
Jan 27 11:22:48 <fabpot>	Sensio is just a vendor example
Jan 27 11:22:55 <bschussek>	sure
Jan 27 11:22:56 <bulatshakirzyano>	Sension == Doctrine
Jan 27 11:22:58 <bschussek>	I think Sensio is fine
Jan 27 11:23:08 <bulatshakirzyano>	Sension\FooBundle +1
Jan 27 11:23:23 *	bulatshakirzyano why is there an 'n' at the end?
Jan 27 11:23:29 <fabpot>	bschussek: you mean the namespace for the doc?
Jan 27 11:23:39 <bschussek>	fabpot: yes
Jan 27 11:24:04 <fabpot>	so, to sum up, everybody agrees that the recommend way to name a bundle is Vendor\FooBundle
Jan 27 11:24:07 <fabpot>	right?
Jan 27 11:24:09 <jmikola|w>	bulatshakirzyano: i'm all for omitting Bundle\ in the namespace, beberlei brought up a point that Doctrine\WhateverBundle might not be published by Doctrine team directly, so it shouldn't use that as the top-level vendor
Jan 27 11:24:09 <iampersistent1>	so I'm assuming that we could also do Vendor\Group\FooBundle
Jan 27 11:24:15 <bschussek>	fabpot: +1
Jan 27 11:24:22 <Seldaek>	fabpot: yes, Vendor\FooBundle\VendorFooBundle()
Jan 27 11:24:30 <jmikola|w>	+1
Jan 27 11:24:34 <bulatshakirzyano>	+1
Jan 27 11:24:49 <fabpot>	ok, and Sensio\ as the vendor name for the doc and examples?
Jan 27 11:24:56 <bschussek>	+1
Jan 27 11:24:59 <henrikbjorn^ipad>	Ye
Jan 27 11:25:00 <Seldaek>	jmikola|w: for the DoctrineBundle, if it's community based, I guess it can sit in the Symfony namespace?
Jan 27 11:25:09 <bulatshakirzyano>	jmikola|w gotcha, in that case it could prob'ly be Vendor\Doctrine\BundleName, for third-party doctrine bundles
Jan 27 11:25:19 <fabpot>	Seldaek: yes, it was just an example in my email, but this was misinterpreted
Jan 27 11:25:21 <jmikola|w>	Seldaek: perhaps, beberlei's other example was regarding Zend bundles, too
Jan 27 11:25:21 <lsmith>	yeah .. its Symfony\DoctrineBundle
Jan 27 11:25:28 <fabpot>	lsmith: correct
Jan 27 11:25:38 <fabpot>	lsmith: noooo, Symfony\Bundle\DoctrineBundle
Jan 27 11:25:43 <Seldaek>	fabpot: yeah no problem, but we still have to clarify imo
Jan 27 11:25:46 <bschussek>	lsmith: Symfony is a different case :)
Jan 27 11:26:09 <jmikola|w>	would the bundle name still be SymfonyDoctrineBundle? or just DoctrineBundle?
Jan 27 11:26:15 <lsmith>	hmm .. well using one recommended approach for docs ... and another in your own code is kinda wonky, no?
Jan 27 11:26:15 <Seldaek>	yeah, it violates its own rules, but we love it anyways
Jan 27 11:26:30 <lsmith>	eat your own dog food ..
Jan 27 11:26:31 <fabpot>	jmikola|w: yes, we need the vendor for uniqueness
Jan 27 11:26:44 <Seldaek>	lsmith: the doc can mention the optional category thing
Jan 27 11:26:45 <jmikola|w>	ok, but Bundle\ part of the namespace can be omitted from the generated bundle name
Jan 27 11:26:55 <bschussek>	fabpot: Can't we simply include the namespace? That would be much more elegant... but I guess that's a different topic
Jan 27 11:27:30 <fabpot>	bschussek: what do you mean by "simply include the namespace"?
Jan 27 11:27:47 <lsmith>	i guess we are in this trouble because we are not installing the components into the vendor dir
Jan 27 11:28:04 <bschussek>	fabpot: when referring to a bundle, don't refer to @SensioFooBundle but @Sensio\FooBundle
Jan 27 11:28:14 <lsmith>	then we wouldnt even think of Symfony\Bundle\DoctrineBundle
Jan 27 11:28:17 <bschussek>	we need to resolve which bundles override this bundle either way
Jan 27 11:28:18 <Seldaek>	jmikola|w, fabpot: also can't it be Vendor\FooBundle\VendorFoo ? don't really see the point in typing Bundle every time I want to refer to some resource or template name
Jan 27 11:28:49 <Seldaek>	bschussek: that'd be awful imo for longer namespaces including one or two categories
Jan 27 11:28:57 <jmikola|w>	Seldaek: it may work that way now... is Bundle suffix on the class name enforced (other than being a suggested convention? :)
Jan 27 11:29:03 <Seldaek>	then the bundle name becomes really looong
Jan 27 11:29:05 <lsmith>	ok .. approaching the end of the timebo
Jan 27 11:29:07 <lsmith>	x
Jan 27 11:29:19 <bschussek>	Seldaek: sure, but that's always the case if the bundle name must be unique
Jan 27 11:29:22 <Seldaek>	jmikola|w: everything works, but what about making it the best practice?
Jan 27 11:29:29 <fabpot>	jmikola|w: yes, you can omit the Bundle suffix if you want I think
Jan 27 11:29:47 <Seldaek>	bschussek: no, the \Bundle\ part in the Symfony namespace is irrelevant to name clashes imo, so it shouldn't be in the name
Jan 27 11:30:06 <jmikola|w>	Seldaek: i could see it conflicting with folks that like to put generic services in their top level bundle directory
Jan 27 11:30:25 <bschussek>	Seldaek: the exception of the rule :) we just decided to recommend Vendor\FooBundle without Bundle\ for generic vendors
Jan 27 11:30:33 <Seldaek>	jmikola|w: yes.. I suppose
Jan 27 11:30:59 <Seldaek>	bschussek: yes but in this case what does it matter that we refer to bundles by fully qualified class name? the bundle class name is enough imo
Jan 27 11:31:21 <bschussek>	Seldaek: because the bundle class name must be unique, and the fully qualified class name is always unique
Jan 27 11:31:31 <Seldaek>	bschussek: if you introduce the full namespace in the name, then it goes boom if someone introduces a category namespace in their code
Jan 27 11:31:41 <fabpot>	we have discussed bundle names, and I think there is no good reason to change the current naming convention
Jan 27 11:31:50 <bschussek>	fabpot: ok
Jan 27 11:31:53 <lsmith>	ok .. next topic
Jan 27 11:31:56 <lsmith>	Current state towards RC1
Jan 27 11:32:11 <lsmith>	i guess the big change is the addition of SecurityBundle
Jan 27 11:32:35 <lsmith>	and a lot of refactoring that went into there
Jan 27 11:32:54 <lsmith>	i guess we could release Symfony2 now .. with a stable API .. but unstable API for SecurityBundle?
Jan 27 11:32:58 <fabpot>	let's make a long story short, I think you are all on the same page, except me
Jan 27 11:33:26 <fabpot>	and after thinking about this a lot last night, the best decision is to change the RC1 date to March 6th
Jan 27 11:33:31 <Seldaek>	yes, everyone would be happy to wait for SfLive Paris for the RC1 I guess, but then again it's not us that will burn on a stick for announcing the delay..
Jan 27 11:33:42 <Seldaek>	fabpot: awesome:)
Jan 27 11:33:45 <fabpot>	it does not mean that we need to slow down
Jan 27 11:33:53 <lsmith>	exactly
Jan 27 11:33:54 *	Garfield-fr has quit (Quit:  ⏏)
Jan 27 11:34:02 *	tecbot (~tecbot@pD9EB69A6.dip.t-dialin.net) has joined #symfony-dev
Jan 27 11:34:10 <fabpot>	let's try to have a RC1 that kicks asses
Jan 27 11:34:19 <lsmith>	fabpot: and we will be releasing a stable API in paris then .. its marketing bla bla .. but :)
Jan 27 11:34:20 <bschussek>	fabpot: +1
Jan 27 11:34:33 <fabpot>	I'm about to freeze the low-level API
Jan 27 11:34:45 <bulatshakirzyano>	fabpot +1
Jan 27 11:34:47 <Seldaek>	kicking ass it does already, that's not the question :)
Jan 27 11:34:58 <pgodel_work>	Seldaek: +1
Jan 27 11:35:23 <lsmith>	fabpot: i would really like to see the DI inheritance pull from johanness to make it in
Jan 27 11:35:23 <weaverryan>	aw shucks, it kicks ass because you all are kicking ass :)
Jan 27 11:35:27 <iampersistent1>	+1, its not something you want to do prematurely.  Some people will be pissed, but in 6 months, everyone will have forgotten that month delay, but will be better off because of it
Jan 27 11:35:37 <fabpot>	lsmith: that's not part of the low-level API, so that's fine
Jan 27 11:35:39 <lsmith>	i also bulat's request changes ..
Jan 27 11:35:54 <lsmith>	whats low level then? :)
Jan 27 11:35:58 <Seldaek>	hehe
Jan 27 11:35:59 <lsmith>	Kernel?
Jan 27 11:36:02 *	henrikbjorn^ipad has quit (Ping timeout: 250 seconds)
Jan 27 11:36:15 <bulatshakirzyano>	lsmith, that is not implemented in a likable way yet:)
Jan 27 11:36:29 <fabpot>	the main interfaces for the MVC part: HttpKernelInterface, KernelInterface, EventDispatcherInterface, EventDispatcher, EngineInterface, ControllerResolver, ...
Jan 27 11:36:31 <lsmith>	bulatshakirzyano: yeah .. i also liked kris's approach better
Jan 27 11:36:31 *	henrikbjorn^ipad (~henrikbjo@94.191.224.26.bredband.3.dk) has joined #symfony-dev
Jan 27 11:36:38 <fabpot>	ContainerInterface, ...
Jan 27 11:36:46 <fabpot>	the API is only made of interfaces
Jan 27 11:36:52 <bulatshakirzyano>	lsmith, I personally hate static methods, so I won't comment:)
Jan 27 11:36:54 <fabpot>	this is the contract between Symfony2 and its developers
Jan 27 11:36:58 <bulatshakirzyano>	static method === function
Jan 27 11:37:19 <fabpot>	bulatshakirzyano: I think it's fine here are this is about managing the f***** PHP global vars
Jan 27 11:37:23 <lsmith>	speaking of ControllerResolver .. is it still named correctly?
Jan 27 11:37:31 <Seldaek>	bulatshakirzyano: but method without $this use === function, and many methods are like that
Jan 27 11:37:32 <bulatshakirzyano>	fabpot true that again:)
Jan 27 11:37:36 <fabpot>	lsmith: I think so
Jan 27 11:38:10 <fabpot>	so, everybody is comfortable with RC1 in March?
Jan 27 11:38:11 *	Ases (c2e0c8fe@gateway/web/freenode/ip.194.224.200.254) has joined #symfony-dev
Jan 27 11:38:18 <pgodel_work>	+1
Jan 27 11:38:22 <lsmith>	+1
Jan 27 11:38:29 <iampersistent1>	+1
Jan 27 11:38:31 <bulatshakirzyano>	_1
Jan 27 11:38:32 <bulatshakirzyano>	Seldaek, yes, the main difference is that you don't know which methods your class depends on when you use statics, so the api is somewhat magical
Jan 27 11:38:36 <bulatshakirzyano>	err +1
Jan 27 11:38:41 <bschussek>	+1
Jan 27 11:38:44 <lsmith>	so moving on .. Problems with the design of DI extensions Options: http://bit.ly/f4Z3bF
Jan 27 11:38:57 <lsmith>	bschussek: think thats another one of your threads
Jan 27 11:39:17 <bschussek>	yes. currently, the DI extensions are a lot of untestable code by design
Jan 27 11:39:32 <bschussek>	if we release this as is, people will use it as a template and do it the same way
Jan 27 11:39:45 <bschussek>	since this is a critical part of every application, I think we need to improve this
Jan 27 11:40:00 <bulatshakirzyano>	+1
Jan 27 11:40:16 <bschussek>	bulatshakirzyano made the excellent suggestion to move much of the logic to factories
Jan 27 11:40:22 <johanness>	why is it untestable?
Jan 27 11:40:35 <bschussek>	johanness: because there is too much happening inside
Jan 27 11:40:45 <fabpot>	bschussek: -1
Jan 27 11:40:46 <bulatshakirzyano>	the premise is simple - those extension creata services dynamically
Jan 27 11:40:50 <johanness>	you can break that down into methods can't you?
Jan 27 11:40:56 <bulatshakirzyano>	*create
Jan 27 11:41:08 <bulatshakirzyano>	what do you use to create other objects?
Jan 27 11:41:11 <bulatshakirzyano>	factories
Jan 27 11:41:11 <fabpot>	weaverryan's work is interesting
Jan 27 11:41:18 <jmikola|w>	johanness: one problem is even after ensuring configLoad() runs only once, the order of things still matters - extensions create services, so if your own bundle extension runs after and tries to override something, it gets ignored
Jan 27 11:41:24 <bschussek>	fabpot: where can I find that?
Jan 27 11:41:27 <fabpot>	bulatshakirzyano: please, don't add yet another layer
Jan 27 11:41:49 <bulatshakirzyano>	fabpot not to the container, this should be the responsibility of the bundle, that creates dynamic services
Jan 27 11:41:56 *	henrikbjorn^ipad has quit ()
Jan 27 11:42:09 <fabpot>	bulatshakirzyano: what is a "dynamic service"?
Jan 27 11:42:11 <jmikola|w>	should extensions just do parameter processing, and leave the service definition construction (setting arguments and such) to compiler passes?
Jan 27 11:42:14 *	henrikbjorn (~henrikbjo@94.191.224.26.bredband.3.dk) has joined #symfony-dev
Jan 27 11:42:21 <weaverryan>	bschussek: work-in-progress https://github.com/fabpot/symfony/pull/510
Jan 27 11:42:24 <bulatshakirzyano>	fabpot, so doctrine bundle allows many document managers for example
Jan 27 11:42:27 <fabpot>	jmikola|w: I think there is no simple answer: it depends
Jan 27 11:42:35 <bulatshakirzyano>	each is registered in its own services it
Jan 27 11:42:53 <bulatshakirzyano>	default_document_manager === document manager with name 'default'
Jan 27 11:43:04 <fabpot>	bulatshakirzyano: what's the problem?
Jan 27 11:43:06 <weaverryan>	I don't see a problem with that
Jan 27 11:43:15 <weaverryan>	but default_document_manager should not be a DI parameter
Jan 27 11:43:20 <jmikola|w>	from a unit testing perspective, single-purpose compiler passes are pretty straight-foward to test; meanwhile, i'm writing unit tests for FrameworkExtension and it's quite hairy - i imagine securityExtension would be equally so :)
Jan 27 11:43:21 <weaverryan>	it should be a DI extension class option only
Jan 27 11:43:33 *	webPragmatist (~webby@70.239.43.254) has joined #symfony-dev
Jan 27 11:43:33 *	webPragmatist has quit (Changing host)
Jan 27 11:43:33 *	webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev
Jan 27 11:44:04 <johanness>	jmikola|w: depends ;)
Jan 27 11:44:12 <fabpot>	what about refactoring the current extensions (see weaverryan work, and the new single call to the config method) and then talk about that later
Jan 27 11:44:26 <bschussek>	weaverryan: could you shortly sum up the benefit of your refactoring?
Jan 27 11:44:28 <bulatshakirzyano>	agreed
Jan 27 11:44:31 <fabpot>	I'm pretty sure, they will be much more easier to understand and to test
Jan 27 11:44:57 <jmikola|w>	i will hopefully be done with FrameworkExtension today (finishing up tests and doing merging) - i'll run through ryan's work before i finish up though
Jan 27 11:45:02 <lsmith>	i also think that with johanness's work on DI inheritance .. we can get rid of some code in the Extensions
Jan 27 11:45:05 <jmikola|w>	lots of good stuff in his pull request
Jan 27 11:45:12 <weaverryan>	The end-result of the refactoring is to remove $container->getParameter() calls from an DI extension class - because if you're using a DI parameter that early, it's not overrideable properly
Jan 27 11:45:30 <bulatshakirzyano>	weaverryan +1 one on spotting that
Jan 27 11:45:42 <bschussek>	weaverryan: thanks
Jan 27 11:45:45 <weaverryan>	it means that some parameters are moved into the class itself - because they were never really been used as parameters in the first place (weren't overridable per the above)
Jan 27 11:46:15 <Seldaek>	fabpot: also another Extension-related issue; there are still those two xml specific methods that imo are a bit pointless, they should be made part of another interface for those that want to implement an xsd etc, otherwise you end up entering junk in the return values and it's not clean either. I can prepare a pull if you're ok with the idea
Jan 27 11:46:22 <fabpot>	weaverryan: jmikola|w: Can you work together to refactor the FrameworkExtension with your ideas?
Jan 27 11:46:41 <weaverryan>	absolutely - I'll first remove the parameter overriding from my pull request that you commented on
Jan 27 11:47:13 <bschussek>	is it possible to abstract the assignment of configuration variables to DI parameteres? there is a lot of code duplication on that part right now
Jan 27 11:47:37 <Stof>	bschussek: see FOS UserBundle
Jan 27 11:47:42 <jmikola|w>	fabpot: will do, i'm anxious to get some extra eyes on my current progress
Jan 27 11:47:56 <Stof>	the remapParameter method makes a good job for this
Jan 27 11:48:08 <lsmith>	bschussek: https://github.com/fabpot/symfony/pull/133
Jan 27 11:48:21 <lsmith>	thats the code FOS\UserBundle uses
Jan 27 11:48:32 <lsmith>	ok .. next topic?
Jan 27 11:48:41 <Stof>	(and that I copy/paste in my own extensions)
Jan 27 11:48:48 *	dustinwhittle (~dustinwhi@labs.dustinwhittle.net) has joined #symfony-dev
Jan 27 11:48:56 <lsmith>	trying to be impartial .. view and intl both got 6 votes .. so since i prefer view, we are going with intl
Jan 27 11:48:58 <lsmith>	Symfony 2's intl extension requirement: http://bit.ly/hNu3b
Jan 27 11:48:58 <weaverryan>	If we standardize all the DI extensions, any helper methods will become very apparent and can easily be added later without affecting BC
Jan 27 11:49:04 *	ozmerk has quit (Ping timeout: 246 seconds)
Jan 27 11:49:27 <jmikola|w>	is a wrapping class for Locale stuff still in the works? i recall a post from bschussek about that on ML last week
Jan 27 11:49:39 <bschussek>	jmikola|w: yes
Jan 27 11:49:41 <fabpot>	weaverryan: +1
Jan 27 11:49:42 <jmikola|w>	meanwhile, i did spot on hard dep to \Locale in FrameworkExtension :)
Jan 27 11:49:46 <lsmith>	yeah .. i think its however pontless to create a wrapper
Jan 27 11:49:53 <lsmith>	just implement intl ..
Jan 27 11:50:10 <bschussek>	Eriksen Costa is currently working on that, Tom Boutell also offered his help
Jan 27 11:50:12 <lsmith>	if other people do not check if the ext is loaded and then think they have a real intl loaded
Jan 27 11:50:14 <eriksencosta>	lsmith: implement intl in PHP code?
Jan 27 11:50:16 <lsmith>	then its theur fault
Jan 27 11:50:17 <bschussek>	lsmith: -1
Jan 27 11:50:32 <bschussek>	we can't expect other libraries to do that, and we certainly don't want to break them. ever.
Jan 27 11:50:35 <jmikola|w>	lsmith: wouldn't making a component perpetuate their ignorance?
Jan 27 11:50:38 <lsmith>	eriksencosta: yeah .. a simple API compatible implementation
Jan 27 11:50:50 <jmikola|w>	they wouldn't realize they don't have intl installed if we provide a working implementation :)
Jan 27 11:50:54 <lsmith>	bschussek: so we make our code more complex?
Jan 27 11:51:01 <lsmith>	we make it harder to review code?
Jan 27 11:51:03 <lsmith>	we make it slower?
Jan 27 11:51:07 <bschussek>	slower??
Jan 27 11:51:11 <bschussek>	you're talking about method delegatoin
Jan 27 11:51:15 <lsmith>	yes
Jan 27 11:51:18 <bschussek>	if that's a problem, we really have a problem
Jan 27 11:51:29 <lsmith>	well you just dont pile on method calls for fun
Jan 27 11:51:30 <henrikbjorn>	Lsmith i agree its core php anyways
Jan 27 11:51:39 <eriksencosta>	lsmith: to me seems simpler, we just need to implement what we need
Jan 27 11:51:52 <lsmith>	its more code to maintain
Jan 27 11:51:52 <bschussek>	lsmith: not for fun, but not breaking third party libraries is a very serious reason to do so
Jan 27 11:51:53 *	ozmerk (~merk@119.15.97.227) has joined #symfony-dev
Jan 27 11:51:54 <lsmith>	more bugs to create
Jan 27 11:51:58 <eriksencosta>	lsmith: at least for the 'en' locale
Jan 27 11:52:03 <Seldaek>	bschussek: it's seriously hypothetical too
Jan 27 11:52:07 <jmikola|w>	if we create a Locale wrapper, this would be similar to what Doctrine does for the Mongo classes, no? (cc bulatshakirzyano )
Jan 27 11:52:12 <lsmith>	then we submit a patch to the 3rd party
Jan 27 11:52:13 <Seldaek>	bschussek: you can always send a patch to said library if a problem occurs
Jan 27 11:52:14 <fabpot>	lsmith: we need a solution for en. We cannot rely on intl being present
Jan 27 11:52:31 <Seldaek>	fabpot: implementing intl is a good solution..
Jan 27 11:52:31 <jmikola|w>	if Locale isn't injected to our wrapper class, we just return "en" as the default
Jan 27 11:52:33 <lsmith>	fabpot: my point is that we shouldnt implement a wrapper that then decide if to call intl or our fallback
Jan 27 11:52:43 *	kriswallsmith (~kriswalls@c-24-21-242-95.hsd1.or.comcast.net) has joined #symfony-dev
Jan 27 11:52:43 *	kriswallsmith has quit (Changing host)
Jan 27 11:52:43 *	kriswallsmith (~kriswalls@symfony/developer/kriswallsmith) has joined #symfony-dev
Jan 27 11:52:44 <lsmith>	we should just implement a fallback that implements the intl API in php
Jan 27 11:52:47 <Seldaek>	fabpot: it won't autoload the files if intl is loaded
Jan 27 11:52:51 <lsmith>	that is loaded if you dont have intl
Jan 27 11:52:53 <bulatshakirzyano>	jmikola|w yes
Jan 27 11:52:57 <bschussek>	lsmith: no, it's not compatible
Jan 27 11:53:07 <lsmith>	bschussek: as compatible as we need it
Jan 27 11:53:18 <bschussek>	lsmith: but not as compatible as third party libs need it
Jan 27 11:53:25 <Seldaek>	bschussek: which libs?
Jan 27 11:53:31 <bschussek>	any
Jan 27 11:53:46 <bulatshakirzyano>	jmikola|w, but that wouldn't decouple ODM from mongo:)
Jan 27 11:53:51 <lsmith>	really you are adding a ton of code, a ton of overhead, a ton of complexity for a very theoretical issue that is the fault of the 3rd party
Jan 27 11:53:58 <Seldaek>	bschussek: well, if it's only a wild guess that someone may have done something stupid in their code, I don't think that's a good enough reason
Jan 27 11:54:00 <bulatshakirzyano>	jmikola|w that wasn't the reason for proxying
Jan 27 11:54:02 <bschussek>	lsmith: you are exaggerating
Jan 27 11:54:13 <lsmith>	you are exaggerating the problem :)
Jan 27 11:54:20 <Seldaek>	bschussek: function calls aren't free, D1 suffered heavily from that afaik
Jan 27 11:54:21 <lsmith>	but i guess we just dont agree
Jan 27 11:54:47 <lsmith>	so either we vote .. or we let the person implementing decide :)
Jan 27 11:55:01 *	ornicar (~ornicar@69.170.160.138) has joined #symfony-dev
Jan 27 11:55:02 *	kertz_ (~kertz@122.167.207.231) has joined #symfony-dev
Jan 27 11:55:20 <bschussek>	the current implementation suggestion is as follows
Jan 27 11:55:21 <lsmith>	for what its worth .. i am -1 on a wrapper, +1 on a compat lib (btw there is PEAR_Compat for this)
Jan 27 11:55:34 <bschussek>	implement interfaces and two implementing classes for each needed class in Locale
Jan 27 11:55:39 <lsmith>	http://pear.php.net/package/PHP_Compat
Jan 27 11:55:51 <bschussek>	e.g., NumberFormatterInterface, IntlNumberFormatter, SimplNumberFormatter
Jan 27 11:56:01 <bschussek>	the first implementation delegates everything to a wrapped intl implementation
Jan 27 11:56:20 <bschussek>	the second implementation fakes the results for "en" locale and throws exceptions if unimplemented features are used
Jan 27 11:56:44 *	henrikbj_ (~henrikbjo@94.191.252.60.bredband.3.dk) has joined #symfony-dev
Jan 27 11:56:45 <jmikola|w>	bulatshakirzyano: your proxying extends, but we could make Locale an optionally contained class and proxy methods that way
Jan 27 11:56:51 <bschussek>	we can easily exchange them and don't break any third party libraries. People could even come up with fully compliant implementations of intl in PHP
Jan 27 11:56:58 *	kertz has quit (Ping timeout: 255 seconds)
Jan 27 11:56:58 *	kertz_ is now known as kertz
Jan 27 11:57:19 <Seldaek>	bschussek: sounds much more complex than implementing only the fake intl part imo, and the fake intl could also be fully compliant if someone feels like it
Jan 27 11:57:28 *	Ases has quit (Quit: Page closed)
Jan 27 11:57:33 <jmikola|w>	bschussek: bulatshakirzyano 's symfony live presentation has a great couple of slides about creating classes with optionally-aware deps :)
Jan 27 11:57:43 <bulatshakirzyano>	jmikola|w, true that, but you still need two drvers - one that uses Locale, another one, that doesn't, otherwise you'll have a lot of conditional code
Jan 27 11:57:44 <jmikola|w>	would be a decent model for Locale-aware form fields
Jan 27 11:57:45 *	ozmerk has quit (Ping timeout: 260 seconds)
Jan 27 11:57:45 <lsmith>	thereby duplicate the intl API, add a method call to every intl call
Jan 27 11:58:14 <bulatshakirzyano>	doesn't make sense to re-create intl
Jan 27 11:58:17 <bschussek>	lsmith: exactly. I don't think the performance impact will be serious compared to badly written ORM code
Jan 27 11:58:19 *	henrikbjorn has quit (Ping timeout: 255 seconds)
Jan 27 11:58:19 <lsmith>	the fake intl API would be loaded optionally .. heck maybe the user even has to put it in explicitly .. so if we are breaking other peoples code .. just fix the fake intl layer
Jan 27 11:58:23 <henrikbj_>	 If people use sf2 a "pro" framework the would know what intl is and how to install it
Jan 27 11:58:23 <eriksencosta>	lsmith: but this way it will be easier to just drop the classes when intl get in php core
Jan 27 11:58:25 <bschussek>	or badly written queries
Jan 27 11:58:32 <bulatshakirzyano>	I'm with bschussek - two strategies/drivers
Jan 27 11:58:44 <henrikbj_>	Erik it is in core
Jan 27 11:58:52 <Seldaek>	bschussek: it's still adding a performance hit in the badly written symfony then :p
Jan 27 11:58:54 <jmikola|w>	realistically, intl is only a problem for developers, i think most prod environments aren't mac servers and can easily get php5-intl installed as a package :)
Jan 27 11:58:57 <bulatshakirzyano>	either using jmikola|w's suggestion or using two formatters as bschussek suggests
Jan 27 11:58:57 <lsmith>	eriksencosta: easier? once everybody really has intl installed .. you seriously dont want to keep the wrapper?
Jan 27 11:59:11 <lsmith>	but its bundled with 5.3
Jan 27 11:59:15 <lsmith>	just not enabled by default IIRC
Jan 27 11:59:26 <henrikbj_>	Yes
Jan 27 11:59:30 <bschussek>	lsmith: once everybody has intl installed, we can change the implementation
Jan 27 11:59:31 <eriksencosta>	are you sure?
Jan 27 11:59:36 <lsmith>	heh
Jan 27 11:59:37 <eriksencosta>	--enable-intl in ./configure?
Jan 27 11:59:45 *	henrikbj_ is now known as henrikbjornipad
Jan 27 11:59:48 <eriksencosta>	or --with-intl, not sure
Jan 27 11:59:49 <fabpot>	my point of view: we must not rely on intl being installed, we should not have overhead if intl is installed
Jan 27 12:00:05 <Seldaek>	bschussek: dropping the implementation is much easier by faking the intl lib is there
Jan 27 12:00:06 <lsmith>	anyway .. its 18:00 .. quick vote
Jan 27 12:00:06 <bulatshakirzyano>	fabpot +1
Jan 27 12:00:14 <lsmith>	fabpot +1
Jan 27 12:00:21 <Seldaek>	bschussek: the other way might have created dependencies in userland code
Jan 27 12:00:22 <lsmith>	(which means no wrapper)
Jan 27 12:00:23 <pgodel_work>	fabpot: +1
Jan 27 12:00:30 <iampersistent1>	fabpot: +1
Jan 27 12:00:30 <bschussek>	fabpot +1, but rephrase to "considerable overhead"
Jan 27 12:00:37 <fabpot>	bschussek: fine
Jan 27 12:00:44 <eriksencosta>	+1
Jan 27 12:00:47 <Seldaek>	well, then we're not voting on anything anymore
Jan 27 12:00:48 <dustinwhittle>	+1
Jan 27 12:00:49 <lsmith>	heh
Jan 27 12:01:05 <Seldaek>	we all agree on not deciding, great
Jan 27 12:01:05 <henrikbjornipad>	-1
Jan 27 12:01:15 <lsmith>	so it goes Seldaek :)
Jan 27 12:01:24 <lsmith>	in the end the person writing the code has the most say
Jan 27 12:01:37 <lsmith>	but i think the rest have experessed their preference
Jan 27 12:01:41 <henrikbjornipad>	Bobthecow have an excelent homebrew formula
Jan 27 12:01:47 <lsmith>	anyway .. thats it for this week