This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 22384 - Deprecate use of Node.setName, etc. for future
Summary: Deprecate use of Node.setName, etc. for future
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jaroslav Tulach
URL: http://openide.netbeans.org/servlets/...
Keywords: API
Depends on:
Blocks: 19446 19504 32744
  Show dependency tree
 
Reported: 2002-04-12 17:45 UTC by Jesse Glick
Modified: 2010-04-06 05:07 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-04-12 17:45:12 UTC
This is a 4.0-type architectural cleanup request.

Currently for classes inheriting from
FeatureDescriptor, there are basically two ways to
provide special behavior for name (displayName,
shortDescription):

1. Call setName (setDisplayName, ...) whenever you
like.

2. Override getName (...) to return the currently
correct value, and call fireNameChange (...) when
that value would become different.

A similar situation applies to
AbstractNode.setIconBase vs. getIcon.

As mentioned in the message to dev@openide (see
URL), I believe approach #2 is much more
maintainable when subclassing is a possibility,
and thus that approach #1 should be deprecated, e.g.:

1. Deprecate Node.setName etc. in Javadoc. And/or
produce runtime warnings.

2. Request existing subclasses of Node to override
getName (...) where dynamic behavior is needed.
Include this request in an upgrade guide.
Specifically, change DataNode's behavior with the
showFileExtensions flag: DataNode should only
override getName (never call setName), and its
impl should compute the name based on
DataObject.name, showFileExtensions, and the
FileSystem.Status annotations. The node for
DefaultDataObject would behave similarly but treat
showFileExtensions as always on. (Perhaps
showFileExtensions should be deprecated and
reimplemented somehow because it is ugly, but I do
not have a proposal here.)

3. It would be unfortunate to require someone to
subclass AbstractNode (e.g.) just to be able to
set the name, where currently they do not! So
provide a new API call similar to the situation
with AbstractLookup and InstanceContent:

3a. A new class (?) holding basic bits of Node
information such as name, displayName,
shortDescription, iconBase; public getters and
setters for them.

3b. A constructor for AbstractNode accepting an
object of this class. If you actually make the
AbstractNode, you can hold onto an instance of
this controller and change its name, without
subclassing the node itself. If you did not make
the node, you cannot change its name etc. - i.e.
the "setters" are effectively protected, with
public getters - since the AbstractNode provides
no way to get the controller once created.

3c. Constructors accepting this controller object
for other nodes in the APIs which extend
AbstractNode and which do not normally provide
dynamic naming (or icon) behavior, and for which
it is likely that someone would want to configure
the name. I am not sure of any examples offhand
however.

3d. Other subclasses of Node or AbstractNode
should decide whether to override getName (...)
and if so whether to make the override final; or
to avoid overriding getName (...) and instead
provide a constructor with the controller object;
or something else along these lines.
Comment 1 Jesse Glick 2002-04-12 17:53:39 UTC
Some relevant bugs caused by, or whose solution was made more complex
by, the mixing of set-style vs. override-style idioms, are listed in
the "blocks" area here. I will add more if I remember any. Also cf.
DataNode.java 1.52 which seems to be similar.
Comment 2 Jesse Glick 2003-04-10 02:19:24 UTC
I see that AbstractNode.setPreferredAction was introduced in 3.5 along
with a nonfinal getPreferredAction. This is unfortunate (see issue
#32744 for some problems it contributes to). Is it too late to delete
the setter method before 3.5 is released?
Comment 3 Petr Nejedly 2004-01-09 09:44:14 UTC
Taking over the node bugs from phrebejk.
Comment 4 Antonin Nebuzelsky 2008-02-08 15:02:05 UTC
Reassigning to new module owner Tomas Holy.
Comment 5 Jaroslav Tulach 2010-04-06 05:07:03 UTC
Too late. According to our compatibility policy I would need to go through all our sources and clean them up. I am not going to do that.