Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » OclInvalid and Collections
| OclInvalid and Collections [message #42152] |
Fri, 28 July 2006 05:52  |
Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
I have a question about OclInvalid and collections.
If I have the following Ocl statement:
Employee.allInstances()->collect( e | e.manager.lastName)
I would expect it to return the last name of everyone who manages
someone. However, if someone does not have a manager (say the CEO or
something) than this entire statement returns invalid.
I know the spec says that collections cannot contain OclInvalid,
although does it say what it should do when it finds one. For example,
if I had the following organization
C reports to B and B reports to A
e.manager should return
{B, A, null} and when I ask for the lastName I would get a list that
includes an OclInvalid, and thus the statement is invalid. Can we not
just throw out the OclInvalids, leaving us with just the last names for
B and A {b, a}, and thus a valid result?
Maybe this is just an over simplification of the spec, but it seems like
it could be a powerful option. Basically it saves writing ->reject ( o
| o.null ) after every collection.
Cheers,
Ian
|
|
|
| Re: OclInvalid and Collections [message #42294 is a reply to message #42152] |
Fri, 28 July 2006 15:55  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ian,
Yes, I had a problem with this constraint on collections, myself. You are
correct that the spec gives tools no guidance regarding how to enforce such
constraints, so I just figured returning OclInvalid would at least be
consistent.
In this respect, I do also prefer the pre-OclInvalid definition of the
language. However, perhaps this should be an API option rather than a
choice that we make? I'm not sure that simply omitting the last value in
the collection in your example is a good idea, though, because now the
collection contains fewer answers than were expected, with no correspondent
of the CEO. I would prefer to optionally coerce OclInvalids to null, which
is more Java-friendly, anyway.
Could you please raise an enhancement on bugzilla for our consideration?
Thanks,
Christian
Ian Bull wrote:
> I have a question about OclInvalid and collections.
>
> If I have the following Ocl statement:
> Employee.allInstances()->collect( e | e.manager.lastName)
>
> I would expect it to return the last name of everyone who manages
> someone. However, if someone does not have a manager (say the CEO or
> something) than this entire statement returns invalid.
>
> I know the spec says that collections cannot contain OclInvalid,
> although does it say what it should do when it finds one. For example,
> if I had the following organization
>
> C reports to B and B reports to A
>
> e.manager should return
> {B, A, null} and when I ask for the lastName I would get a list that
> includes an OclInvalid, and thus the statement is invalid. Can we not
> just throw out the OclInvalids, leaving us with just the last names for
> B and A {b, a}, and thus a valid result?
>
> Maybe this is just an over simplification of the spec, but it seems like
> it could be a powerful option. Basically it saves writing ->reject ( o
> | o.null ) after every collection.
>
> Cheers,
> Ian
|
|
|
| Re: OclInvalid and Collections [message #42346 is a reply to message #42294] |
Fri, 28 July 2006 17:21 |
| Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
Sure, I will do that. I have a few more that I have stumbled upon that
I will bring up. Primarily I am using OCL as a query language rather
than a constraint language, which is why I am using it in strange ways
(it makes a really good graph walking language).
I must say, you guys did a really good job. I am using it on a large
model (40,000 EObjects) it is working without problems.
Cheers,
Ian
Christian W. Damus wrote:
> Hi, Ian,
>
> Yes, I had a problem with this constraint on collections, myself. You are
> correct that the spec gives tools no guidance regarding how to enforce such
> constraints, so I just figured returning OclInvalid would at least be
> consistent.
>
> In this respect, I do also prefer the pre-OclInvalid definition of the
> language. However, perhaps this should be an API option rather than a
> choice that we make? I'm not sure that simply omitting the last value in
> the collection in your example is a good idea, though, because now the
> collection contains fewer answers than were expected, with no correspondent
> of the CEO. I would prefer to optionally coerce OclInvalids to null, which
> is more Java-friendly, anyway.
>
> Could you please raise an enhancement on bugzilla for our consideration?
>
> Thanks,
>
> Christian
>
>
> Ian Bull wrote:
>
>> I have a question about OclInvalid and collections.
>>
>> If I have the following Ocl statement:
>> Employee.allInstances()->collect( e | e.manager.lastName)
>>
>> I would expect it to return the last name of everyone who manages
>> someone. However, if someone does not have a manager (say the CEO or
>> something) than this entire statement returns invalid.
>>
>> I know the spec says that collections cannot contain OclInvalid,
>> although does it say what it should do when it finds one. For example,
>> if I had the following organization
>>
>> C reports to B and B reports to A
>>
>> e.manager should return
>> {B, A, null} and when I ask for the lastName I would get a list that
>> includes an OclInvalid, and thus the statement is invalid. Can we not
>> just throw out the OclInvalids, leaving us with just the last names for
>> B and A {b, a}, and thus a valid result?
>>
>> Maybe this is just an over simplification of the spec, but it seems like
>> it could be a powerful option. Basically it saves writing ->reject ( o
>> | o.null ) after every collection.
>>
>> Cheers,
>> Ian
>
|
|
|
| Re: OclInvalid and Collections [message #42383 is a reply to message #42346] |
Fri, 28 July 2006 17:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Ian Bull wrote:
> Sure, I will do that. I have a few more that I have stumbled upon that
> I will bring up. Primarily I am using OCL as a query language rather
> than a constraint language, which is why I am using it in strange ways
> (it makes a really good graph walking language).
Yes, my favourite feature of OCL for querying is Tuples: these implement
something akin to both the relational "project" and "join" operators.
BTW, have I mentioned yet that the closure iterator (non-spec) that we
implemented reduces your recursive getSubroles() problem to a very simple
expression and also avoids infinite recursion on cycles?
>
> I must say, you guys did a really good job. I am using it on a large
> model (40,000 EObjects) it is working without problems.
Great! We're always glad to hear of success.
Thanks,
Christian
>
> Cheers,
> Ian
>
> Christian W. Damus wrote:
>> Hi, Ian,
>>
>> Yes, I had a problem with this constraint on collections, myself. You
>> are correct that the spec gives tools no guidance regarding how to
>> enforce such constraints, so I just figured returning OclInvalid would at
>> least be consistent.
>>
>> In this respect, I do also prefer the pre-OclInvalid definition of the
>> language. However, perhaps this should be an API option rather than a
>> choice that we make? I'm not sure that simply omitting the last value in
>> the collection in your example is a good idea, though, because now the
>> collection contains fewer answers than were expected, with no
>> correspondent
>> of the CEO. I would prefer to optionally coerce OclInvalids to null,
>> which is more Java-friendly, anyway.
>>
>> Could you please raise an enhancement on bugzilla for our consideration?
>>
>> Thanks,
>>
>> Christian
>>
>>
>> Ian Bull wrote:
>>
>>> I have a question about OclInvalid and collections.
>>>
>>> If I have the following Ocl statement:
>>> Employee.allInstances()->collect( e | e.manager.lastName)
>>>
>>> I would expect it to return the last name of everyone who manages
>>> someone. However, if someone does not have a manager (say the CEO or
>>> something) than this entire statement returns invalid.
>>>
>>> I know the spec says that collections cannot contain OclInvalid,
>>> although does it say what it should do when it finds one. For example,
>>> if I had the following organization
>>>
>>> C reports to B and B reports to A
>>>
>>> e.manager should return
>>> {B, A, null} and when I ask for the lastName I would get a list that
>>> includes an OclInvalid, and thus the statement is invalid. Can we not
>>> just throw out the OclInvalids, leaving us with just the last names for
>>> B and A {b, a}, and thus a valid result?
>>>
>>> Maybe this is just an over simplification of the spec, but it seems like
>>> it could be a powerful option. Basically it saves writing ->reject ( o
>>> | o.null ) after every collection.
>>>
>>> Cheers,
>>> Ian
>>
|
|
|
| Re: OclInvalid and Collections [message #42398 is a reply to message #42383] |
Fri, 28 July 2006 18:35 |
| Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
https://bugs.eclipse.org/bugs/show_bug.cgi?id=152190
Cheers,
ian
Christian W. Damus wrote:
> Ian Bull wrote:
>
>> Sure, I will do that. I have a few more that I have stumbled upon that
>> I will bring up. Primarily I am using OCL as a query language rather
>> than a constraint language, which is why I am using it in strange ways
>> (it makes a really good graph walking language).
>
> Yes, my favourite feature of OCL for querying is Tuples: these implement
> something akin to both the relational "project" and "join" operators.
>
> BTW, have I mentioned yet that the closure iterator (non-spec) that we
> implemented reduces your recursive getSubroles() problem to a very simple
> expression and also avoids infinite recursion on cycles?
>
>> I must say, you guys did a really good job. I am using it on a large
>> model (40,000 EObjects) it is working without problems.
>
> Great! We're always glad to hear of success.
>
> Thanks,
>
> Christian
>
>
>> Cheers,
>> Ian
>>
>> Christian W. Damus wrote:
>>> Hi, Ian,
>>>
>>> Yes, I had a problem with this constraint on collections, myself. You
>>> are correct that the spec gives tools no guidance regarding how to
>>> enforce such constraints, so I just figured returning OclInvalid would at
>>> least be consistent.
>>>
>>> In this respect, I do also prefer the pre-OclInvalid definition of the
>>> language. However, perhaps this should be an API option rather than a
>>> choice that we make? I'm not sure that simply omitting the last value in
>>> the collection in your example is a good idea, though, because now the
>>> collection contains fewer answers than were expected, with no
>>> correspondent
>>> of the CEO. I would prefer to optionally coerce OclInvalids to null,
>>> which is more Java-friendly, anyway.
>>>
>>> Could you please raise an enhancement on bugzilla for our consideration?
>>>
>>> Thanks,
>>>
>>> Christian
>>>
>>>
>>> Ian Bull wrote:
>>>
>>>> I have a question about OclInvalid and collections.
>>>>
>>>> If I have the following Ocl statement:
>>>> Employee.allInstances()->collect( e | e.manager.lastName)
>>>>
>>>> I would expect it to return the last name of everyone who manages
>>>> someone. However, if someone does not have a manager (say the CEO or
>>>> something) than this entire statement returns invalid.
>>>>
>>>> I know the spec says that collections cannot contain OclInvalid,
>>>> although does it say what it should do when it finds one. For example,
>>>> if I had the following organization
>>>>
>>>> C reports to B and B reports to A
>>>>
>>>> e.manager should return
>>>> {B, A, null} and when I ask for the lastName I would get a list that
>>>> includes an OclInvalid, and thus the statement is invalid. Can we not
>>>> just throw out the OclInvalids, leaving us with just the last names for
>>>> B and A {b, a}, and thus a valid result?
>>>>
>>>> Maybe this is just an over simplification of the spec, but it seems like
>>>> it could be a powerful option. Basically it saves writing ->reject ( o
>>>> | o.null ) after every collection.
>>>>
>>>> Cheers,
>>>> Ian
>
|
|
|
| Re: OclInvalid and Collections [message #42455 is a reply to message #42383] |
Sat, 29 July 2006 15:24 |
| Eclipse User |
|
|
|
Originally posted by: sven.efftinge.de
Christian W. Damus schrieb:
> BTW, have I mentioned yet that the closure iterator (non-spec) that we
> implemented reduces your recursive getSubroles() problem to a very simple
> expression and also avoids infinite recursion on cycles?
Sounds interesting, is there a sample or any other kind of documentation
available for this feature?
Are there other interesting, non-spec features included in your
implementation? Allthough I like most of the features EOCL 2.0 provides
I think there is much space for improvement.
What are the plans for the next version?
regards,
Sven
|
|
|
| Re: OclInvalid and Collections [message #42832 is a reply to message #42455] |
Tue, 01 August 2006 19:25 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Sven,
There is no documentation nor example, I'm afraid. I can provide an
illustrative example here. The recursive operation that is discussed in
Chris Lenz's "'OCL Error' lost in space" thread could be implemented as the
following, using the closure iterator:
context Role
def getSubroles() : Set(Role) =
self.role->closure(subrole)
The closure iterator supports the usual iterator syntax, so it could be
written as "closure(r : Role | r.subrole)".
I should apologize to Chris and Ian for getting confused about the owner of
the recursive operation definition conundrum. Sorry!
I'm glad you like what we have done so far, and I definitely agree that
there is room for improvement! Any help you can offer will be most welcome
:-)
We will be starting the planning for the EMFT OCL release that lines up with
3.3 soon, so there is no plan available, yet. In the mean-time, we are
also looking at getting the Eclipse Modeling Project provisioned and how
EMFT OCL will fit into that. Feel free to suggest enhancements in
Bugzilla, to provide ideas for the next release!
Thanks,
Christian
Sven Efftinge wrote:
> Christian W. Damus schrieb:
>> BTW, have I mentioned yet that the closure iterator (non-spec) that we
>> implemented reduces your recursive getSubroles() problem to a very simple
>> expression and also avoids infinite recursion on cycles?
>
> Sounds interesting, is there a sample or any other kind of documentation
> available for this feature?
>
> Are there other interesting, non-spec features included in your
> implementation? Allthough I like most of the features EOCL 2.0 provides
> I think there is much space for improvement.
>
> What are the plans for the next version?
>
> regards,
> Sven
|
|
|
| Re: OclInvalid and Collections [message #583828 is a reply to message #42152] |
Fri, 28 July 2006 15:55 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ian,
Yes, I had a problem with this constraint on collections, myself. You are
correct that the spec gives tools no guidance regarding how to enforce such
constraints, so I just figured returning OclInvalid would at least be
consistent.
In this respect, I do also prefer the pre-OclInvalid definition of the
language. However, perhaps this should be an API option rather than a
choice that we make? I'm not sure that simply omitting the last value in
the collection in your example is a good idea, though, because now the
collection contains fewer answers than were expected, with no correspondent
of the CEO. I would prefer to optionally coerce OclInvalids to null, which
is more Java-friendly, anyway.
Could you please raise an enhancement on bugzilla for our consideration?
Thanks,
Christian
Ian Bull wrote:
> I have a question about OclInvalid and collections.
>
> If I have the following Ocl statement:
> Employee.allInstances()->collect( e | e.manager.lastName)
>
> I would expect it to return the last name of everyone who manages
> someone. However, if someone does not have a manager (say the CEO or
> something) than this entire statement returns invalid.
>
> I know the spec says that collections cannot contain OclInvalid,
> although does it say what it should do when it finds one. For example,
> if I had the following organization
>
> C reports to B and B reports to A
>
> e.manager should return
> {B, A, null} and when I ask for the lastName I would get a list that
> includes an OclInvalid, and thus the statement is invalid. Can we not
> just throw out the OclInvalids, leaving us with just the last names for
> B and A {b, a}, and thus a valid result?
>
> Maybe this is just an over simplification of the spec, but it seems like
> it could be a powerful option. Basically it saves writing ->reject ( o
> | o.null ) after every collection.
>
> Cheers,
> Ian
|
|
|
| Re: OclInvalid and Collections [message #583857 is a reply to message #42294] |
Fri, 28 July 2006 17:21 |
 Ian Bull
Messages: 145
Registered: July 2009 |
Senior Member |
|
|
Sure, I will do that. I have a few more that I have stumbled upon that
I will bring up. Primarily I am using OCL as a query language rather
than a constraint language, which is why I am using it in strange ways
(it makes a really good graph walking language).
I must say, you guys did a really good job. I am using it on a large
model (40,000 EObjects) it is working without problems.
Cheers,
Ian
Christian W. Damus wrote:
> Hi, Ian,
>
> Yes, I had a problem with this constraint on collections, myself. You are
> correct that the spec gives tools no guidance regarding how to enforce such
> constraints, so I just figured returning OclInvalid would at least be
> consistent.
>
> In this respect, I do also prefer the pre-OclInvalid definition of the
> language. However, perhaps this should be an API option rather than a
> choice that we make? I'm not sure that simply omitting the last value in
> the collection in your example is a good idea, though, because now the
> collection contains fewer answers than were expected, with no correspondent
> of the CEO. I would prefer to optionally coerce OclInvalids to null, which
> is more Java-friendly, anyway.
>
> Could you please raise an enhancement on bugzilla for our consideration?
>
> Thanks,
>
> Christian
>
>
> Ian Bull wrote:
>
>> I have a question about OclInvalid and collections.
>>
>> If I have the following Ocl statement:
>> Employee.allInstances()->collect( e | e.manager.lastName)
>>
>> I would expect it to return the last name of everyone who manages
>> someone. However, if someone does not have a manager (say the CEO or
>> something) than this entire statement returns invalid.
>>
>> I know the spec says that collections cannot contain OclInvalid,
>> although does it say what it should do when it finds one. For example,
>> if I had the following organization
>>
>> C reports to B and B reports to A
>>
>> e.manager should return
>> {B, A, null} and when I ask for the lastName I would get a list that
>> includes an OclInvalid, and thus the statement is invalid. Can we not
>> just throw out the OclInvalids, leaving us with just the last names for
>> B and A {b, a}, and thus a valid result?
>>
>> Maybe this is just an over simplification of the spec, but it seems like
>> it could be a powerful option. Basically it saves writing ->reject ( o
>> | o.null ) after every collection.
>>
>> Cheers,
>> Ian
>
|
|
|
| Re: OclInvalid and Collections [message #583873 is a reply to message #42346] |
Fri, 28 July 2006 17:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Ian Bull wrote:
> Sure, I will do that. I have a few more that I have stumbled upon that
> I will bring up. Primarily I am using OCL as a query language rather
> than a constraint language, which is why I am using it in strange ways
> (it makes a really good graph walking language).
Yes, my favourite feature of OCL for querying is Tuples: these implement
something akin to both the relational "project" and "join" operators.
BTW, have I mentioned yet that the closure iterator (non-spec) that we
implemented reduces your recursive getSubroles() problem to a very simple
expression and also avoids infinite recursion on cycles?
>
> I must say, you guys did a really good job. I am using it on a large
> model (40,000 EObjects) it is working without problems.
Great! We're always glad to hear of success.
Thanks,
Christian
>
> Cheers,
> Ian
>
> Christian W. Damus wrote:
>> Hi, Ian,
>>
>> Yes, I had a problem with this constraint on collections, myself. You
>> are correct that the spec gives tools no guidance regarding how to
>> enforce such constraints, so I just figured returning OclInvalid would at
>> least be consistent.
>>
>> In this respect, I do also prefer the pre-OclInvalid definition of the
>> language. However, perhaps this should be an API option rather than a
>> choice that we make? I'm not sure that simply omitting the last value in
>> the collection in your example is a good idea, though, because now the
>> collection contains fewer answers than were expected, with no
>> correspondent
>> of the CEO. I would prefer to optionally coerce OclInvalids to null,
>> which is more Java-friendly, anyway.
>>
>> Could you please raise an enhancement on bugzilla for our consideration?
>>
>> Thanks,
>>
>> Christian
>>
>>
>> Ian Bull wrote:
>>
>>> I have a question about OclInvalid and collections.
>>>
>>> If I have the following Ocl statement:
>>> Employee.allInstances()->collect( e | e.manager.lastName)
>>>
>>> I would expect it to return the last name of everyone who manages
>>> someone. However, if someone does not have a manager (say the CEO or
>>> something) than this entire statement returns invalid.
>>>
>>> I know the spec says that collections cannot contain OclInvalid,
>>> although does it say what it should do when it finds one. For example,
>>> if I had the following organization
>>>
>>> C reports to B and B reports to A
>>>
>>> e.manager should return
>>> {B, A, null} and when I ask for the lastName I would get a list that
>>> includes an OclInvalid, and thus the statement is invalid. Can we not
>>> just throw out the OclInvalids, leaving us with just the last names for
>>> B and A {b, a}, and thus a valid result?
>>>
>>> Maybe this is just an over simplification of the spec, but it seems like
>>> it could be a powerful option. Basically it saves writing ->reject ( o
>>> | o.null ) after every collection.
>>>
>>> Cheers,
>>> Ian
>>
|
|
|
| Re: OclInvalid and Collections [message #583889 is a reply to message #42383] |
Fri, 28 July 2006 18:35 |
Ian Bull
Messages: 145
Registered: July 2009 |
Senior Member |
|
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=152190
Cheers,
ian
Christian W. Damus wrote:
> Ian Bull wrote:
>
>> Sure, I will do that. I have a few more that I have stumbled upon that
>> I will bring up. Primarily I am using OCL as a query language rather
>> than a constraint language, which is why I am using it in strange ways
>> (it makes a really good graph walking language).
>
> Yes, my favourite feature of OCL for querying is Tuples: these implement
> something akin to both the relational "project" and "join" operators.
>
> BTW, have I mentioned yet that the closure iterator (non-spec) that we
> implemented reduces your recursive getSubroles() problem to a very simple
> expression and also avoids infinite recursion on cycles?
>
>> I must say, you guys did a really good job. I am using it on a large
>> model (40,000 EObjects) it is working without problems.
>
> Great! We're always glad to hear of success.
>
> Thanks,
>
> Christian
>
>
>> Cheers,
>> Ian
>>
>> Christian W. Damus wrote:
>>> Hi, Ian,
>>>
>>> Yes, I had a problem with this constraint on collections, myself. You
>>> are correct that the spec gives tools no guidance regarding how to
>>> enforce such constraints, so I just figured returning OclInvalid would at
>>> least be consistent.
>>>
>>> In this respect, I do also prefer the pre-OclInvalid definition of the
>>> language. However, perhaps this should be an API option rather than a
>>> choice that we make? I'm not sure that simply omitting the last value in
>>> the collection in your example is a good idea, though, because now the
>>> collection contains fewer answers than were expected, with no
>>> correspondent
>>> of the CEO. I would prefer to optionally coerce OclInvalids to null,
>>> which is more Java-friendly, anyway.
>>>
>>> Could you please raise an enhancement on bugzilla for our consideration?
>>>
>>> Thanks,
>>>
>>> Christian
>>>
>>>
>>> Ian Bull wrote:
>>>
>>>> I have a question about OclInvalid and collections.
>>>>
>>>> If I have the following Ocl statement:
>>>> Employee.allInstances()->collect( e | e.manager.lastName)
>>>>
>>>> I would expect it to return the last name of everyone who manages
>>>> someone. However, if someone does not have a manager (say the CEO or
>>>> something) than this entire statement returns invalid.
>>>>
>>>> I know the spec says that collections cannot contain OclInvalid,
>>>> although does it say what it should do when it finds one. For example,
>>>> if I had the following organization
>>>>
>>>> C reports to B and B reports to A
>>>>
>>>> e.manager should return
>>>> {B, A, null} and when I ask for the lastName I would get a list that
>>>> includes an OclInvalid, and thus the statement is invalid. Can we not
>>>> just throw out the OclInvalids, leaving us with just the last names for
>>>> B and A {b, a}, and thus a valid result?
>>>>
>>>> Maybe this is just an over simplification of the spec, but it seems like
>>>> it could be a powerful option. Basically it saves writing ->reject ( o
>>>> | o.null ) after every collection.
>>>>
>>>> Cheers,
>>>> Ian
>
|
|
| |
| Re: OclInvalid and Collections [message #584132 is a reply to message #42455] |
Tue, 01 August 2006 19:25 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Sven,
There is no documentation nor example, I'm afraid. I can provide an
illustrative example here. The recursive operation that is discussed in
Chris Lenz's "'OCL Error' lost in space" thread could be implemented as the
following, using the closure iterator:
context Role
def getSubroles() : Set(Role) =
self.role->closure(subrole)
The closure iterator supports the usual iterator syntax, so it could be
written as "closure(r : Role | r.subrole)".
I should apologize to Chris and Ian for getting confused about the owner of
the recursive operation definition conundrum. Sorry!
I'm glad you like what we have done so far, and I definitely agree that
there is room for improvement! Any help you can offer will be most welcome
:-)
We will be starting the planning for the EMFT OCL release that lines up with
3.3 soon, so there is no plan available, yet. In the mean-time, we are
also looking at getting the Eclipse Modeling Project provisioned and how
EMFT OCL will fit into that. Feel free to suggest enhancements in
Bugzilla, to provide ideas for the next release!
Thanks,
Christian
Sven Efftinge wrote:
> Christian W. Damus schrieb:
>> BTW, have I mentioned yet that the closure iterator (non-spec) that we
>> implemented reduces your recursive getSubroles() problem to a very simple
>> expression and also avoids infinite recursion on cycles?
>
> Sounds interesting, is there a sample or any other kind of documentation
> available for this feature?
>
> Are there other interesting, non-spec features included in your
> implementation? Allthough I like most of the features EOCL 2.0 provides
> I think there is much space for improvement.
>
> What are the plans for the next version?
>
> regards,
> Sven
|
|
|
Goto Forum:
Current Time: Thu Apr 18 21:22:10 GMT 2024
Powered by FUDForum. Page generated in 0.04191 seconds |
] 
Search
Help
Register
Login
Home
