Regarding use of the final keyword and limiting extending in general, a few
thoughts below:
- While I found the blog post about final classes to be informative, I'd take
it with a grain of salt. The author bills himself as a consultant who works
with enterprise web applications. Briefly looking at his background,
practically all his gigs were short consulting jobs. I don't see a track record
for open source projects so it would appear that his views are likely more
applicable for enterprise developers working within closed systems.
- The Java community has already beaten this subject to death over the past
decade. During recent years, it seems that the debate has waned. I occasionally
see enterprise Java devs use final to communicate their intent so that their
system isn't butchered many years down the road when it becomes poorly
understood legacy code.
- On the other hand, I hardly ever see final classes in open source code/APIs.
- Regarding future-proofing, I agree that it's easier to switch from final to
not using final than the other way around. However, I've actually had cases
where I needed to extend a final class in an API and was simply annoyed by the
author's desire to control how I use the API. I also understood that if the
author were to change certain things, my extension may have to be refactored.
That's a risk I'm certainly willing to take to get the job done.
Thanks,
--
Sam Choi
Hewlett-Packard Co.
HP Cloud Services
+1 650 316 1652 / Office
-Original Message-
From: Matthew Farina [mailto:m...@mattfarina.com]
Sent: Monday, June 09, 2014 7:09 AM
To: Jamie Hannaford
Cc: Shaunak Kashyap; Glen Campbell; OpenStack Development Mailing List (not for
usage questions); Choi, Sam; Farina, Matt
Subject: Re: [openstack-sdk-php] Use of final and private keywords to limit
extending
If you don't mind I'd like to step back for a moment and talk about the end
users of this codebase and the types code it will be used in.
We're looking to make application developers successful in PHP. The top 10% of
PHP application developers aren't an issue. If they have an SDK or not they
will build amazing things. It's the long tail of app devs. Many of these
developers don't know things we might take for granted, like dependency
injection. A lot of them may writing spaghetti procedural code. I use these
examples because I've run into them in the past couple months. We need to make
these folks successful in a cost effective and low barrier to entry manner.
When I've gotten into the world of closed source PHP (or any other language for
that matter) and work that's not in the popular space I've seen many things
that aren't clean or pretty. But, they work.
That means this SDK needs to be useful in the modern frameworks (which vary
widely on opinions) and in environments we may not like.
The other thing I'd like to talk about is the protected keyword. I use this a
lot. Using protected means an outside caller can't access the method. Only
other methods on the class or classes that extend it.
This is an easy way to have an API and internals.
Private is different. Private means it's part of the class but not there for
extended classes. It's not just about controlling the public API for callers
but not letting classes that extend this one have access to the functionality.
Given the scope of who our users are...
- Any place we use the `final` scoping we need to explain how to extend it
properly. It's a teaching moment for someone who might not come to a direction
on what to do very quickly. Think about the long tail of developers and
projects, most of which are not open source.
Note, I said I'm not opposed to using final. It's an intentional decision. For
the kinds of things we're doing I can't see all to many use cases for using
final. We need to enable users to be successful without controlling how they
write applications because this is an add-on to help them not a driver for
their architecture.
- For scoping private and public APIs, `protected` is a better keyword unless
we are intending on blocking extension. If we block extension we should explain
how to handled overriding things that are likely to happen in real world
applications that are not ideally written or architected.
At the end of the day, applications that successfully do what they need to do
while using OpenStack on the backend is what will make OpenStack more
successful. We need to help make it easy for the developers, no matter how they
choose to code, to be successful. I find it useful to focus on end users and
their practical cases over the theory of how to design something.
Thoughts,
Matt
On Fri, Jun 6, 2014 at 10:01 AM, Jamie Hannaford
wrote:
> So this is an issue that’s been heavily discussed recently in the PHP
> community.
>
> Bas
