Private variables are not eco-friendly

[Dmitriy Ryaboy <dv...@gmail.com>]

Hi all,
I keep running into problems trying to extend Pig due to variables
being declared private. The latest time around it was in PigSlice --
one can't inherit it and do much meaningful overriding of methods
because the input streams are private rather than protected, so I
can't change how it gets created. I wound up having to copy+paste the
class wholesale, which is unfortunate. I know the Slice/Slicer
interfaces are going away, but as a general rule -- can we be mindful
of folks trying to extend classes, and make inner members protected,
rather than private or package?

Thanks
-Dmitriy

Re: Private variables are not eco-friendly

[Arun C Murthy <ac...@yahoo-inc.com>]

The current model forces people to 'convince' others to open up  
classes for inheritance at the precise point it is necessary. This is  
a model which has served, at least, Hadoop very well.

So, I think we should not go make every member protected - rather we  
should open them up one at a time, as and when necessary.

Arun

On Feb 2, 2010, at 7:34 PM, Dmitriy Ryaboy wrote:

> Hi all,
> I keep running into problems trying to extend Pig due to variables
> being declared private. The latest time around it was in PigSlice --
> one can't inherit it and do much meaningful overriding of methods
> because the input streams are private rather than protected, so I
> can't change how it gets created. I wound up having to copy+paste the
> class wholesale, which is unfortunate. I know the Slice/Slicer
> interfaces are going away, but as a general rule -- can we be mindful
> of folks trying to extend classes, and make inner members protected,
> rather than private or package?
>
> Thanks
> -Dmitriy

Re: Private variables are not eco-friendly

[Dmitriy Ryaboy <dv...@gmail.com>]

Making things protected breaks encapsulation, while keeping them
private hampers extensibility. Ideally, we would go through careful
design phases and consider all such issues, coming up with clean
interfaces that allow just enough visibility into reference
implementations of public-facing interfaces and abstract classes to do
what a user might need, while keeping the internal workings of Pig
isolated. So, yes.  But that involves either foreseeing all possible
use cases, or forcing a user to choose between waiting on a 3+ month
release cycle and maintaining their own patched version of Pig,
instead of an official release. With that in mind, I would favor
usability and extensibility over implicitly encouraging programming by
cut-n-paste.

Naturally, I am talking about implementations of user-facing
abstractions here -- UDFs, Load/Store funcs, Input formats, etc. Since
anyone trying to do things like create new physical operators would be
working inside the Pig guts anyway, they can turn things protected if
they want to, so that's fine.


On Tue, Feb 2, 2010 at 10:28 PM, Pradeep Kamath <pr...@yahoo-inc.com> wrote:
> Would it be better to make them protected when a use case for
> inheritance arises rather than begin as protected?
>
> -----Original Message-----
> From: Dmitriy Ryaboy [mailto:dvryaboy@gmail.com]
> Sent: Tuesday, February 02, 2010 7:35 PM
> To: pig-dev@hadoop.apache.org
> Subject: Private variables are not eco-friendly
>
> Hi all,
> I keep running into problems trying to extend Pig due to variables
> being declared private. The latest time around it was in PigSlice --
> one can't inherit it and do much meaningful overriding of methods
> because the input streams are private rather than protected, so I
> can't change how it gets created. I wound up having to copy+paste the
> class wholesale, which is unfortunate. I know the Slice/Slicer
> interfaces are going away, but as a general rule -- can we be mindful
> of folks trying to extend classes, and make inner members protected,
> rather than private or package?
>
> Thanks
> -Dmitriy
>

RE: Private variables are not eco-friendly

[Pradeep Kamath <pr...@yahoo-inc.com>]

Would it be better to make them protected when a use case for
inheritance arises rather than begin as protected? 

-----Original Message-----
From: Dmitriy Ryaboy [mailto:dvryaboy@gmail.com] 
Sent: Tuesday, February 02, 2010 7:35 PM
To: pig-dev@hadoop.apache.org
Subject: Private variables are not eco-friendly

Hi all,
I keep running into problems trying to extend Pig due to variables
being declared private. The latest time around it was in PigSlice --
one can't inherit it and do much meaningful overriding of methods
because the input streams are private rather than protected, so I
can't change how it gets created. I wound up having to copy+paste the
class wholesale, which is unfortunate. I know the Slice/Slicer
interfaces are going away, but as a general rule -- can we be mindful
of folks trying to extend classes, and make inner members protected,
rather than private or package?

Thanks
-Dmitriy