[izpack-devel] private to protected -> Objection

[Ryan Shillington]

Hello team,

I've been mulling this over for a while now too.

As I'm sure many of you know, whenever you're considering delegation
over polymorphism, the question always comes down to whether you would
put the words "is a" or "uses" in between the class names.

Hence, which one is more correct?
    a) ExtendedUserInputPanel is a UserInputPanel
 or b) ExtendedUserInputPanel uses UserInputPanel

I think the answer is a), and if so then it'll be very hard to write a
new ExtendedUserInputPanel without being closely coupled with
UserInputPanel.  Even if we provide getters and setters instead of
protected member variables, the implementation in ExtendedUserInputPanel
is still going to greatly depend on the implementation of UserInputPanel
because ExtendedUserInputPanel will expect UserInputPanel to be using
them internally.

One of IzPack's great strengths is that it is open source, meaning that
you can find a panel that does 80% of what you want it to do, and
override it to remove/add what you need.   Hence, especially because
we're in the installer business here, I'm leaning towards making our
variables protected.  Unfortunately your point is very, very valid - we
will be making it easier for people to write installers at the cost of
making it difficult for them to upgrade to the next great version of
IzPack.

But I digress... :-)

Ryan
</soapbox>
-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de] On Behalf Of Elmar Grom
Sent: Friday, September 01, 2006 2:54 PM
To: izpack-devel at lists.berlios.de
Subject: Re: [izpack-devel] private to protected -> Objection

Hi Marc,

I do object. This is against the very important principles of
information
hiding.

I am not sure which fields you want to access from your subclass. I
would
strongly advise to find other approaches to solve your problem. Writing
subclasses with detailed knowledge of the inside workings of the super
class, such as data fields, is never a good idea. This is particularly
true
in such a disconnected case as you present. If we ever make changes to
those
data fields or how we use them, anyone who wrote a subclass will see
their
code break. In many cases there will be no obvious indication of that
fact.

Instead we should strive to have a clean and dependable interface that
subclasses can really depend on.

	Elmar

-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Marc
Eppelmann
Sent: Friday, September 01, 2006 11:57 AM
To: izpack-devel at lists.berlios.de
Subject: [izpack-devel] private to protected


Hi all,

I want to change the fields and methods of the UserInputPanel from
private
to
protected, to make it possible to derive an userdefined UserInputPanel
from
it. If there is nobody which has an objection about it, I will commit
this
next week at Tuesday. Then I will describe and document the features(**
of
my
derived ExtendedUserInputPanel and if there is anybody that interests
on, I
will commit this.

**) such as userdefined Title Layouts.

Cheers
Marc
_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel

_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel

IMPORTANT NOTICE:
This message may contain confidential information. If you have received this e-mail in error, do not use, copy or distribute it. Do not open any attachments. Delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.