<html>
<head>
<!-- Template generated by Exclaimer Mail Disclaimers on 09:06:36 Tuesday, 10 June 2014 -->
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">P.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
LI.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
DIV.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
TABLE.ae431132-9d17-4a38-b6b5-634369783623Table {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</style>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<p class="ae431132-9d17-4a38-b6b5-634369783623"></p>
<div id="bloop_customfont">I completely agree that our priorities are to lower barriers to entry. This involves making it as easy as possible to use and contribute back to our SDK. But we also have a commitment to the quality of the codebase. This is not closed-source,
this is open-source - and people care about quality. There’s no way to make “application developers successful in PHP” if we don’t take the lead and encourage good design. </div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">Now, to reiterate: I’m not against extension - I’m against needless inheritance. You can
<i>extend</i> the functionality of our SDK in lots of different ways - many of which are vastly more advantageous than inheritance because they avoid our API being changed. Events, for example, allow end-users to plug in functionality without overriding our
base classes. Using events and the observer pattern is a simple way users can easily engage with, and extend, our SDK. Symfony, ZF2, Guzzle developers all use it without a problem. But saying that, I agree that documentation is extremely important: we need
to understand how and why users want to interact with, or augment, the functionality of our SDK - and document how to do it in a clear way. Having targeted and focused documentation like this is way better than letting people inherit classes and override our
API.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">In terms of keywords, you should only ever use the `protected` keyword if you’re absolutely certain (1) your class will be extended and (2) that property will need to be accessed by sub-classes. When we’re writing code, that’s almost
never the case. We want state to be preserved internally, to maintain encapsulation, not leak it out to external classes. If the situation arises where we actually need inheritance and shared state, we can change `private` to `protected` very easily. By being
initially defensive with visibility, we’ve not lost anything.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">Using `final` does not restrict our users from being “successful” whatsoever. It’s to do with us and our users having confidence in what our API does, both now and in the future. We’re not stopping extension, we’re just being defensive
with how our classes are overridden. Using event subscribers is not difficult, and people who use alternative means of extension are probably more successful in what they want to do than those who constantly override for no good reason.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_sign_1402386442637836032" class="bloop_sign">Jamie</div>
<br>
<p style="color:#000;">On June 9, 2014 at 4:09:26 PM, Matthew Farina (<a href="mailto:matt@mattfarina.com">matt@mattfarina.com</a>) wrote:</p>
<blockquote type="cite" class="clean_bq"><span>
<div>
<div></div>
<div>If you don't mind I'd like to step back for a moment and talk about <br>
the end users of this codebase and the types code it will be used in. <br>
<br>
We're looking to make application developers successful in PHP. The <br>
top 10% of PHP application developers aren't an issue. If they have an <br>
SDK or not they will build amazing things. It's the long tail of app <br>
devs. Many of these developers don't know things we might take for <br>
granted, like dependency injection. A lot of them may writing <br>
spaghetti procedural code. I use these examples because I've run into <br>
them in the past couple months. We need to make these folks successful <br>
in a cost effective and low barrier to entry manner. <br>
<br>
When I've gotten into the world of closed source PHP (or any other <br>
language for that matter) and work that's not in the popular space <br>
I've seen many things that aren't clean or pretty. But, they work. <br>
<br>
That means this SDK needs to be useful in the modern frameworks (which <br>
vary widely on opinions) and in environments we may not like. <br>
<br>
The other thing I'd like to talk about is the protected keyword. I use <br>
this a lot. Using protected means an outside caller can't access the <br>
method. Only other methods on the class or classes that extend it. <br>
This is an easy way to have an API and internals. <br>
<br>
Private is different. Private means it's part of the class but not <br>
there for extended classes. It's not just about controlling the public <br>
API for callers but not letting classes that extend this one have <br>
access to the functionality. <br>
<br>
Given the scope of who our users are... <br>
<br>
- Any place we use the `final` scoping we need to explain how to <br>
extend it properly. It's a teaching moment for someone who might not <br>
come to a direction on what to do very quickly. Think about the long <br>
tail of developers and projects, most of which are not open source. <br>
<br>
Note, I said I'm not opposed to using final. It's an intentional <br>
decision. For the kinds of things we're doing I can't see all to many <br>
use cases for using final. We need to enable users to be successful <br>
without controlling how they write applications because this is an <br>
add-on to help them not a driver for their architecture. <br>
<br>
- For scoping private and public APIs, `protected` is a better keyword <br>
unless we are intending on blocking extension. If we block extension <br>
we should explain how to handled overriding things that are likely to <br>
happen in real world applications that are not ideally written or <br>
architected. <br>
<br>
At the end of the day, applications that successfully do what they <br>
need to do while using OpenStack on the backend is what will make <br>
OpenStack more successful. We need to help make it easy for the <br>
developers, no matter how they choose to code, to be successful. I <br>
find it useful to focus on end users and their practical cases over <br>
the theory of how to design something. <br>
<br>
Thoughts, <br>
Matt <br>
<br>
<br>
On Fri, Jun 6, 2014 at 10:01 AM, Jamie Hannaford <br>
<jamie.hannaford@rackspace.com> wrote: <br>
> So this is an issue that’s been heavily discussed recently in the PHP <br>
> community. <br>
> <br>
> Based on personal opinion, I heavily favor and use private properties in <br>
> software I write. I haven’t, however, used the “final” keyword that much. <br>
> But the more I read about and see it being used, the more inclined I am to <br>
> use it in projects. Here’s a great overview of why it’s useful for public <br>
> APIs: http://verraes.net/2014/05/final-classes-in-php/ <br>
> <br>
> Here’s a tl;dr executive summary: <br>
> <br>
> - Open/Closed principle. It’s important to understand that “Open for <br>
> extension”, does not mean “Open for inheritance”. Composition, strategies, <br>
> callbacks, plugins, event listeners, … are all valid ways to extend without <br>
> inheritance. And usually, they are much preferred to inheritance – hence the <br>
> conventional recommendation in OOP to “favour composition over inheritance”. <br>
> Inheritance creates more coupling, that can be hard to get rid of, and that <br>
> can make understanding the code quite tough. <br>
> <br>
> - Providing an API is a responsibility: by allowing end-users to access <br>
> features of our SDK, we need to give certain guarantees of stability or low <br>
> change frequency. The behavior of classes should be deterministic - i.e. we <br>
> should be able to trust that a class does a certain thing. There’s no trust <br>
> whatsoever if that behavior can be edited and overridden from external code. <br>
> <br>
> - Future-proofing: the fewer behaviours and extension points we expose, the <br>
> more freedom we have to change system internals. This is the idea behind <br>
> encapsulation. <br>
> <br>
> You said that we should only use private and final keywords if there’s an <br>
> overwhelming reason to do so. I completely disagree. I actually want to flip <br>
> the proposition here: I think we should only use public keywords if we’re <br>
> CERTAIN we want to encourage and allow the inheritance of that class. By <br>
> making a class inheritable, you are saying to the outside world: this class <br>
> is meant to be extended. And the majority of times this is not what we want. <br>
> Sure there are times when inheritance may well be the best option - but you <br>
> can support extension points in different, often better, ways. Declaring <br>
> explicitly what the extension points are is part of the contract your code <br>
> has with the rest of the system. Final classes help to enforce this <br>
> contract. <br>
> <br>
> To summarize, we have nothing to lose by favoring private and final <br>
> keywords. We gain the above advantages, and if we later decide to open up <br>
> that class as an extension point we can remove the keywords without any <br>
> issues. Should a valid reason come up to open it up, it will be easy to do <br>
> so, because nothing depends on it being closed. On the other hand, if you <br>
> start by making everything open or inheritable, it will be very hard to <br>
> close it later. <br>
> <br>
> Jamie <br>
> <br>
> On June 5, 2014 at 6:24:52 PM, Matthew Farina (matt@mattfarina.com) wrote: <br>
> <br>
> Some recent reviews have started to include the use of the private <br>
> keyword for methods and talk of using final on classes. I don't think <br>
> we have consistent agreement on how we should do this. <br>
> <br>
> My take is that we should not use private or final unless we can <br>
> articulate the design decision to intentionally do so. <br>
> <br>
> To limit public the public API for a class we can use protected. <br>
> Moving from protected to private or the use of final should have a <br>
> good reason. <br>
> <br>
> In open source software code is extended in ways we often don't think <br>
> of up front. Using private and final limits how those things can <br>
> happen. When we use them we are intentionally limiting extending so we <br>
> should be able to articulate why we want to put that limitation in <br>
> place. <br>
> <br>
> Given the reviews that have been put forth I think there is a <br>
> different stance. If there is one please share it. <br>
> <br>
> - Matt <br>
> <br>
> <br>
> <br>
> Jamie Hannaford <br>
> Software Developer III - CH <br>
> Tel: +41434303908 <br>
> Mob: +41791009767 <br>
> <br>
> <br>
> <br>
> Rackspace International GmbH a company registered in the Canton of Zurich, <br>
> Switzerland (company identification number CH-020.4.047.077-1) whose <br>
> registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. <br>
> Rackspace International GmbH privacy policy can be viewed at <br>
> www.rackspace.co.uk/legal/swiss-privacy-policy <br>
> - <br>
> Rackspace Hosting Australia PTY LTD a company registered in the state of <br>
> Victoria, Australia (company registered number ACN 153 275 524) whose <br>
> registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW <br>
> 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be <br>
> viewed at www.rackspace.com.au/company/legal-privacy-statement.php <br>
> - <br>
> Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States <br>
> of America <br>
> Rackspace US, Inc privacy policy can be viewed at <br>
> www.rackspace.com/information/legal/privacystatement <br>
> - <br>
> Rackspace Limited is a company registered in England & Wales (company <br>
> registered number 03897010) whose registered office is at 5 Millington Road, <br>
> Hyde Park Hayes, Middlesex UB3 4AZ. <br>
> Rackspace Limited privacy policy can be viewed at <br>
> www.rackspace.co.uk/legal/privacy-policy <br>
> - <br>
> Rackspace Benelux B.V. is a company registered in the Netherlands (company <br>
> KvK nummer 34276327) whose registered office is at Teleportboulevard 110, <br>
> 1043 EJ Amsterdam. <br>
> Rackspace Benelux B.V privacy policy can be viewed at <br>
> www.rackspace.nl/juridisch/privacy-policy <br>
> - <br>
> Rackspace Asia Limited is a company registered in Hong Kong (Company no: <br>
> 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place, <br>
> 979 King's Road, Quarry Bay, Hong Kong. <br>
> Rackspace Asia Limited privacy policy can be viewed at <br>
> www.rackspace.com.hk/company/legal-privacy-statement.php <br>
> - <br>
> This e-mail message (including any attachments or embedded documents) is <br>
> intended for the exclusive and confidential use of the individual or entity <br>
> to which this message is addressed, and unless otherwise expressly <br>
> indicated, is confidential and privileged information of Rackspace. Any <br>
> dissemination, distribution or copying of the enclosed material is <br>
> prohibited. If you receive this transmission in error, please notify us <br>
> immediately by e-mail at abuse@rackspace.com and delete the original <br>
> message. Your cooperation is appreciated. <br>
</div>
</div>
</span></blockquote>
<p></p>
<p class="ae431132-9d17-4a38-b6b5-634369783623"> </p>
<p class="ae431132-9d17-4a38-b6b5-634369783623">
<table border="0" cellpadding="0" width="504">
<tbody>
<tr>
<td style="WIDTH: 270px" class="LEFT_ALIGNED"><span style="font-family:Verdana; font-size:small; ">Jamie Hannaford</span><br>
<span style="font-family:Verdana; font-size:x-small; ">Software Developer III - CH</span></td>
<td style="WIDTH: 281px"><img alt="experience Fanatical Support" align="right" src="cid:image2b478f.JPG@33652212.48aca1ae" width="159" height="17"></td>
</tr>
<tr class="LEFT_ALIGNED">
<td colspan="2"><img alt="LINE" src="cid:imaged51cb8.JPG@36b95576.4b833bd2" width="504" height="4"></td>
</tr>
<tr>
<td class="CONTACTINFO"><span style="font-family:Calibri; ">
<table class="ae431132-9d17-4a38-b6b5-634369783623Table">
<tbody>
<tr>
<td><span style="font-family:Verdana; font-size:x-small; ">Tel: </span></td>
<td><span style="font-family:Verdana; font-size:x-small; ">+41434303908</span></td>
</tr>
<tr>
<td><span style="font-family:Verdana; font-size:x-small; ">Mob: </span></td>
<td><span style="font-family:Verdana; font-size:x-small; ">+41791009767</span></td>
</tr>
</tbody>
</table>
</span></td>
<td class="RIGHT_ALIGNED"><img alt="Rackspace" src="cid:image6163f6.JPG@c8f48f1f.40990635" width="280" height="60"></td>
</tr>
<tr class="LEFT_ALIGNED">
<td class="CONTACTINFO" colspan="2"><img src="cid:imageaa33d6.JPG@365afffb.48884814" width="504" height="3"></td>
</tr>
</tbody>
</table>
</p>
<p class="ae431132-9d17-4a38-b6b5-634369783623"> </p>
<p class="ae431132-9d17-4a38-b6b5-634369783623"></p>
<span style="font-size: 11px;">Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy<br>-<br>Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php<br>-<span style="font-size: 11px;"></span><br>Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America</span><br><span style="font-size: 11px;">Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ.</span><br><span style="font-size: 11px;">Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Benelux B.V. is a company registered in the Netherlands (company KvK nummer 34276327) whose registered office is at Teleportboulevard 110, 1043 EJ Amsterdam.</span><br><span style="font-size: 11px;">Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">Rackspace Asia Limited is a company registered in Hong Kong (Company no: 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place, 979 King's Road, Quarry Bay, Hong Kong.</span><br><span style="font-size: 11px;">Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">This e-mail message (including any attachments or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com and delete the original message. Your cooperation is appreciated.</span></body>
</html>