On 1/29/2013 3:13 PM, Steve Ebersole wrote:
> Ok, I think I was missing this part in my earlier questions.
>
> So AttributeNode.getType() is going away; got it. Will there be separate getSubgraphs() and getKeySubgraphs() methods
> (in addition to getAttributeNodes()) as mentioned by Gordon?
>
Not in this release, but perhaps later if needed.
> Still does not clear up my overall confusion of addAttributeNodes when passed non-basic types in terms of spec-defined
> behavior.
>
>
> On Thu 17 Jan 2013 04:43:54 PM CST, Linda DeMichiel wrote:
>> Thanks, Gordon.
>>
>> Folks, I plan to remove AttributeNode.getType(). Yell now if you
>> disagree.
>>
>> -Linda
>>
>> On 1/17/2013 12:44 PM, Gordon Yorke wrote:
>>> Perhaps but they are practically the same thing in this case and I do
>>> not see a clear use case for this information
>>> especially since there is no way to inspect the related subgraphs of
>>> the attribute node. It would be far more helpful to
>>> add getSubgraphs() getKeySubgraphs() as a starting point for
>>> EntityGraph inspection.
>>> --Gordon
>>>
>>> On 17/01/2013 4:14 PM, Linda DeMichiel wrote:
>>>> Hi Gordon,
>>>>
>>>> On 1/17/2013 12:06 PM, Gordon Yorke wrote:
>>>>> Building on Ollie's feedback with respect to BindableType I was
>>>>> reviewing AttributeNode.getType() and see this method as
>>>>> having very little value and unnecessarily crowds the interface.
>>>>> Given the stage we are at with delivering the
>>>>> specifiation I suggest we simply remove this method for now and
>>>>> provide other methods that add value to the interface in
>>>>> the future.
>>>>
>>>> Would it be useful to simply return the Java type rather than Type?
>>>>
>>>>
>>>>
>>>