15:30:10 <mfer> #startmeeting openstack-sdk-php
15:30:11 <openstack> Meeting started Wed Jun 18 15:30:10 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:15 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:30:28 <mfer> Hello everyone. Please state your name along with any applicable affiliation.
15:30:30 <mfer> Matt Farina, HP
15:30:33 <samchoi> Sam Choi, HP
15:31:01 <jamiehannaford> Jamie Hannaford, Rackspace
15:31:24 <samchoi> Shaunak is out right? jamiehannaford
15:32:01 <jamiehannaford> yes I think so. I think Glen is in a meeting
15:32:26 <mfer> ok, thanks for the update
15:32:35 <mfer> #topic Agenda
15:32:50 <mfer> 1. Usage of final, private, and protected (mfer)
15:32:50 <mfer> 2. Reviews in progress - any questions/concerns? (samchoi)
15:33:00 <mfer> and changes or additions to make?
15:33:20 <samchoi> no, this seems good since we have a shortened meeting
15:33:41 <jamiehannaford> I have nothing to add
15:33:59 <mfer> #topic Usage of final, private, and protected
15:34:07 <mfer> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036842.html
15:34:18 <mfer> The link is to the list thread on this topic
15:35:36 <mfer> jamiehannaford I think we're coming at this from two different styles of writing PHP
15:35:52 <mfer> two different valid styles used in the PHP community
15:37:00 <jamiehannaford> I agree they're different approaches, but I don't think they just apply to PHP
15:37:16 <mfer> jamiehannaford how familiar are you with the style where folks need to override a piece of functionality and extend the class to do so. It's less about the `Cat extends Animal` method and more about the practicalities of getting something done
15:37:44 <mfer> I say PHP because some languages, like Python, don't have this issue because they don't have Private as an option
15:38:01 <jamiehannaford> how familiar? I know of it, and think it's wrong
15:38:20 <jamiehannaford> Python has a strong convention - so doesn't need keywords like private
15:38:24 <jamiehannaford> they tend to use _ and __
15:38:49 <mfer> sure, but if someone wants to they can access those... just at their own risk
15:38:50 <jamiehannaford> but it's a completely different culture, they see visibility in a completely different way from PHP I think
15:38:59 <jamiehannaford> I don't think we should allow that risk
15:39:18 <jamiehannaford> let me ask  a question:
15:39:29 <mfer> so, lets go back to the use cases. I'd prefer to solve problems than to get into opinions on style
15:39:35 * mfer waits for question
15:39:37 <jamiehannaford> do we support public visibility for properties?
15:39:45 <jamiehannaford> $server->name = 'foo';
15:40:00 <jamiehannaford> I mean, do we think it's a good idea
15:40:13 <jamiehannaford> or do we instead support $server->setName('foo');
15:41:40 <jamiehannaford> we choose the latter, don't we?
15:42:11 <mfer> That's up for debate. The reason is important. A class has a behavior described by an interface. The caller should only be concerned with the interface. Whether that's the thing we ship, what someone extended from our stuff (using ours as the basis for theirs), or something else all together that supports the interface.
15:42:27 <jamiehannaford> completely agree
15:42:27 <mfer> Are they protected or public.... if they are public than it needs to be clearly docuented
15:42:37 <jamiehannaford> the interface is the most important thing
15:42:54 <mfer> enabling developers to be successful is the most important thing
15:42:57 <jamiehannaford> modifying properties directly is completely undermining an interface
15:43:21 <mfer> we're not building a library... we're enabling developers to access openstack services. i view it differently than if i was creating something like a UUID library
15:43:56 <mfer> the question is, how do we enable a wide variety of developers who use different conventions to be successful?
15:43:56 <jamiehannaford> what do you mean by "library"?
15:44:20 <mfer> the code we include in the SDK to get people going. The library/binding
15:44:49 <jamiehannaford> I don't understand what you mean - we are building a "library" or "kit" that enables devs to work with openstack APIs
15:45:38 <mfer> our goal isn't to build the library. the goal is to enable a wide variety of developers to be successful accessing openstack services. we're including a library only as a way to meet that goal
15:46:12 <mfer> so, we need code that wordpress devs, drupal devs, symfony devs, home grown framework devs, zf devs, and many others can use
15:46:20 <mfer> and enables them to be successful
15:46:33 <mfer> rather than having different libraries for different communities
15:46:39 <jamiehannaford> how does using protected visibility make developers more successful?
15:46:49 <mfer> like one that feels right for drupalers, one that feels right for symfony folks, etc
15:46:57 <jamiehannaford> so here's the thing
15:47:06 <jamiehannaford> today I went into #symfony on irc and asked about this
15:47:16 <mfer> that's not the protected part. it's the private/final part that changes development habits
15:47:20 <jamiehannaford> I asked people they're opinion on using private visibility and encourage alternative ways of extension
15:47:34 <jamiehannaford> nearly everyone I spoke to had very strong ideas that private visibility was right, and the way to go
15:47:45 <jamiehannaford> I also did this on Stack Overflow
15:48:07 <jamiehannaford> and I looked at some of the most popular libraries for PHP - all advocate private visibility because it enforces encapsulation
15:48:09 <mfer> so, i went to Drupal developers (who are a different breed) and asked the same question. And I was universally told not to use private
15:48:19 <mfer> and I went to developers of some other libraries who said the same thing
15:48:32 <jamiehannaford> could you share those conversations on the mailing list? I'd like to see the feedback
15:48:41 <jamiehannaford> I'll post my R&D too
15:48:46 <mfer> asking a community (sub-culture) of the whole PHP their opinion isn't going to represent PHP devs... jsut that subculture
15:48:53 <samchoi> jamiehannaford: I've been seeing more mixed responses on sites such as Stack Overflow, especially when the private/protected/public debate came up for other OO languages
15:49:14 <samchoi> I'm surprised that a public site would heavily lean towards one side exclusively
15:50:01 <jamiehannaford> samchoi did you see responses from php people? what do other OO languages feel about this?
15:50:10 <jamiehannaford> I know you have experience with them
15:50:21 <samchoi> Yea, it was pretty interesting to see the variety of responses :)
15:50:40 <samchoi> One question, the votes would lean towards protected/public, the next question would lean towards private...
15:51:00 <mfer> i think it's important to note that the community around symfony doesn't represent PHP as a whole. Far from it. I don't want to go down a stylistic route that inhibits the development of those who take a different path.
15:51:18 <jamiehannaford> symfony, composer, guzzle, phpspec, behat
15:51:33 <jamiehannaford> millions of downloads, thousands of stars - I'd say that's a fair representation, no?
15:52:20 <samchoi> in C++, if I remember correctly, final classes weren't supported by most distributions until as late as 2012. The C++ community is still asking why final classes exist from what I've observed.
15:52:59 <jamiehannaford> hmm, I have no C++ experience, zilch :)
15:53:09 <jamiehannaford> community involvement is great, but inevitably we should decide based on what *we* believe in
15:53:17 <jamiehannaford> I believe that an interface is the most important thing
15:53:22 <mfer> Drupal has millions of downloads. It's just not a project on github. very different style. Even Drupal 8 which is using some Symfony components isn't adopting the Symfony style for its own code
15:53:26 <jamiehannaford> state should be modified through an interface
15:53:44 <mfer> Wordpress has millions of downloads and is stylistically entirely different
15:53:57 <mfer> going by github numbers only holds to projects on github
15:53:59 <jamiehannaford> are you advocating we use a procedural style like WP?
15:54:18 <mfer> haha, no. just making it in a way accessible to those developers to integrate in
15:54:41 <mfer> my point was more to look at community opinions. symfony with millions of downloads is still a subset of PHP developers
15:54:49 <jamiehannaford> but if developers *are* successful with symfony, guzzle et al - why do you think they won't be if we use private visibility?
15:54:53 <jamiehannaford> that's what i don't understand
15:55:04 <mfer> lets go to my two use cases
15:55:32 <jamiehannaford> samchoi what do you think about the importance of an interface?
15:55:32 <mfer> "1. Someone needs to add functionality to a class but can't add it back
15:55:32 <mfer> upstream. That could be because they are in a hurry to get their app
15:55:32 <mfer> out and aren't concerned with contributing it or because the
15:55:32 <mfer> organization they work for won't let them release it in a timely
15:55:32 <mfer> manner or ever."
15:55:54 <mfer> this could be added functionality or a bug
15:56:06 <samchoi> can you elaborate jamiehannaford ? Since I could misinterpret what you mean
15:56:24 <mfer> the easy way I've seen countless times is to extend the class, alter what needs to be altered, and use the new class in place of the old one
15:56:32 <mfer> what alternative method should be used?
15:56:36 <jamiehannaford> there's so ways to change the state of an object: the first is directly accessing its properties. the second is to call methods defined on an interface
15:56:45 <jamiehannaford> I heavily prefer the second
15:57:05 <mfer> no, i mean the internals of what's happening (not what's passed in or returned) needs to be changed
15:58:32 <jamiehannaford> mfer could you elaborate on what type of functionality we expect users to be adding to the SDK?
16:00:39 <samchoi> more than the exact functionality being added to the SDK, I thought the bigger issue was that the small group of contributors we have wouldn't be able to predict what our end users would ultimately end up doing with the SDK?
16:00:42 <mfer> an assumption is we know what to expect. i don't think we can ever say we know everything they'd want to do.
16:01:20 <mfer> say the openstack setup they're talking to has a custom extension. so, they need to alter a method on a class to take advantage of that extension
16:04:17 <mfer> another example is they want to inject logging in specific spaces between the code. maybe it's for debugging or custom audit purposes.
16:04:31 <jamiehannaford> mfer you'd use DI for that
16:04:40 <jamiehannaford> that satisfies the PSR interface or something
16:05:02 <jamiehannaford> I can't really respond with specifics unless there's a specific scenario you're worried about
16:05:12 <mfer> that's the idea. we don't knwo the specifics
16:06:13 <jamiehannaford> an API is a promise to the end-user - if we're not confident in it, or don't enforce it, what value does it have?
16:06:47 <jamiehannaford> all I'm saying is that there are better ways to extend behaviour
16:06:56 <jamiehannaford> ways that are well known to LOTS of PHP devs
16:07:03 <mfer> the promise is defined in the interface. we supply one implementation of that against vanilla openstack.
16:07:18 <jamiehannaford> and if we think inheritance is the ONLY thing they know, we're selling them massively short
16:07:23 <mfer> how people alter openstack (which is built in) or need to extend our SDK is up to them
16:07:36 <jamiehannaford> sure, and inheritance is not the only way to do that
16:07:43 <jamiehannaford> it's actually an anti-pattern that causes a lot of harm
16:07:58 <jamiehannaford> this is not a debate about extension. I support extension massively
16:08:16 <jamiehannaford> this is about whether inheritance should be actively promoted with open visibility
16:09:32 <mfer> open visibility to what? to all the innerds or just a subset chosen by the developer who doesn't know the use case the new person has to deal with
16:09:59 <mfer> there's a difference between a promise (though an interface) and enabling devs of different styles to extend things
16:10:08 <jamiehannaford> protected visibility is as dangerous as public visibility
16:10:35 <mfer> to whom? the person who needs to make a fast alteration to deliver on time
16:10:45 <jamiehannaford> mfer I disagree. you're unnecessarily promoting bad practice when there better and more effective ways to extend/modify/access behaviour
16:10:54 <mfer> note, the alternative will be people who change the core code of the class and have to manage that change... or not
16:10:59 <mfer> there will be people who do that
16:11:09 <jamiehannaford> yes, and to us who can't refactor something in 6 months because we've opened up the entire class
16:11:23 <mfer> they will just stay with their legacy code which they've altered
16:11:43 <mfer> if we refactor we increment the semver accordingly
16:11:57 <jamiehannaford> right, but you can't introduce a non-BC change
16:12:09 <jamiehannaford> making things protected obliges us to support multiple APIs
16:12:14 <mfer> we make promises with interfaces and the code openstack ship noted via semver. what others do with it is on them not us
16:12:14 <jamiehannaford> which restricts us down the line
16:12:57 <jamiehannaford> so if we're actively saying "do not do this - it is not supported" and we know other libraries are incredibly successful pushing other forms of extension, why do we believe inheritance is right for us?
16:12:59 <mfer> any change they make to our stuff is on them not us
16:13:21 <mfer> we can't make API changes without incrementing the first number of the semver
16:13:57 <jamiehannaford> we have a responsibility to our users to make sure we support them - we can't just say "use whatever, but we don't support this bit if you break it"
16:14:00 <mfer> we need to be careful to not try to control people but instead enable
16:14:17 <mfer> if they alter the codebase they altered it
16:14:17 <jamiehannaford> we support them with well-defined APIs and solidify those expectations
16:14:22 <samchoi> About public/protected, I would argue that it's not dangerous given that things like the final class weren't around until Java introduced it. Some languages still don't have a concept of final classes. End users of APIs were doing alright before the concept of 'final' existed so it seems a bit extreme so say that we're restricting ourselves simply by making classes extendable
16:14:48 <samchoi> however, I do support final classes in the right circumstances
16:15:11 <samchoi> although, imo, it'd be rare for an API like ours
16:15:43 <samchoi> and sorry getting distracted by a 2nd meeting
16:16:10 <jamiehannaford> but the fact is, it doesn't matter what we didn't have in the past - we have these language features now
16:16:10 <mfer> there are patterns where we don't need private/final and are fairly simple for this stuff
16:16:14 <jamiehannaford> they were introduced for a reason
16:16:24 <mfer> when to use them is debated
16:16:31 <jamiehannaford> mfer which patterns?
16:17:12 <mfer> jamiehannaford so, samchoi and I are totally distracted in a second meeting. i need to pay attention right now. can I send it to the mailing list?
16:17:25 <jamiehannaford> yeah, sure
16:17:36 <jamiehannaford> sorry for overrunning :)
16:17:45 <samchoi> good discussion topic
16:19:37 <mfer> jamiehannaford nothing to be sorry about. i understand where all this is coming from. I just happen to have spent time in other corners of the PHP world. I want to help all of them be successful. even many of those who will do things I won't.
16:19:55 <mfer> I know we didn't get to all the topics... is it ok to end now?
16:20:07 <jamiehannaford> yep, fine with me
16:20:13 <samchoi> alright
16:20:59 <mfer> jamiehannaford thanks!
16:21:03 <mfer> #endmeeting