|
| Re: IPathGroup issues [message #489561 is a reply to message #489521] |
Sun, 04 October 2009 23:32   |
|
On 10/04/2009 02:44 PM, Henrik Lindberg wrote:
> Hi,
> The modeled IPathGroup has a base path, and 0..* paths.
> Use of IPathGroup is correct when looking at IArtifactsPart, and
> ResultingPathGroup as the relationship is 0..*.
>
> The IGenericUnit however has a relationship to 0..1 IPathGroup called
> "self". This is supposed to represent a unit as a set of all path groups
> from all parts. But that obviously is wrong right now.
> This could be changed to 0..* as well.
>
> But I wonder if we should not use a more complex IPathGroupCollection as
> the value everywhere - i.e. let IArtifactsPart and ResultingPathGroup
> have one such collection, and let IGenericUnit's self reference it with
> 1..1.
>
> The IPathGroupCollection (or some other name like IPathGroups) would
> simply be a collection of IPathGroup.
>
> I came across this issue when modelling interfaces for unit types (e.g.
> the Java interface for and osgi.bundle - what is the return type
> supposed to be? I started using IPathGroup, but I think that
> IPathGroupCollection should be used instead).
>
> On naming - we could call the more complex type IPathGroup (as it is
> perhaps used more often), and call the current IPathGroup IPathElement
> or similar.
>
> Any thoughts on this?
> What are the corresponding types called in Buckminster?
>
In Buckminster, all attributes are expected to provide a PathGroup array, not a single PathGroup. It doesn't have any
specific name. The method is that does the bulk of the work is:
PathGroup[] getPathGroups(IModelCache ctx, Stack<IAttributeFilter> filters)
implemented on the generic Attribute class. I'm all for using special type for this. Perhaps it should be a List or a
Set, and not just a Collection. Or why not simply:
IPathGroupList extends List<IPathGroup>
I'm not in favor of IPathElement since it sounds like one element in a path rather then a grouping of paths. I'm quite
fond of the name PathGroup actually. It's a group of paths under a common base.
Regards,
Thomas Hallgren
|
|
|
|
| Re: IPathGroup issues [message #581033 is a reply to message #489521] |
Sun, 04 October 2009 23:32 |
|
On 10/04/2009 02:44 PM, Henrik Lindberg wrote:
> Hi,
> The modeled IPathGroup has a base path, and 0..* paths.
> Use of IPathGroup is correct when looking at IArtifactsPart, and
> ResultingPathGroup as the relationship is 0..*.
>
> The IGenericUnit however has a relationship to 0..1 IPathGroup called
> "self". This is supposed to represent a unit as a set of all path groups
> from all parts. But that obviously is wrong right now.
> This could be changed to 0..* as well.
>
> But I wonder if we should not use a more complex IPathGroupCollection as
> the value everywhere - i.e. let IArtifactsPart and ResultingPathGroup
> have one such collection, and let IGenericUnit's self reference it with
> 1..1.
>
> The IPathGroupCollection (or some other name like IPathGroups) would
> simply be a collection of IPathGroup.
>
> I came across this issue when modelling interfaces for unit types (e.g.
> the Java interface for and osgi.bundle - what is the return type
> supposed to be? I started using IPathGroup, but I think that
> IPathGroupCollection should be used instead).
>
> On naming - we could call the more complex type IPathGroup (as it is
> perhaps used more often), and call the current IPathGroup IPathElement
> or similar.
>
> Any thoughts on this?
> What are the corresponding types called in Buckminster?
>
In Buckminster, all attributes are expected to provide a PathGroup array, not a single PathGroup. It doesn't have any
specific name. The method is that does the bulk of the work is:
PathGroup[] getPathGroups(IModelCache ctx, Stack<IAttributeFilter> filters)
implemented on the generic Attribute class. I'm all for using special type for this. Perhaps it should be a List or a
Set, and not just a Collection. Or why not simply:
IPathGroupList extends List<IPathGroup>
I'm not in favor of IPathElement since it sounds like one element in a path rather then a grouping of paths. I'm quite
fond of the name PathGroup actually. It's a group of paths under a common base.
Regards,
Thomas Hallgren
|
|
|
|
Powered by
FUDForum. Page generated in 0.02808 seconds
] 
Search
Help
Register
Login
Home
