15:30:10 #startmeeting openstack-sdk-php 15:30:11 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:30:15 The meeting name has been set to 'openstack_sdk_php' 15:30:28 Hello everyone. Please state your name along with any applicable affiliation. 15:30:30 Matt Farina, HP 15:30:33 Sam Choi, HP 15:31:01 Jamie Hannaford, Rackspace 15:31:24 Shaunak is out right? jamiehannaford 15:32:01 yes I think so. I think Glen is in a meeting 15:32:26 ok, thanks for the update 15:32:35 #topic Agenda 15:32:50 1. Usage of final, private, and protected (mfer) 15:32:50 2. Reviews in progress - any questions/concerns? (samchoi) 15:33:00 and changes or additions to make? 15:33:20 no, this seems good since we have a shortened meeting 15:33:41 I have nothing to add 15:33:59 #topic Usage of final, private, and protected 15:34:07 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/036842.html 15:34:18 The link is to the list thread on this topic 15:35:36 jamiehannaford I think we're coming at this from two different styles of writing PHP 15:35:52 two different valid styles used in the PHP community 15:37:00 I agree they're different approaches, but I don't think they just apply to PHP 15:37:16 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 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 how familiar? I know of it, and think it's wrong 15:38:20 Python has a strong convention - so doesn't need keywords like private 15:38:24 they tend to use _ and __ 15:38:49 sure, but if someone wants to they can access those... just at their own risk 15:38:50 but it's a completely different culture, they see visibility in a completely different way from PHP I think 15:38:59 I don't think we should allow that risk 15:39:18 let me ask a question: 15:39:29 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 do we support public visibility for properties? 15:39:45 $server->name = 'foo'; 15:40:00 I mean, do we think it's a good idea 15:40:13 or do we instead support $server->setName('foo'); 15:41:40 we choose the latter, don't we? 15:42:11 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 completely agree 15:42:27 Are they protected or public.... if they are public than it needs to be clearly docuented 15:42:37 the interface is the most important thing 15:42:54 enabling developers to be successful is the most important thing 15:42:57 modifying properties directly is completely undermining an interface 15:43:21 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 the question is, how do we enable a wide variety of developers who use different conventions to be successful? 15:43:56 what do you mean by "library"? 15:44:20 the code we include in the SDK to get people going. The library/binding 15:44:49 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 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 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 and enables them to be successful 15:46:33 rather than having different libraries for different communities 15:46:39 how does using protected visibility make developers more successful? 15:46:49 like one that feels right for drupalers, one that feels right for symfony folks, etc 15:46:57 so here's the thing 15:47:06 today I went into #symfony on irc and asked about this 15:47:16 that's not the protected part. it's the private/final part that changes development habits 15:47:20 I asked people they're opinion on using private visibility and encourage alternative ways of extension 15:47:34 nearly everyone I spoke to had very strong ideas that private visibility was right, and the way to go 15:47:45 I also did this on Stack Overflow 15:48:07 and I looked at some of the most popular libraries for PHP - all advocate private visibility because it enforces encapsulation 15:48:09 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 and I went to developers of some other libraries who said the same thing 15:48:32 could you share those conversations on the mailing list? I'd like to see the feedback 15:48:41 I'll post my R&D too 15:48:46 asking a community (sub-culture) of the whole PHP their opinion isn't going to represent PHP devs... jsut that subculture 15:48:53 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 I'm surprised that a public site would heavily lean towards one side exclusively 15:50:01 samchoi did you see responses from php people? what do other OO languages feel about this? 15:50:10 I know you have experience with them 15:50:21 Yea, it was pretty interesting to see the variety of responses :) 15:50:40 One question, the votes would lean towards protected/public, the next question would lean towards private... 15:51:00 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 symfony, composer, guzzle, phpspec, behat 15:51:33 millions of downloads, thousands of stars - I'd say that's a fair representation, no? 15:52:20 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 hmm, I have no C++ experience, zilch :) 15:53:09 community involvement is great, but inevitably we should decide based on what *we* believe in 15:53:17 I believe that an interface is the most important thing 15:53:22 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 state should be modified through an interface 15:53:44 Wordpress has millions of downloads and is stylistically entirely different 15:53:57 going by github numbers only holds to projects on github 15:53:59 are you advocating we use a procedural style like WP? 15:54:18 haha, no. just making it in a way accessible to those developers to integrate in 15:54:41 my point was more to look at community opinions. symfony with millions of downloads is still a subset of PHP developers 15:54:49 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 that's what i don't understand 15:55:04 lets go to my two use cases 15:55:32 samchoi what do you think about the importance of an interface? 15:55:32 "1. Someone needs to add functionality to a class but can't add it back 15:55:32 upstream. That could be because they are in a hurry to get their app 15:55:32 out and aren't concerned with contributing it or because the 15:55:32 organization they work for won't let them release it in a timely 15:55:32 manner or ever." 15:55:54 this could be added functionality or a bug 15:56:06 can you elaborate jamiehannaford ? Since I could misinterpret what you mean 15:56:24 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 what alternative method should be used? 15:56:36 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 I heavily prefer the second 15:57:05 no, i mean the internals of what's happening (not what's passed in or returned) needs to be changed 15:58:32 mfer could you elaborate on what type of functionality we expect users to be adding to the SDK? 16:00:39 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 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 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 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 mfer you'd use DI for that 16:04:40 that satisfies the PSR interface or something 16:05:02 I can't really respond with specifics unless there's a specific scenario you're worried about 16:05:12 that's the idea. we don't knwo the specifics 16:06:13 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 all I'm saying is that there are better ways to extend behaviour 16:06:56 ways that are well known to LOTS of PHP devs 16:07:03 the promise is defined in the interface. we supply one implementation of that against vanilla openstack. 16:07:18 and if we think inheritance is the ONLY thing they know, we're selling them massively short 16:07:23 how people alter openstack (which is built in) or need to extend our SDK is up to them 16:07:36 sure, and inheritance is not the only way to do that 16:07:43 it's actually an anti-pattern that causes a lot of harm 16:07:58 this is not a debate about extension. I support extension massively 16:08:16 this is about whether inheritance should be actively promoted with open visibility 16:09:32 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 there's a difference between a promise (though an interface) and enabling devs of different styles to extend things 16:10:08 protected visibility is as dangerous as public visibility 16:10:35 to whom? the person who needs to make a fast alteration to deliver on time 16:10:45 mfer I disagree. you're unnecessarily promoting bad practice when there better and more effective ways to extend/modify/access behaviour 16:10:54 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 there will be people who do that 16:11:09 yes, and to us who can't refactor something in 6 months because we've opened up the entire class 16:11:23 they will just stay with their legacy code which they've altered 16:11:43 if we refactor we increment the semver accordingly 16:11:57 right, but you can't introduce a non-BC change 16:12:09 making things protected obliges us to support multiple APIs 16:12:14 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 which restricts us down the line 16:12:57 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 any change they make to our stuff is on them not us 16:13:21 we can't make API changes without incrementing the first number of the semver 16:13:57 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 we need to be careful to not try to control people but instead enable 16:14:17 if they alter the codebase they altered it 16:14:17 we support them with well-defined APIs and solidify those expectations 16:14:22 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 however, I do support final classes in the right circumstances 16:15:11 although, imo, it'd be rare for an API like ours 16:15:43 and sorry getting distracted by a 2nd meeting 16:16:10 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 there are patterns where we don't need private/final and are fairly simple for this stuff 16:16:14 they were introduced for a reason 16:16:24 when to use them is debated 16:16:31 mfer which patterns? 16:17:12 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 yeah, sure 16:17:36 sorry for overrunning :) 16:17:45 good discussion topic 16:19:37 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 I know we didn't get to all the topics... is it ok to end now? 16:20:07 yep, fine with me 16:20:13 alright 16:20:59 jamiehannaford thanks! 16:21:03 #endmeeting