Home » Modeling » OCL » About toUpper and toLower non-standard String operations
| About toUpper and toLower non-standard String operations [message #54211] |
Wed, 23 April 2008 11:18  |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Including ValidationVisitor to the QVToParser a new warning appeared in
my test cases:
Validator-WARNING in operationCallExp; Encapsulation.qvto:30 : Usage of
non-standard "String::toUpper()" operation
Which made me realize that oclstdlib.ecore defines the toUpper (and
toLower) operation, which is referred by operationCallExps. QVTo defines
a standard toUpper (and toLower) operation, for Strings, which should be
referred instead, when using the QVTo parser.
Maybe, a bugzilla enhancement feature could be arisen, so via
ParsingOption mechanisms, the oclstdlid toUpper and toLower could be
excluded from the string oclOperations during the parsing...
I don't if there are more non-standard operations for the implemented
ocl standard library. In that case, they could be excluded as well.
Regards,
Adolfo.
|
|
|
| Re: About toUpper and toLower non-standard String operations [message #54285 is a reply to message #54211] |
Wed, 23 April 2008 18:25  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Adolfo,
There is the closure() iterator, also, that is non-standard.
If QVTo defines its own String type, would operation look-ups not be
redirected to that? I don't understand why the OCL stdlib representation
is in the picture ...
Cheers,
Christian
Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
>
> Including ValidationVisitor to the QVToParser a new warning appeared in
> my test cases:
>
> Validator-WARNING in operationCallExp; Encapsulation.qvto:30 : Usage of
> non-standard "String::toUpper()" operation
>
> Which made me realize that oclstdlib.ecore defines the toUpper (and
> toLower) operation, which is referred by operationCallExps. QVTo defines
> a standard toUpper (and toLower) operation, for Strings, which should be
> referred instead, when using the QVTo parser.
>
> Maybe, a bugzilla enhancement feature could be arisen, so via
> ParsingOption mechanisms, the oclstdlid toUpper and toLower could be
> excluded from the string oclOperations during the parsing...
>
> I don't if there are more non-standard operations for the implemented
> ocl standard library. In that case, they could be excluded as well.
>
> Regards,
> Adolfo.
|
|
|
| Re: About toUpper and toLower non-standard String operations [message #54366 is a reply to message #54285] |
Thu, 24 April 2008 09:45 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Some comments in-line below
Christian W. Damus escribió:
> Hi, Adolfo,
>
> There is the closure() iterator, also, that is non-standard.
Ok, it could be excluded as well. Although I don't need to exclude this
one, since it doesn't appear in my stdlib oeprations...So I'm not sure
if this exluding should be more "fine-grained" or just exclude all the
non-standard ops.
The option could be called EXCLUDE_NON_STANDARD_STD_LIB_OPERATIONS
>
> If QVTo defines its own String type, would operation look-ups not be
> redirected to that? I don't understand why the OCL stdlib representation
> is in the picture ...
Well, the never-ending history with the QVTo Std Lib....you know ;P
(How many times have I read that section -> Who knows ;) )
AFAIU the QVTo stdlib (at this moment), QVTo doesn't define its own
String type. The only M1 types which "says" that it defines are Object,
Element, Transformation, Model, Status, and Exception (sect 8.3.1).
Probably some more related to the new metatypes (ListType and DictType).
The new additions for OCL String (Primitive Type) will be new operations
which will be enclosed as a ImperativeOCL::Typedef instance (sect
8.2.2.24).
So the type for Strings in QVTo programs, will be the oclstdlib String
Primitive Type. The concat operation for them will be the oclstdlib
String_Class.concat() operation. However the toUpper operation (a qvto
addition for them) will be the qvtostdlib String Typedef.toUpper()
operation.
Fortunately, with this approach not to much changes to OCL project will
needed. I'll send you the definitive (I hope so ;P) patch with this
approach.
I think that the qvto stdlib (a model which conforms to QVTo Metamodel)
which I have implemented is very closer to the actual specification.
However I suppose that Borland will have a different one. So it's a
clear example that the specification needs to be clearer saying what the
qvto std lib, looks like.
Perhaps Radek, Sergey o Alex would like to add their point of view to
this interesting debate ;)
Cheers,
Adolfo.
>
> Cheers,
>
> Christian
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>
>> Hi Christian,
>>
>> Including ValidationVisitor to the QVToParser a new warning appeared in
>> my test cases:
>>
>> Validator-WARNING in operationCallExp; Encapsulation.qvto:30 : Usage of
>> non-standard "String::toUpper()" operation
>>
>> Which made me realize that oclstdlib.ecore defines the toUpper (and
>> toLower) operation, which is referred by operationCallExps. QVTo defines
>> a standard toUpper (and toLower) operation, for Strings, which should be
>> referred instead, when using the QVTo parser.
>>
>> Maybe, a bugzilla enhancement feature could be arisen, so via
>> ParsingOption mechanisms, the oclstdlid toUpper and toLower could be
>> excluded from the string oclOperations during the parsing...
>>
>> I don't if there are more non-standard operations for the implemented
>> ocl standard library. In that case, they could be excluded as well.
>>
>> Regards,
>> Adolfo.
>
|
|
|
| Re: About toUpper and toLower non-standard String operations [message #54393 is a reply to message #54366] |
Fri, 25 April 2008 00:13 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Adolfo,
I would also appreciate if there was an easy way to disable non-std OCL
usage.
Since some users may want to use handy non-std OCL,
(at their own risk ;-)), I would like to expose these in QVTo too.
Perhaps, an option like NON_STANDARD_STD_LIB_OPERATIONS of severity type
would
be flexible enough in this case.
If not set, non-std features would not be resolved at all,
while if set OK, all is allowed.
Otherwise problems - WARN, ERROR, ... would be reported.
Thus we would not need to keep track of individual non-std additions and
disable/enable them separately.
What do you think Christian? ;-)
As for our QVTo stdlib, we do not use TypeDef yet, but define contextual
operations on the
primitive types, which are owned by the library module.
What I find a bit impractical about Typedef is that there is no concrete
syntax for defining operations there.
IMO, it would be reasonable, if QVT stdlib is not different from any other
QVT library, once it has
to conform the Abstract syntax metamodel.
Regards,
/Radek
On Thu, 24 Apr 2008 11:45:24 +0200, Adolfo Sánchez-Barbudo Herrera
<adolfosbh@opencanarias.com> wrote:
> Hi Christian,
>
> Some comments in-line below
> Christian W. Damus escribió:
>> Hi, Adolfo,
>> There is the closure() iterator, also, that is non-standard.
>
> Ok, it could be excluded as well. Although I don't need to exclude this
> one, since it doesn't appear in my stdlib oeprations...So I'm not sure
> if this exluding should be more "fine-grained" or just exclude all the
> non-standard ops.
>
> The option could be called EXCLUDE_NON_STANDARD_STD_LIB_OPERATIONS
>> If QVTo defines its own String type, would operation look-ups not be
>> redirected to that? I don't understand why the OCL stdlib
>> representation
>> is in the picture ...
>
> Well, the never-ending history with the QVTo Std Lib....you know ;P
> (How many times have I read that section -> Who knows ;) )
>
> AFAIU the QVTo stdlib (at this moment), QVTo doesn't define its own
> String type. The only M1 types which "says" that it defines are Object,
> Element, Transformation, Model, Status, and Exception (sect 8.3.1).
> Probably some more related to the new metatypes (ListType and DictType).
>
> The new additions for OCL String (Primitive Type) will be new operations
> which will be enclosed as a ImperativeOCL::Typedef instance (sect
> 8.2.2.24).
>
> So the type for Strings in QVTo programs, will be the oclstdlib String
> Primitive Type. The concat operation for them will be the oclstdlib
> String_Class.concat() operation. However the toUpper operation (a qvto
> addition for them) will be the qvtostdlib String Typedef.toUpper()
> operation.
>
> Fortunately, with this approach not to much changes to OCL project will
> needed. I'll send you the definitive (I hope so ;P) patch with this
> approach.
>
> I think that the qvto stdlib (a model which conforms to QVTo Metamodel)
> which I have implemented is very closer to the actual specification.
> However I suppose that Borland will have a different one. So it's a
> clear example that the specification needs to be clearer saying what the
> qvto std lib, looks like.
>
> Perhaps Radek, Sergey o Alex would like to add their point of view to
> this interesting debate ;)
>
> Cheers,
> Adolfo.
>
>> Cheers,
>> Christian
>> Adolfo Sánchez-Barbudo Herrera wrote:
>>
>>> Hi Christian,
>>>
>>> Including ValidationVisitor to the QVToParser a new warning appeared in
>>> my test cases:
>>>
>>> Validator-WARNING in operationCallExp; Encapsulation.qvto:30 : Usage of
>>> non-standard "String::toUpper()" operation
>>>
>>> Which made me realize that oclstdlib.ecore defines the toUpper (and
>>> toLower) operation, which is referred by operationCallExps. QVTo
>>> defines
>>> a standard toUpper (and toLower) operation, for Strings, which should
>>> be
>>> referred instead, when using the QVTo parser.
>>>
>>> Maybe, a bugzilla enhancement feature could be arisen, so via
>>> ParsingOption mechanisms, the oclstdlid toUpper and toLower could be
>>> excluded from the string oclOperations during the parsing...
>>>
>>> I don't if there are more non-standard operations for the implemented
>>> ocl standard library. In that case, they could be excluded as well.
>>>
>>> Regards,
>>> Adolfo.
>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: About toUpper and toLower non-standard String operations [message #54421 is a reply to message #54393] |
Fri, 25 April 2008 00:33 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.eggs.zeligsoft.com
Hi,
If both Adolfo *and* Radek want a one-shot option, then so it shall be!
Seriously, though, this sounds like a good idea. Have you raised
anenhancement request, yet?
Cheers,
Christian
On Thursday 04-24-2008 (08:13), Radek Dvorak wrote:
> Hi Adolfo,
> I would also appreciate if there was an easy way to disable non-std
> OCL usage.
> Since some users may want to use handy non-std OCL,
> (at their own risk ;-)), I would like to expose these in QVTo too.
> Perhaps, an option like NON_STANDARD_STD_LIB_OPERATIONS of severity
> type would
> be flexible enough in this case.
> If not set, non-std features would not be resolved at all,
> while if set OK, all is allowed.
> Otherwise problems - WARN, ERROR, ... would be reported.
> Thus we would not need to keep track of individual non-std additions
> anddisable/enable them separately.
> What do you think Christian? ;-)
> As for our QVTo stdlib, we do not use TypeDef yet, but define
> contextual operations on the
> primitive types, which are owned by the library module.
> What I find a bit impractical about Typedef is that there is no
> concrete syntax for defining operations there.
> IMO, it would be reasonable, if QVT stdlib is not different from any
> other QVT library, once it has
> to conform the Abstract syntax metamodel.
> Regards,
> /Radek
> On Thu, 24 Apr 2008 11:45:24 +0200, Adolfo Sánchez-Barbudo Herrera
> <adolfosbh@opencanarias.com> wrote:
>> Hi Christian,
>> Some comments in-line below
>> Christian W. Damus escribió:
>>> Hi, Adolfo,
>>> There is the closure() iterator, also, that is non-standard.
>> Ok, it could be excluded as well. Although I don't need to exclude
>> this one, since it doesn't appear in my stdlib oeprations...So I'm
>> not sure if this exluding should be more "fine-grained" or just
>> exclude all the non-standard ops.
>> The option could be called EXCLUDE_NON_STANDARD_STD_LIB_OPERATIONS
>>> If QVTo defines its own String type, would operation look-ups
>>> not be redirected to that? I don't understand why the OCL stdlib
>>> representation
>>> is in the picture ...
>> Well, the never-ending history with the QVTo Std Lib....you know
>> ;P (How many times have I read that section -> Who knows ;) )
>> AFAIU the QVTo stdlib (at this moment), QVTo doesn't define its
>> own String type. The only M1 types which "says" that it defines
>> are Object, Element, Transformation, Model, Status, and Exception
>> (sect 8.3.1). Probably some more related to the new metatypes
>> (ListType and DictType).
>> The new additions for OCL String (Primitive Type) will be new
>> operations which will be enclosed as a ImperativeOCL::Typedef
>> instance (sect 8.2.2.24).
>> So the type for Strings in QVTo programs, will be the oclstdlib
>> String Primitive Type. The concat operation for them will be the
>> oclstdlib String_Class.concat() operation. However the toUpper
>> operation (a qvto addition for them) will be the qvtostdlib
>> String Typedef.toUpper() operation.
>> Fortunately, with this approach not to much changes to OCL project
>> will needed. I'll send you the definitive (I hope so ;P) patch
>> with this approach.
>> I think that the qvto stdlib (a model which conforms to QVTo
>> Metamodel) which I have implemented is very closer to the actual
>> specification. However I suppose that Borland will have a
>> different one. So it's a clear example that the specification
>> needs to be clearer saying what the qvto std lib, looks like.
>> Perhaps Radek, Sergey o Alex would like to add their point of view
>> to this interesting debate ;)
>> Cheers,
>> Adolfo.
>>> Cheers,
>>> Christian
>>> Adolfo Sánchez-Barbudo Herrera wrote:
>>>> Hi Christian,
>>>> Including ValidationVisitor to the QVToParser a new warning
>>>> appeared in my test cases:
>>>> Validator-WARNING in operationCallExp; Encapsulation.qvto:30 :
>>>> Usage of non-standard "String::toUpper()" operation
>>>> Which made me realize that oclstdlib.ecore defines the toUpper
>>>> (and toLower) operation, which is referred by operationCallExps.
>>>> QVTo defines
>>>> a standard toUpper (and toLower) operation, for Strings, which
>>>> should be
>>>> referred instead, when using the QVTo parser.
>>>> Maybe, a bugzilla enhancement feature could be arisen, so via
>>>> ParsingOption mechanisms, the oclstdlid toUpper and toLower could
>>>> be excluded from the string oclOperations during the parsing...
>>>> I don't if there are more non-standard operations for the
>>>> implemented ocl standard library. In that case, they could be
>>>> excluded as well.
>>>> Regards,
>>>> Adolfo.
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
| |
| Re: About toUpper and toLower non-standard String operations [message #54475 is a reply to message #54393] |
Fri, 25 April 2008 09:22 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Radek Dvorak escribió:
> Hi Adolfo,
>
> I would also appreciate if there was an easy way to disable non-std OCL
> usage.
> Since some users may want to use handy non-std OCL,
> (at their own risk ;-)), I would like to expose these in QVTo too.
> Perhaps, an option like NON_STANDARD_STD_LIB_OPERATIONS of severity type
> would
> be flexible enough in this case.
> If not set, non-std features would not be resolved at all,
> while if set OK, all is allowed.
> Otherwise problems - WARN, ERROR, ... would be reported.
>
> Thus we would not need to keep track of individual non-std additions and
> disable/enable them separately.
>
> What do you think Christian? ;-)
From OCL point of view (its non-standard operations), I suspect that
the default behaviour (not setting any option) will be including the
non-standard operations, so previous ocl-code which include that
operations doesn't notice about this new option. I suppose that you
would like this as well, (if you are offering non-standard operations).
>
>
> As for our QVTo stdlib, we do not use TypeDef yet, but define contextual
> operations on the
> primitive types, which are owned by the library module.
I see....that approach makes much more sense than creating a new type
(typedef) for that purpose (adding new operations to the predefined ocl
types). In fact, I don't understand the typedef as aliases, because if
you are not adding any semantic restriction to that type, why are you
creating a new one?. What kind of sense makes having two "semantically
identical" types ?. I have had to make some kinf of tricks or
considerations when resolving the typdefs...
It seems that using helpers and/or querys for that kind of additions is
more sensible. The only inconvenience which I could oversee is that you
will have a lot operations in the library. Using typedefs they are more
organized.
Have you considered suggesting that approach in the OMG - qvt-rtf issues ?
>
> What I find a bit impractical about Typedef is that there is no concrete
> syntax for defining operations there.
> IMO, it would be reasonable, if QVT stdlib is not different from any
> other QVT library, once it has
> to conform the Abstract syntax metamodel.
From my point of view, if the concrete syntax allows you that or
doesn't allow it, should not worry us. In fact, in this case, it
facilitates our labour :D. QVTo stdlib will conform to the QVTo
Metametamodel, independently the concrete syntax allows us creating it
or not... I don't know if you see what I mean ;).
You have another clear example with the TemplateParameterType which I
guess you have not include it in the Std Lib at all , but it's exclusive
of the QVTo Standar Library. It's a bit shocking when you deal with it ¬¬!!
Regards,
Adolfo.
>
> Regards,
> /Radek
>
>
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:42:42 GMT 2024
Powered by FUDForum. Page generated in 0.03457 seconds |
] 
Search
Help
Register
Login
Home
