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 202663 - [71cat] Encapsulate field, code position
Summary: [71cat] Encapsulate field, code position
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 7.1
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-26 11:24 UTC by muellermi
Modified: 2014-08-15 15:53 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description muellermi 2011-09-26 11:24:40 UTC
Product Version = NetBeans IDE 7.1 Beta (Build 201109222201)
Operating System = Windows XP version 5.1 running on x86
Java; VM; Vendor = 1.7.0
Runtime = Java HotSpot(TM) Client VM 21.0-b17

    // <editor-fold defaultstate="collapsed" desc="getter / setter Definition">
    public String getNames() {...}
    public void setName(String name) {...}
    // </editor-fold>

Next, add a new field, e.g. "private int age"
Highlight age, start refactoring "encapsulate field", insert after setName

NB will insert after " // </editor-fold>"

--> if existing coderelated to "after/before"  is contained within a code fold comment, insert new code within the same code fold.
Comment 1 Jan Lahoda 2013-07-09 14:48:33 UTC
Belongs to Java, even though exact category is not completely clean without deeper look.
Comment 2 muellermi 2013-07-09 19:49:52 UTC
Belongs to Java? Doesn't it belong to editor?
Comment 3 Svata Dedic 2014-08-15 15:53:02 UTC
Enhancement; the base code generator has no clue about getter/setter encapsulation pattern. Even if it had, it has to connect somehow the knowledge with the custom editor fold (which it does not know either).

Right now the // <editor-fold> is treated just as any other comment - and since there's no code following (at least in the sample), it's connected to the preceding code fragment (setName() method).

If the // editor-fold would be followed by another method or field (with no blank line, or less blank lines than between // </editor-fold> and the last folded decl), or if the insertion point would be set "after getName()", the code would be generated inside the fold.

To make these fine adjustments, some additional API could be needed to hint the code generator what is really "after setName"; maybe even the UI could understand the custom grouping somehow and present an additional insertion point (?)