<ac:macro ac:name="toc" />
<li>Date: 16 May 2012, 20:00-21:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-05-16 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 23 May 2012</li>
<h3>Rename Zend\Module to Zend\ModuleManager</h3>
<p>(Search for "20:02:00" in the log.)</p>
<p>Several folks have called for some naming conventions around components. In particular, Ralph Schindler (ralphschindler) has recommended renaming <code>Zend\Module</code> to <code>Zend\ModuleManager</code> – largely as the big players in the new MVC are EventManager, ServiceManager, and modules.</p>
<p>Evan Coury (EvanDotPro), author of the module component, expressed that he doesn't like having "Manager" as part of the component name (and shared some interesting links pointing out why), but would go with whatever the consensus was.</p>
<p>A quick vote was in favor of renaming. Matthew (weierophinney) suggested he could do the renaming as part of a pull request he's doing on ServiceManager <-> MVC integration, as he's already touching the component.</p>
<p><strong>tl;dr</strong>: <code>Zend\Module</code> will be <code>Zend\ModuleManager</code> on master soon, and in beta4.</p>
<h3>Composer as a possible solution for autoloading in ZendSkeletonApplication</h3>
<p>(Search for "20:12:23" in the log.)</p>
<p>A number of people, including Marco Pivetta (ocramius), Rob Allen (Akrabat), and Kyle Spraggs (SpiffyJr) have been experimenting heavily with Composer (<a class="external-link" href="http://packagist.org">http://packagist.org</a>) for dependency management lately. Rob has provided groundwork for ZF2 to provide per-component Composer packages, and we have a composer.json in the ZF2 repository and registered with packagist.</p>
<p>Marco would like to take this further, to the skeleton application, for installing ZF2 itself. This would potentially prove simpler to maintain and support, particularly as git submodule usage is often hard to explain (especially to those not using the command line git tooling). </p>
<p>The primary discussion centered around:</p>
<li>Should this be the default and suggested installation mechanism for the skeleton application?</li>
<li>If so, should we provide support for the composer autoloader?</li>
<li>If so, should we also still provide docs for using git submodules?</li>
<p>The votes were overwhelmingly in favor of using composer. The consensus was that we should retain the directions for git submodule usage, but encourage composer usage. Additionally, we decided to try and provide support for the composer autoloader for components/packages/etc. managed by composer, while still supporting ZF2's autoloading mechanisms (which might be necessary for site-specific modules and/or libraries).</p>
<p>While we'd like to target beta4, it will not be a requirement for the beta4 release.</p>
<p><strong>tl;dr</strong>: Expect Composer to be the default install mechanism for the skeleton application and modules in the near future.</p>
<h3>Beta 4 Status Report</h3>
<p>(Search for "20:23:05" in the log.)</p>
<li>Forms have been merged to master</li>
<li>ServiceManager has been merged to master</li>
<li>ServiceManager <-> MVC integration is close to completion and merging to master</li>
<li>A ton of DB updates have been merged to master, and the last features for beta4 are nearing completion</li>
<li>The "rename interfaces" story is complete, though a few pull requests are pending merges</li>
<li>i18n, console, and escaper have been dropped from beta4, and are currently targetted for beta5</li>
<p>At this point, it looks like the release will happen Monday, 21 May 2012, or Tuesday, 22 May 2012.</p>
<p>We also started some discussion of what will occur for beta5, and what cleanup needs to occur before we can start the RC phase for 2.0.0. Read the log for details.</p>
<p><strong>tl;dr</strong>: Huge changes are either in place or about to be merged – and beta4 will drop in the next few days!</p>
<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
white-space: -moz-pre-wrap; /* Mozilla, supported since 1999 */
white-space: -pre-wrap; /* Opera 4 - 6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 - Text module (Candidate Recommendation) http://www.w3.org/TR/css3-text/#white-space */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
20:01:19 <weierophinney > Reminder, Agenda is HERE: http://bit.ly/K7gtJc
20:01:35 <weierophinney > I'm going to go in reverse order
20:02:00 <weierophinney > So, first topic is: "Rename Zend\Module to Zend\ModuleManager"
20:02:18 <weierophinney > ralphschindler: is this your topic? or is for EvanDotPro/Akrabat?
20:02:25 < prolic > mine
20:02:26 < prolic >
20:02:39 <weierophinney > ah, okay.
20:02:44 <weierophinney > So, let's discuss
20:02:55 < prolic > ralph and me proposed this to evan and we had a short discussion about that
20:03:09 < EvanDotPro > yeah... there's a mailing list thread as well
20:03:15 < prolic > the reason behind this change is consistency
20:03:23 <ralphschindle > ah, reverse order
20:03:23 <ralphschindle > yes
20:03:26 <ralphschindle > its both of us
20:03:40 < EvanDotPro > http://zend-framework-community.634137.n4.nabble.com/quot-Manager-quot-suffix-on-component-names-td4589647.html
20:03:41 <ralphschindle > I proposed, originally, that Module become ModuleManager
20:03:51 <ralphschindle > Zend\Module actually has no modules in it
20:03:58 < prolic > +1
20:04:08 < mbn_18 > +1
20:04:14 < MikeA_ > +1
20:04:16 <weierophinney > EvanDotPro: what are your thoughts, as author of the component?
20:04:32 <ralphschindle > it would make it more consistent with other things: EventManager and ServiceManager, and these 3, together, are the hero components of the MVC stack
20:04:39 < SpiffyJr > Holy crap. I got the channel right on the first try.
20:04:45 < EvanDotPro > i personally don't like classes that end in "Manager" or even "er"
20:05:02 <ralphschindle > why?
20:05:14 < EvanDotPro > http://objology.blogspot.com/2011/09/one-of-best-bits-of-programming-advice.html
20:05:15 <ralphschindle > Manager is just as much a noun as Module
20:05:18 < mbn_18 > But our is a manager...
20:05:35 < mbn_18 > Our/it
20:05:59 < EvanDotPro > but that's only a personal opinion i hold. i'm absolutely fine with whatever we choose as long as there's consistency
20:06:06 < mbn_18 > Name should be transparent as possible
20:06:39 < prolic > another reason: matthew brought this up in a thread on the ml, long time ago: the default implementation that we offer should have the same name as it's namespace, so we need to have another name for the interface
20:07:22 < Bilge > This looks like fun
20:07:31 <ralphschindle > prolic: i brought that up, its a identifiable "entry point" object
20:07:32 < EvanDotPro > i agree there. Zend\Module might be a little vague, and Zend\Module\Module wouldn't make a ton of sense.
20:07:36 < prolic > acutally, the module manager is the main thing the component offers
20:07:38 <ralphschindle > that was in my interface naming document
20:07:51 < EvanDotPro > ah yeah, that was ralphschindler's. i rememver that.
20:07:54 < EvanDotPro > remember*
20:07:54 < prolic > sorry @ralphschindler, i thought matthew was it
20:08:01 < mbn_18 > Let's votes
20:08:21 <weierophinney@> !start-vote Rename Module component to ModuleManager?
20:08:21 < Zend\Bot > Vote "Rename Module component to ModuleManager?"; type either +1, -1 or 0
20:08:26 < SpiffyJr > +1
20:08:31 < mbn_18 > +1
20:08:32 < prolic > +1
20:08:32 < MikeA_ > +1
20:08:36 < SocalNick > 0
20:08:39 < EvanDotPro > -1
20:08:40 <ralphschindle > +1
20:08:43 < pulpfree > +1
20:08:48 < SpiffyJr > EvanDotPro, I think you lose.
20:08:52 < prolic > lol
20:08:57 < EvanDotPro > (though i'm +1 for a better name than Zend\Module)
20:08:59 < san > -1
20:09:02 <weierophinney@> Akrabat, DASPRiD, WalterTamboer, Freeaqingme, Gabriel403 ?
20:09:06 < SpiffyJr > EvanDotPro, but I'll give you +0.5 for avoiding peer pressure
20:09:19 <weierophinney@> +1
20:09:30 <weierophinney@> rizza?
20:09:33 < mbn_18 > This is not football. No one loose
20:09:35 <weierophinney@> mwillbanks?
20:09:42 < bjy > +1
20:09:53 < rizza > +1
20:10:31 < Gabriel403 > 0
20:10:49 <weierophinney@> !end-vote
20:10:50 < Zend\Bot > Vote result for "Rename Module component to ModuleManager?": 9 positives, 2 negatives and 2 neutrals, consensus: 7
20:11:07 <weierophinney@> I think that can be called a majority no matter how you look at it.
20:11:14 < SpiffyJr > Erm hrm.
20:11:16 <weierophinney@> EvanDotPro: shall I make that change in the branch I'm working on?
20:11:26 <weierophinney@> since I'm already doing sweeping changes anyways?
20:11:36 < EvanDotPro > weierophinney: that's fine, so it's one big merge.
20:11:36 < prolic > i can do it, too
20:11:50 < EvanDotPro > prolic: weierophinney is doing some stuff that would conflict, so might be best if he does it.
20:11:53 < prolic > but go ahead
20:11:53 <weierophinney@> prolic: I'm working on changes to the Module component already – best if I keep all changes together.
20:12:23 <weierophinney@> kk, next topic: "Composer as a possible solution for autoloading in ZendSkeletonApplication"
20:12:36 <weierophinney@> I believe SpiffyJr is already working on this
20:12:42 < SpiffyJr > and ocramius
20:12:49 < SpiffyJr > Might want to expand that to also include modules?
20:12:51 <ralphschindle > part 2 of this is, there is an abigious set of code in there called "Consumer/Provider", I suggested calling this "Feature" since features of a module could be provding or consuming "stuff"
20:12:54 < SpiffyJr > Although modules are entirely "userland"
20:12:59 <weierophinney@> I'd like to note that we could actually have docs for both approaches; they're not mutually exclusive.
20:13:06 < Akrabat > sorry - back
20:13:11 <weierophinney@> ralphschindler: I already made that change in my branch.
20:13:18 <ralphschindle > oh:?
20:13:19 <ralphschindle > ok
20:13:34 <ralphschindle > so its an AutoloadFeature implements FeatureInterface?
20:13:37 <weierophinney@> ralphschindler: discussed it in #zftalk.2 over the last couple days, and moved forward on it this morning.
20:13:42 <ralphschindle > ok
20:13:46 <weierophinney@> ralphschindler: no, no feature interface – just feature namespace.
20:13:51 < Akrabat > FTR, I was +1 on ModuleManager too
20:13:55 <weierophinney@> Akrabat: cool
20:14:04 <weierophinney@> BACK TO TOPIC, please.
20:14:16 <weierophinney@> SpiffyJr and ... where's ocramius?
20:14:25 < SpiffyJr > Good question.
20:14:32 < SpiffyJr > He's the one that actually put it on the agenda...
20:14:41 <weierophinney@> I'm trying to summon him from #zftalk.2
20:14:58 < SpiffyJr > Any other topics we could skip to?
20:14:59 <weierophinney@> Has everybody read the agenda item?
20:15:09 < Akrabat > I'm generally in favour of Composer for Skeleton
20:15:15 < prolic > me too
20:15:15 < mbn_18 > Are you the summoner?
20:15:22 <weierophinney@> And does anybody have objections to having composer be one of the possibilities for installation?
20:15:35 <ralphschindle > im fine with it until a better solution presents itself
20:15:49 < SocalNick > can I ask a question about composer in the meantime? maybe someone knows...how does composer work when you are actively developing the Modules that are being included via composer? i.e. with Git submodules, each module is a separate repo I can commit to...
20:15:52 < Akrabat > we need to work out how to do autoloading
20:15:55 < san > Doesn't Pear or Pyrus could do almost the same things as Composer?
20:16:14 < SpiffyJr > SocalNick, Composer uses native tools (git, svn) to checkout
20:16:18 <weierophinney@> SocalNick: I think you can point composer to a branch, and then just periodically update.
20:16:23 < SpiffyJr > SocalNick, so the modules that are included are repositories
20:16:30 < SpiffyJr > SocalNick, You can also specify alternative branches to use for dev
20:16:32 <ralphschindle > san: not really, no
20:16:35 < Akrabat > SocalNick: I would remove it from composer and use git if I was developing. However, I'll explore with Jordi
20:16:45 < EvanDotPro > if disadvantage #1 is true (i don't know), that may increase our support workload in #zftalk.2, but that said, i'm not against adding installation methods, regardless.
20:16:50 <weierophinney@> Akrabat: SpiffyJr was working on the autoloading bit, actually
20:17:00 < Akrabat > SpiffyJr: pear/pyrus seems to favour global install. Composer is always local
20:17:05 < SpiffyJr > weierophinney, was holding off until this meeting is finished
20:17:13 <weierophinney@> Akrabat: my suggestion was to use the composer autoloader for things installed via composer, and ZF2 autoloaders otherwise.
20:17:18 < Akrabat > san: pear/pyrus seems to favour global install. Composer is always local
20:17:24 < prolic > so perhabs invent a new solution entirely writting in php
20:17:32 < Akrabat > weierophinney: that's worth investigating
20:17:35 <weierophinney@> EvanDotPro: it'd only be an issue really until we go RC
20:17:42 < SocalNick > Akrabat - so if you are just using a module, composer works fine - if developing a module inside an app, use submodule?
20:17:47 < mwillbanks > sorry catching up now busy week so far
20:17:48 < SpiffyJr > EvanDotPro, once master is in a more stable state it won't change as often.
20:17:50 < EvanDotPro > weierophinney: right
20:17:55 <WalterTamboer > The main problem for me was that I used Doctrine in combination with ZF2, the submodule part of git made a BIG mess of the structure.
20:18:03 < SpiffyJr > WalterTamboer, very big mess
20:18:08 < Akrabat > SocalNick: as I say, we'll investigate with Jordi, but that's what' I'd do
20:18:10 <weierophinney@> Akrabat: actually, pyrus favors local installs at this time. But it's harder to get working, and not much info on creating channels currently
20:18:16 < SpiffyJr > There's also other instances were conflicting submodules might pose an issue.
20:18:22 < Akrabat > weierophinney: really? their docs suck then!
20:18:28 <weierophinney@> Akrabat: indeed.
20:18:54 < Akrabat > EvanDotPro: I think disadvantage 1 is actually an advantage
20:19:01 < Akrabat > if we play our cards carefully
20:19:18 <WalterTamboer > As I commented at the wiki, it's so easy to setup an application using Composer that I definitely think that Composer is the best option available right now.
20:19:22 < san > Akrabat, I think taht Pyrus aslo can install packages localy… just strange to use 2 tools for so commun task. Hard to lear so much new for developers who only starting to lear zf.
20:19:27 <weierophinney@> Akrabat: I think so as well – it's also why I've liked using pyrus. Pinning is a good thing, as it prevents the WTF factor.
20:19:47 <weierophinney@> so...
20:19:48 < Akrabat > we need to ensure that we keep "casual" users on the released beta
20:20:13 <weierophinney@> !start-vote Use Composer as one solution (default) for ZendSkeletonApplication
20:20:13 < Zend\Bot > Vote "Use Composer as one solution (default) for ZendSkeletonApplication"; type either +1, -1 or 0
20:20:21 < Akrabat > +1
20:20:22 < prolic > +1
20:20:25 <weierophinney@> +1
20:20:25 < mwillbanks > +1
20:20:30 <WalterTamboer > +1
20:20:31 < mbn_18 > 0
20:20:31 < SpiffyJr > +1
20:20:31 < EvanDotPro > Akrabat: true... we'd just have to direct them to using the tag and tell them they're on their own if they're trying to follow master.
20:20:32 < MikeA_ > 0
20:20:35 < EvanDotPro > +1
20:20:35 < rizza > +1
20:20:39 < SocalNick > +1
20:20:41 < mwillbanks > composer makes me happy
20:20:46 < rizza > Indeed.
20:20:48 < rhunwicks > +1
20:20:49 < bjy > +1
20:20:50 < SpiffyJr > Yea, I was anti-composer until I started using it
20:20:52 <weierophinney@> EvanDotPro: as you say: ZF2_PATH if you want cutting edge.
20:20:55 < SpiffyJr > Now that I have it's incredibly easy to use.
20:20:59 <ralphschindle > 0
20:21:08 < Akrabat > EvanDotPro: exactly - and if they are on master, then they can deal with git
20:21:34 < SpiffyJr > There will still be the option to use submodules
20:21:35 < Akrabat > SpiffyJr: same here. I was dead against any package manager other than plain old zip files
20:21:37 <weierophinney@> !end-vote
20:21:38 < Zend\Bot > Vote result for "Use Composer as one solution (default) for ZendSkeletonApplication": 11 positives, 0 negatives and 3 neutrals, consensus: 11
20:22:03 <weierophinney@> SpiffyJr: exactly – I think we retain the submodule docs, but have composer as the first option, and preferred.
20:22:18 < prolic > great
20:22:32 <weierophinney@> and docs to remove the ZF2 entry in composer.json if you opt for submodule.
20:23:05 <weierophinney@> Last topic: Beta4 Status Report
20:23:08 <weierophinney@> Lots to report!
20:23:09 < prolic > you can even use plain old zip files should still work
20:23:18 <weierophinney@> I'll start this one.
20:23:40 <weierophinney@> Forms have been merged to master. There's a post on the ML (somebody dig up a link, please!) with some links to examples.
20:23:46 <weierophinney@> I'll be getting docs in the next day or two.
20:23:57 <weierophinney@> ServiceManager has been merged to master. Docs are on their way.
20:24:12 <weierophinney@> Lots of DB updates (I'll have ralphschindler expand on this in a minute)
20:24:18 < Akrabat > http://zend-framework-community.634137.n4.nabble.com/Forms-now-in-master-td4637456.html
20:24:35 <weierophinney@> I'm zeroing in on ServiceManager <-> MVC integration, and working with EvanDotPro to finalize the last use cases.
20:25:12 < prolic > so mvc integration is not yet finished?
20:25:22 < EvanDotPro > EXPECT A HANDFUL OF BC BREAKS – within the next couple of days before B4. We'll outline them on the ML and PR descriptions as they're merged... but know they're coming.
20:25:29 <weierophinney@> DASPRiD has indicated he'd like to move i18n to beta5. Artur has said the same for Console. No word from Padraic on Escaper. Those latter two may be moved to 2.1 if they cannot be completed in the next few weeks.
20:25:54 <weierophinney@> My goal is to release Friday, but, realistically, it'll likely be Monday or Tuesday.
20:26:05 <weierophinney@> ralphschindler: want to outline the DB updates now?
20:26:11 <weierophinney@> Akrabat: thanks!
20:26:11 < Akrabat > don't want Escaper to not be in 2.0
20:26:13 <ralphschindle > Sure
20:26:24 <ralphschindle > i am not going to recap stuff that happened earlier than last week
20:26:32 <weierophinney@> Akrabat: I'd rather not as well, but I cannot get any word from Padraic, unfortunately.
20:26:36 <ralphschindle > like the major pulls on expressions, joins, etc
20:26:47 < Akrabat > weierophinney: we need redundancy on that component anyway
20:27:12 <weierophinney@> ralphschindler: so, indicate what you're finishing up.
20:27:38 <weierophinney@> OH! quickly – ezimuel finished up Zend\Crypt, including refactoring all components that were using it or using custom crypt/bigint solutions.
20:27:45 <weierophinney@> ralphschindler: I'm done.
20:27:59 <ralphschindle > but recently: mysqli buffer support, sqlite count() support, Exceptions for Zend\Db\Adapter have been completely (pull request to follow this meeting), I am also working on TableGateway API and RowGateway API improvments, and lastly, will look into Zend\Paginator integration (I believe all other integration with Zend\Db is working at this moment)
20:28:14 <ralphschindle > completed*
20:28:31 < Akrabat > ralphschindler: do we get pdo buffer support too?
20:28:38 <WalterTamboer > Sounds good guys but I'm actually interested in stuff that's still open
20:28:44 < prolic > me did a PR in db, too
20:28:48 <ralphschindle > Akrabat: theres actually no abstraction for PDO buffering that i know of
20:29:07 < Akrabat > ralphschindler: how do we foreach() twice over results from SQL Server ?
20:29:37 <ralphschindle > ah
20:29:38 <ralphschindle > so
20:29:45 <ralphschindle > buffer() is now part of the ResultInterface
20:30:03 < EvanDotPro > ralphschindler: just want to confirm that table aliases in a join is on your list (ie, for joining the same table twice)?
20:30:10 <ralphschindle > which means the API is always available, and we can determine on a driver by driver basis what it actually does, if anything
20:30:18 < Akrabat > also, is there any point in keeping Pdo-Mysql ?
20:30:20 <ralphschindle > EvanDotPro: i can do that, pretty simple
20:30:26 <ralphschindle > yes
20:30:48 <ralphschindle > well, first, if its part of PDO, its part of Zend\Db's Pdo implementation
20:30:49 < Akrabat > the main use-case fail I had at my ZF2 training when it came to Zend\Db was being able to foreach() twice over a resultset
20:30:51 <ralphschindle > theres no "taking it out"
20:30:54 < EvanDotPro > ralphschindler: great, that would be very useful for some stuff my team and i are working on.
20:31:20 <ralphschindle > Akrabat: buffer() for Pdo-mysqli could do a userland buffer
20:31:25 < Akrabat > that works for me
20:31:29 <ralphschindle > it would have to be called before first iteration
20:31:41 <ralphschindle > b/c with unbuffered results, after you pass a row, the server throws it out
20:31:42 < Akrabat > by "take out" I mkind of meant "we don't talk about it"
20:31:48 <ralphschindle > haha
20:32:03 < Akrabat > cos clearly, you could use pdo-anything
20:32:07 <ralphschindle > buffer() for mysqli effectively calls store_row
20:32:09 <ralphschindle > store_result*
20:32:10 < Akrabat > but we don't talk about the ones we know nothing about
20:32:11 < mwillbanks > weierophinney: so you're referencing 2.1 already; when is 2.0 supposed to be finalized or more or less finalized?
20:32:16 < ocramius > aaaaaaaaanf, connection, sorry guys
20:33:03 < prolic > hi ocramius
20:33:11 < Akrabat > mwillbanks: 2.0 is nearly feature complete
20:33:22 <weierophinney@> mwillbanks: We'll definitely have a beta5. I'd like that to be stable – in other words, to look like what we plan to distribute. If we absolutely must, we can do another beta after that, but I'd rather focus beta5 on finalizing what the library looks like. After that, we'd start doing RCs until stable.
20:33:33 < Akrabat > I'll try and raise on the ML my thoughts about the 2.0 release train once b4 is out
20:33:39 <ralphschindle > we need to talk about pulling code out in the next beta
20:33:40 <weierophinney@> Akrabat: awesome, thx
20:33:45 <weierophinney@> ralphschindler: exactly
20:33:47 < Akrabat > ralphschindler: yes - that's my view
20:33:58 <weierophinney@> but that goes along with other decisions we've made as well – moving service components out, etc.
20:34:02 < Akrabat > that's lots of stuff that we need to decide if we want to sign up to support
20:34:09 <weierophinney@> precisely
20:34:10 <ralphschindle > im not really comfortable with Pdf, its nothing more than a namespaced version of the one in v1 (and serveral other components too)
20:34:12 < Akrabat > of defer that decision
20:34:22 < Akrabat > Pdf and Lucene are my top two
20:34:40 < rhunwicks > Will there be any improvements to Zend/Db/Metadata in Beta4
20:34:49 < Akrabat > but loosely, we need service moved out and have strong maintainers for anything we ship in 2.0
20:34:51 <weierophinney@> yeah, mine too. Problem is, those have been two of our runaway, most popular components. But nobody is capable of maintaining them right now.
20:35:00 * ocramius catching up. Are we at #1?
20:35:06 < Akrabat > (sorry, this is for post b4)
20:35:09 <weierophinney@> ocramius: yes. We went backwards.
20:35:17 <ralphschindle > rhunwicks: i am doing a TableGateway feature where it uses metadata to populate columns, so, I am not sure what more I need for that use case out of metadata, what do you need?
20:35:39 < rhunwicks > The ability to determine the primary and foreign keys for a table
20:35:45 <ralphschindle > you can do that currently
20:35:59 < rhunwicks > The ability to inject the Adapter
20:36:28 < EvanDotPro > rhunwicks: you can inject the adapter into a TG... in fact, you have to, iirc.
20:36:29 <ralphschindle > rhunwicks: see this example:
20:36:29 < rhunwicks > You can do it in /master, or in your branch?
20:36:31 <ralphschindle > https://github.com/ralphschindler/Zend_Db-Examples/blob/master/example-10.php
20:36:43 <ralphschindle > thats been working against master since the last beta
20:37:41 < rhunwicks > I'm confused
20:37:43 < rhunwicks > https://github.com/zendframework/zf2/blob/master/library/Zend/Db/Metadata/Object/TableObject.php
20:37:53 < rhunwicks > has
20:37:55 < rhunwicks > public function getConstraints()
20:37:55 < rhunwicks >
20:38:19 <ralphschindle > that is odd now isnt it
20:38:22 < prolic > can we move that detailed db-specific question for after the meeting?
20:38:33 <ralphschindle > alright, ill clean it up, and check that functionality
20:38:40 < EvanDotPro > yeah, this can continue in #zftalk.2
20:38:41 * ralphschind puts it on his list
20:38:42 < rhunwicks > Sorry, I mean the inject the Metadata/Adapter into Metadata
20:38:46 < Akrabat > Can I raise PR queue?
20:38:57 < rhunwicks > so I can use a custom Metadata adapter instead of InformationSchema
20:39:10 <weierophinney@> Akrabat: please do.
20:39:17 <ralphschindle > lets move this to other room rhunwicks
20:39:17 < Akrabat > right.
20:39:20 < rhunwicks > Sure
20:39:25 <weierophinney@> Akrabat: I need to go through the stuff from over the weekend and the last two days.
20:39:26 < rhunwicks > After meeting
20:39:36 <weierophinney@> But... there's also a lot of old, lingering items in there.
20:39:37 <ralphschindle > whats left in here?
20:39:41 < Akrabat > There's around 40 items in the PR queue
20:39:43 <weierophinney@> ralphschindler: go look.
20:39:51 < prolic > sorry
20:39:56 < prolic > should i stop PRing?
20:39:58 < Akrabat > 90% of them need a specialist to approve for merge
20:40:03 <weierophinney@> CR-Team is assigned to a number of them, so please check and see if you can merge those.
20:40:04 <ralphschindle > i'd love to look at the agenda, i really would
20:40:09 < Akrabat > prolic: most arent' Zen-27
20:40:11 <weierophinney@> ralphschindler is assigned to quite a few.
20:40:15 <WalterTamboer > weierophinney: Do you have a list with items that still need to be done for a 2.0 release?
20:40:23 < prolic > zen-27 is finished today
20:40:32 <weierophinney@> prolic: I've merged most, other than the ones since Friday.
20:41:05 < prolic > i see that daily, thx @weierophinney
20:41:05 < Akrabat > It would be nice if DASPRiD, EvanDotPro, ralphschindler & weierophinney could run through and find the ones related to their specialities and either merge or close
20:41:10 <weierophinney@> WalterTamboer: I'm working on that. i18n is a must have; escaper is a should-have. There are some form additions I mention on the ML, and ralphschindler has a few DB things he's pushed to beta5.
20:41:26 < Akrabat > escaper is a must-have for me
20:41:28 < EvanDotPro > Akrabat: will do.. there's a couple that i was waiting on decisions from that i should be able to merge and/or close now.
20:41:32 <ralphschindle > Akrabat: im on it today, i konw there is a di one from ocramius that i will address soon
20:41:40 <weierophinney@> WalterTamboer: after beta4, I'm going to start making a list, and we'll vote on the items.
20:41:44 < Akrabat > thanks
20:41:52 < Akrabat > I'd like to set a deadline of Friday
20:42:10 <WalterTamboer > weierophinney: Ok. Maybe you can e-mail that around (just to inform the community)
20:42:23 < Akrabat > anythign that's not got a comment from this week on it by Friday, I'll close
20:42:40 < Akrabat > (on Saturday)
20:42:47 <weierophinney@> WalterTamboer: well, yeah – that's what I meant by vote on it. I'll be doing an RFC, we'll discuss, and then vote during a meeting.
20:43:18 <WalterTamboer > ok cool.
20:43:24 < EvanDotPro > Akrabat: sounds fair to me
20:43:36 <weierophinney@> I like how Akrabat thinks.
20:43:50 < Akrabat > WalterTamboer: for b5, I'd look to look at convenience stuff too
20:43:51 <weierophinney@> some of those have been lingering way too long without updates.
20:43:56 <weierophinney@> Akrabat: +1
20:44:12 < Akrabat > yes - either we're going to actually merge, or we're working on them to get them merged
20:44:18 < Akrabat > otherwise, it's just noise
20:44:20 <weierophinney@> there's a fair bit in the controllers we could make simpler (accessing query, post, request body, headers, etc)
20:44:34 <weierophinney@> kk, any other topics for now?
20:44:45 <weierophinney@> we have a fair chunk of work to get done in the next couple days.
20:45:10 <WalterTamboer > There is also still the coding convention issue. The naming of methods. Is a decision made there already?
20:45:55 < Akrabat > WalterTamboer: get/set ?
20:45:57 <ralphschindle > WalterTamboer: i dont think we've voten on it
20:46:01 <WalterTamboer > Akrabat: yes
20:46:01 <ralphschindle > voted*
20:46:18 <weierophinney@> WalterTamboer: no RFC, no vote
20:46:30 <ralphschindle > I think we'd need to identify exactly all the code that is affected by the proposed change
20:46:37 <ralphschindle > and what exceptions would be allowed
20:46:38 < prolic > can someone put the naming of methods discussion on the next meetings agenda?
20:46:41 < Akrabat > yeah - need an RFC on that - preferably very small
20:46:54 <weierophinney@> prolic: you can do it. Create the new agenda page and add it.
20:47:01 <weierophinney@> crap, I won't be here next week
20:47:02 <ralphschindle > Zend\Db\Sql\Select, IMO, is a candidate for the exception as the API is the major feature
20:47:04 < Akrabat > and then I can vote for "always do it one way or the other, but not both ways"
20:47:10 <weierophinney@> haha
20:47:26 < Akrabat > ralphschindler: I would agree with that
20:47:56 <ralphschindle > in which case, to conform, i would also do mutator/accessors <- i could go with that
20:47:56 < Akrabat > it's things like events() but getRequest() that bug me
20:48:11 <WalterTamboer > I'll see if I can create an RFC
20:48:15 < prolic > agreed @akrabat
20:48:17 <ralphschindle > setSelect(), getSelect(), and select() for fluency
20:48:21 <ralphschindle > for example
20:48:30 <ralphschindle > (just brainstorming)
20:48:31 < Akrabat > there's just enough ones that arent "get" that mean I get it wrong
20:48:36 <ralphschindle > but anyway
20:48:36 <WalterTamboer > It will probably contain a list of pro's and cons for each way
20:48:50 < Bilge > !start-vote Remove non-words like "prepend" with English words like "prefix"
20:48:53 <weierophinney@> I'm to a point where I hate "get", tbh.
20:48:53 < Bilge >
20:49:00 <weierophinney@> !end-vote
20:49:05 < Akrabat > the Sql stuff is different I think
20:49:16 < Akrabat > weierophinney: I'm fine with that - i code Objective-C too
20:49:24 <ralphschindle > like get() ? weierophinney or getSomething()
20:49:25 <ralphschindle > ?
20:49:29 < Akrabat > but then it should be $this->request()-query
20:49:32 <WalterTamboer > weierophinney: Call me old fashioned but I actually hate the opposite, but we had this discussion on the ML already
20:49:37 <weierophinney@> ralphschindler: getSomething()
20:49:39 < Bilge > Why isn't it getEvents()?
20:49:42 <weierophinney@> Akrabat: agreed
20:49:45 <ralphschindle > b/c having an IDE with code completion, get* groups everything nicely together
20:49:54 < Akrabat > Bilge: that's precisely the discussion
20:50:05 <weierophinney@> Bilge: because you're interacting with an object. Using the method just ensures you have an object in scope.
20:50:06 < Akrabat > ralphschindler: and that's the big advantage of the get prefix
20:50:09 < Bilge > Well what's to discuss? It's wrong as it is now
20:50:16 <ralphschindle > not having that means i have to hunt 26 letters of the alphabet to explore a classes api
20:50:38 <WalterTamboer > Akrabat: Not only that but it also implies what the method does
20:50:43 <weierophinney@> Bilge: not cut and dried. It's definitely a matter of opinion and style, not wrong vs right.
20:50:44 < Akrabat > as I say, I don't mind much either way - I just want everything to be the same
20:51:07 < Bilge > I'm of the opinion that all functions names should be comprised of at least two words where the first is a verb
20:51:19 <weierophinney@> Akrabat: that, I feel, is the only real argument – make a choice, but make it consistent.
20:51:20 < Bilge > So that you have some semblence of an idea about what it is the function is goign to do
20:51:27 <WalterTamboer > weierophinney: Agreed. I'll create an RFC with pro's and cons and than we can all shoot on it and discuss it during the next meeting
20:51:38 < ocra > I'd also prefer seeing get*, even if it lazily initializes stuff behind the scenes. I'm just a bit confused. Didn't we get that settled before?
20:51:42 < Akrabat > should have seen DASPRiD and I trying to remember how to get a param from the route when in a controller...
20:51:46 < Akrabat > WalterTamboer: thanks !
20:52:00 < ocra > (I mean the discussion)
20:52:03 <weierophinney@> WalterTamboer: thanks for offering to start the RFC.
20:52:05 < Bilge > I've actually forgotten to add parens () after calls like ->events because it looks like a field instead of a function
20:52:10 < Akrabat > ocra: no - just a ML discussion
20:52:15 < Bilge > If it was called getEvents there is no way I would forget the parens
20:52:17 < ocra > thx Akrabat
20:52:38 < Akrabat > Bilge: that's a fair point to the advantages of the get prefix side
20:52:47 <weierophinney@> Bilge: well, the distinction is less when using DI – as you can be reasonably assured the object is there when you need it.
20:53:01 < Akrabat > on the flip side, are there any ZF classes that expose public properties?
20:53:01 <weierophinney@> but yea, I get it.
20:53:08 < Bilge > I don't understand what you're talking about
20:53:17 <WalterTamboer > Akrabat: haha if so, they should be refactored immediately!
20:53:22 <ralphschindle > Akrabat: no, in fact, to expose something as a read-only property, i use __get()
20:53:28 <weierophinney@> I fall on both sides. I like the feel of removing get from the verbiage, but I also mainly just want it consistent.
20:53:32 < Bilge > I assume it's something to do with the advantage of dropping get but to my mind there aren't any besides it being shorter to write
20:53:37 < prolic > i think we still have public properties somewhere
20:53:41 < Akrabat > Bilge: I mean that we would never ever have $this->events->something
20:53:48 <ralphschindle > like the convenience properties of TableGateway and Adapter
20:53:52 <weierophinney@> Bilge: what I mean is: if the property is $events, and the method is events(), and the property gets injected, $this->events and $this->events() are equivalent.
20:54:15 < Bilge > Yeah but $this->events is private or at least protected
20:54:17 < Bilge > So I get an error
20:54:20 <ralphschindle > since php doesn't have read-only properties, i dont think we should utilize property chaining via real properties
20:54:28 < Akrabat > ralphschindler: yeah - Db seems to have a number of exceptions to the rule in order to make it look right
20:54:32 <weierophinney@> Bilge: ah – right, I'm talking about within the class itself.
20:54:47 < Akrabat > anyway
20:54:53 < Bilge > Well I speak as a consumer of the framework rather than a developer obviously
20:55:02 <ralphschindle > Akrabat: any of those things exposed magically are only there for consumer convenience
20:55:06 <weierophinney@> kk, let's call this meeting over for now – we can move discussion to #zftalk.2