| VE and private members [message #93203] |
Thu, 09 June 2005 16:34  |
Eclipse User |
|
|
|
Originally posted by: raysnews.web.de
Hello,
why does VE generate private members only ? I would like to touch the
generated visual class as little as possible (mainly because VE gets
very slow on big classes), but how could I access the components (for
registering listeners for example) inside that class without adding some
public methods to it ?
|
|
|
|
|
|
|
| Re: VE and private members [message #93761 is a reply to message #93717] |
Mon, 13 June 2005 14:43  |
| Eclipse User |
|
|
|
Originally posted by: raysnews.web.de
Steven Buroff wrote:
> "Noam Tamim" <noamtm@gmail.com> wrote in message
> news:d8i6k2$na4$1@news.eclipse.org...
>
>>As an OOP developer, I think the "default" visibility should always be
>>private (C++ does that). Unfortunately, in Java the default is
>>"package-private".
>>
>>Anyway, my point: as a user of VE, I'd be really unhappy with non-private
>>fields.
>
>
> Absolutely right. Private is the correct default.
>
> Steve Buroff
>
So then please tell me: Do you create access methods by hand for all
controls in your applications and maintain them as you modify your
layout and design ?
I have in my application about 85 controls distributed among 43 classes
(arranged in a tree hierarchy), which needs to get listeners registered,
text set, etc. It would be a horrible work to create access methods by
hand for every class! Maybe I'm missing something and there is a simple
solution for this. Any hints would be helpful.
>
>>Ray Kane wrote:
>>
>>>>They are private because by default components should not be visible
>>>>outside of the class itself. It's called information hiding, and is a
>>>>general concept of Object Oriented programming. If you want a component
>>>>to be visible outside of the class you need to create a accessor (get
>>>>method) that returns the component.
>>>
>>>But to create accessor methods would means to modify that visual class
>>>considerably. So I think there could arise two problem:
>>>First, the VE could may be disturbed by this not generated methods and
>>>second when the class grows the VE will become very slow in parsing that
>>>class. In addition I also have to do it (creating that accessor methods)
>>>which makes more work to to.
>>>So I would suggest to make these members package local, so that there is
>>>at least a limited access for classes that need it (i.e. event listener).
>>>What do you think ?
>
>
>
|
|
|
|
|
|
|
| Re: VE and private members [message #95445 is a reply to message #93983] |
Thu, 30 June 2005 15:04 |
| Eclipse User |
|
|
|
Ray Kane wrote:
> Rich Kulp wrote:
>
>> You are the developer of the class. It is your job to decide what is
>> exposed and what isn't. Typically you should not expose everything,
>> only the things that make sense. So you should not create an accessor
>> for every control, just the ones that you feel a user of your class
>> should have access to. If you expose everything you have now created a
>> contract that becomes very difficult to maintain. You will not be
>> allowed to remove anything in the future.
>>
> I understand want you want to tell me and I agree to you fully. The
> access to a class should be as little as possible. But how can I solve
> this concrete problem ? Ok, I could use the VE to create my listeners
> inside the classes but that also would make them bigger and bigger and
> fill them with code (inside the listeners) that doesn't really belong to
> them.
> By the way, the attribute don't have to be non-private. But VE already
> generates "access methods" anyway (if they wouldn't be private). Maybe
> there could be an option for a visual bean in the "Java Beans"-View to
> let me choose the visibility outside the class ?
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=102263, this may be of help for you
|
|
|
| Re: VE and private members [message #607903 is a reply to message #93203] |
Thu, 09 June 2005 17:21 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
They are private because by default components should not be visible
outside of the class itself. It's called information hiding, and is a
general concept of Object Oriented programming. If you want a component
to be visible outside of the class you need to create a accessor (get
method) that returns the component.
Ray Kane wrote:
> Hello,
>
> why does VE generate private members only ? I would like to touch the
> generated visual class as little as possible (mainly because VE gets
> very slow on big classes), but how could I access the components (for
> registering listeners for example) inside that class without adding some
> public methods to it ?
--
Thanks,
Rich Kulp
|
|
|
| Re: VE and private members [message #607932 is a reply to message #93221] |
Sun, 12 June 2005 07:28 |
| Eclipse User |
|
|
|
Originally posted by: raysnews.web.de
Rich Kulp wrote:
> They are private because by default components should not be visible
> outside of the class itself. It's called information hiding, and is a
> general concept of Object Oriented programming. If you want a component
> to be visible outside of the class you need to create a accessor (get
> method) that returns the component.
>
> Ray Kane wrote:
>
>> Hello,
>>
>> why does VE generate private members only ? I would like to touch the
>> generated visual class as little as possible (mainly because VE gets
>> very slow on big classes), but how could I access the components (for
>> registering listeners for example) inside that class without adding
>> some public methods to it ?
>
>
Thank you for your answer, Rich.
But to create accessor methods would means to modify that visual class
considerably. So I think there could arise two problem:
First, the VE could may be disturbed by this not generated methods and
second when the class grows the VE will become very slow in parsing that
class. In addition I also have to do it (creating that accessor methods)
which makes more work to to.
So I would suggest to make these members package local, so that there is
at least a limited access for classes that need it (i.e. event
listener). What do you think ?
Ray
|
|
|
| Re: VE and private members [message #607936 is a reply to message #93644] |
Sun, 12 June 2005 16:40 |
| Eclipse User |
|
|
|
As an OOP developer, I think the "default" visibility should always be
private (C++ does that). Unfortunately, in Java the default is
"package-private".
Anyway, my point: as a user of VE, I'd be really unhappy with
non-private fields.
Ray Kane wrote:
>> They are private because by default components should not be visible
>> outside of the class itself. It's called information hiding, and is a
>> general concept of Object Oriented programming. If you want a
>> component to be visible outside of the class you need to create a
>> accessor (get method) that returns the component.
> But to create accessor methods would means to modify that visual class
> considerably. So I think there could arise two problem:
> First, the VE could may be disturbed by this not generated methods and
> second when the class grows the VE will become very slow in parsing that
> class. In addition I also have to do it (creating that accessor methods)
> which makes more work to to.
> So I would suggest to make these members package local, so that there is
> at least a limited access for classes that need it (i.e. event
> listener). What do you think ?
|
|
|
| Re: VE and private members [message #607937 is a reply to message #93702] |
Mon, 13 June 2005 08:32 |
| Eclipse User |
|
|
|
"Noam Tamim" <noamtm@gmail.com> wrote in message
news:d8i6k2$na4$1@news.eclipse.org...
> As an OOP developer, I think the "default" visibility should always be
> private (C++ does that). Unfortunately, in Java the default is
> "package-private".
>
> Anyway, my point: as a user of VE, I'd be really unhappy with non-private
> fields.
Absolutely right. Private is the correct default.
Steve Buroff
>
> Ray Kane wrote:
>>> They are private because by default components should not be visible
>>> outside of the class itself. It's called information hiding, and is a
>>> general concept of Object Oriented programming. If you want a component
>>> to be visible outside of the class you need to create a accessor (get
>>> method) that returns the component.
>> But to create accessor methods would means to modify that visual class
>> considerably. So I think there could arise two problem:
>> First, the VE could may be disturbed by this not generated methods and
>> second when the class grows the VE will become very slow in parsing that
>> class. In addition I also have to do it (creating that accessor methods)
>> which makes more work to to.
>> So I would suggest to make these members package local, so that there is
>> at least a limited access for classes that need it (i.e. event listener).
>> What do you think ?
|
|
|
| Re: VE and private members [message #607940 is a reply to message #93717] |
Mon, 13 June 2005 14:43 |
| Eclipse User |
|
|
|
Originally posted by: raysnews.web.de
Steven Buroff wrote:
> "Noam Tamim" <noamtm@gmail.com> wrote in message
> news:d8i6k2$na4$1@news.eclipse.org...
>
>>As an OOP developer, I think the "default" visibility should always be
>>private (C++ does that). Unfortunately, in Java the default is
>>"package-private".
>>
>>Anyway, my point: as a user of VE, I'd be really unhappy with non-private
>>fields.
>
>
> Absolutely right. Private is the correct default.
>
> Steve Buroff
>
So then please tell me: Do you create access methods by hand for all
controls in your applications and maintain them as you modify your
layout and design ?
I have in my application about 85 controls distributed among 43 classes
(arranged in a tree hierarchy), which needs to get listeners registered,
text set, etc. It would be a horrible work to create access methods by
hand for every class! Maybe I'm missing something and there is a simple
solution for this. Any hints would be helpful.
>
>>Ray Kane wrote:
>>
>>>>They are private because by default components should not be visible
>>>>outside of the class itself. It's called information hiding, and is a
>>>>general concept of Object Oriented programming. If you want a component
>>>>to be visible outside of the class you need to create a accessor (get
>>>>method) that returns the component.
>>>
>>>But to create accessor methods would means to modify that visual class
>>>considerably. So I think there could arise two problem:
>>>First, the VE could may be disturbed by this not generated methods and
>>>second when the class grows the VE will become very slow in parsing that
>>>class. In addition I also have to do it (creating that accessor methods)
>>>which makes more work to to.
>>>So I would suggest to make these members package local, so that there is
>>>at least a limited access for classes that need it (i.e. event listener).
>>>What do you think ?
>
>
>
|
|
|
| Re: VE and private members [message #607944 is a reply to message #93761] |
Mon, 13 June 2005 16:30 |
| Eclipse User |
|
|
|
I'd suggest a preference in the VE's code generation section allowing
you to specify the access modifier for generated methods. Enhancement
request anyone?
Just my $0.02.
- Jeff
|
|
|
| Re: VE and private members [message #607946 is a reply to message #93761] |
Mon, 13 June 2005 16:37 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
You are the developer of the class. It is your job to decide what is
exposed and what isn't. Typically you should not expose everything, only
the things that make sense. So you should not create an accessor for
every control, just the ones that you feel a user of your class should
have access to. If you expose everything you have now created a contract
that becomes very difficult to maintain. You will not be allowed to
remove anything in the future.
--
Thanks,
Rich Kulp
|
|
|
| Re: VE and private members [message #607955 is a reply to message #93849] |
Tue, 14 June 2005 14:58 |
| Eclipse User |
|
|
|
Originally posted by: raysnews.web.de
Rich Kulp wrote:
> You are the developer of the class. It is your job to decide what is
> exposed and what isn't. Typically you should not expose everything, only
> the things that make sense. So you should not create an accessor for
> every control, just the ones that you feel a user of your class should
> have access to. If you expose everything you have now created a contract
> that becomes very difficult to maintain. You will not be allowed to
> remove anything in the future.
>
I understand want you want to tell me and I agree to you fully. The
access to a class should be as little as possible. But how can I solve
this concrete problem ? Ok, I could use the VE to create my listeners
inside the classes but that also would make them bigger and bigger and
fill them with code (inside the listeners) that doesn't really belong to
them.
By the way, the attribute don't have to be non-private. But VE already
generates "access methods" anyway (if they wouldn't be private). Maybe
there could be an option for a visual bean in the "Java Beans"-View to
let me choose the visibility outside the class ?
|
|
|
| Re: VE and private members [message #607956 is a reply to message #93820] |
Tue, 14 June 2005 15:30 |
| Eclipse User |
|
|
|
Originally posted by: raysnews.web.de
Jeff Myers wrote:
> I'd suggest a preference in the VE's code generation section allowing
> you to specify the access modifier for generated methods. Enhancement
> request anyone?
>
> Just my $0.02.
>
> - Jeff
Yes, I think, that would be a nice option (or an example for a nice
coding pattern ;-) ). See my other posting to Rich.
|
|
|
| Re: VE and private members [message #608129 is a reply to message #93983] |
Thu, 30 June 2005 15:04 |
| Eclipse User |
|
|
|
Ray Kane wrote:
> Rich Kulp wrote:
>
>> You are the developer of the class. It is your job to decide what is
>> exposed and what isn't. Typically you should not expose everything,
>> only the things that make sense. So you should not create an accessor
>> for every control, just the ones that you feel a user of your class
>> should have access to. If you expose everything you have now created a
>> contract that becomes very difficult to maintain. You will not be
>> allowed to remove anything in the future.
>>
> I understand want you want to tell me and I agree to you fully. The
> access to a class should be as little as possible. But how can I solve
> this concrete problem ? Ok, I could use the VE to create my listeners
> inside the classes but that also would make them bigger and bigger and
> fill them with code (inside the listeners) that doesn't really belong to
> them.
> By the way, the attribute don't have to be non-private. But VE already
> generates "access methods" anyway (if they wouldn't be private). Maybe
> there could be an option for a visual bean in the "Java Beans"-View to
> let me choose the visibility outside the class ?
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=102263, this may be of help for you
|
|
|
Powered by
FUDForum. Page generated in 0.74321 seconds
Home