对我没有要求的内容进行比较。
我的问题涉及从嵌入在容器对象中的委托派生的属性。
尽管所有属性的设置器（无论类型）都可以轻松方便地以“set”为前缀（例如 setValueRequired(blah) ），但存在各种类型的布尔属性，每个属性的 getter 通常被命名为 {verb}{PropertyName}。例如，
- 最常见的是存在主义，按照惯例以“is”为前缀。例如 isEmpty()。
- 所有格属性，以“has”为前缀，例如 hasValue()。
- 确认必要性，以“requires”为前缀，例如 requiresResize()、providesResize()。
到目前为止，大多数属性获取器都以某种方式转换为存在属性。例如 isRequireResize、isValued 等。因此，我的问题只涉及表达存在的布尔属性（委托类的）。
假设容器类是 Printer，其中包含类 Queue。
class Queue {
boolean empty, resettable, resizable;
}
class Printer {
Queue queue;
}
那么打印机应该如何为队列命名它的委托属性呢？因为按照英语理解惯例，以下内容很尴尬，因为它们听起来像是在问一个问题，而不是肯定它的状态。
- isQueueEmpty()
- isQueueResettable()
- isQueueResizable()
布尔属性应该是肯定的，听起来不像是在问问题。因此，对于可理解的英语，它们应该是
- queueIsEmpty()
- queueIsResettable()
- queueIsResizable()
或者，可以是
- isEmptyQueue()
- isResettableQueue()
- isResizableQueue()
但是，自动委托方法代码生成器总是生成名称 isQueueEmpty()、isQueueResettable()、isQueueResizable()。
放入 if 时很尴尬
if (isQueueResettable() && !isQueueEmpty()) resetQueue();
因为这听起来更好
if (isResizableQueue() && !isEmptyQueue()) resetQueue();
〜
我的问题实际上
如果有 JSR 推荐属性获取器的命名约定？它是什么？当然必须有，否则不是所有的代码生成器都会在模棱两可的约定中一瘸一拐吗？
如果有，JSR 是否推荐了委托布尔存在属性获取器？
如果不是 JSR，至少是 Apache、JBoss、Eclipse 等中的某种形式的 RFC？
您不认为我推荐的约定比创建质疑获取器的代码生成器更好吗？