Eclipse Community Forums: EMF » Validation of default alue literals

Help

Home

Home » Modeling » EMF » Validation of default alue literals

Show: Today's Messages :: Show Polls :: Message Navigator

Validation of default alue literals [message #633376]

Sun, 17 October 2010 05:48

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi,

We've had some hard time to find an issue with one of our models. Finally we found that the default value literal for an EEnum attribute did not match any of the literals in that EEnum. The validator did not complain about that. Is that intentional or could it be "enhanced" to show up an error inthat case? Or a warning?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Validation of default alue literals [message #633424 is a reply to message #633376]

Sun, 17 October 2010 17:45

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

Eike,

This discussion sounds familiar. In general, the value of a default
will be converted using the generated factory which can have
hand-written conversion code. Perhaps in the case of known data types
(e.g., ones from generated packages in the core
EcorePackage/XMLTypePackage) we could do better always. For things like
EEnums we could assume that 99.9% of the time no one would specialize
the code. Or perhaps we should assume that in the model itself, the
literal value of the enum must be used. That certainly seems reasonable
(because right now the generator itself appears to be assuming that)...

Eike Stepper wrote:
> Hi,
>
> We've had some hard time to find an issue with one of our models.
> Finally we found that the default value literal for an EEnum attribute
> did not match any of the literals in that EEnum. The validator did not
> complain about that. Is that intentional or could it be "enhanced" to
> show up an error inthat case? Or a warning?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Validation of default alue literals [message #633448 is a reply to message #633424]

Mon, 18 October 2010 04:03

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 17.10.2010 19:45, schrieb Ed Merks:
> Eike,
>
> This discussion sounds familiar. In general, the value of a default will be converted using the generated factory which can have hand-written conversion code. Perhaps in the case of known data types (e.g., ones from generated packages in the core EcorePackage/XMLTypePackage) we could do better always. For things like EEnums we could assume that 99.9% of the time no one would specialize the code. Or perhaps we should assume that in the model itself, the literal value of the enum must be used. That certainly seems reasonable (because right now the generator itself appears to be assuming that)...
What about an annotation on attributes with "non-standard" default value literals to exclude them from validation? Or a general preference setting?

Is it okay that I file a bugzilla?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
>
> Eike Stepper wrote:
>> Hi,
>>
>> We've had some hard time to find an issue with one of our models. Finally we found that the default value literal for an EEnum attribute did not match any of the literals in that EEnum. The validator did not complain about that. Is that intentional or could it be "enhanced" to show up an error inthat case? Or a warning?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Validation of default alue literals [message #633578 is a reply to message #633448]

Mon, 18 October 2010 12:45

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

Eike,

Feel free.

Eike Stepper wrote:
> Am 17.10.2010 19:45, schrieb Ed Merks:
>> Eike,
>>
>> This discussion sounds familiar. In general, the value of a default
>> will be converted using the generated factory which can have
>> hand-written conversion code. Perhaps in the case of known data
>> types (e.g., ones from generated packages in the core
>> EcorePackage/XMLTypePackage) we could do better always. For things
>> like EEnums we could assume that 99.9% of the time no one would
>> specialize the code. Or perhaps we should assume that in the model
>> itself, the literal value of the enum must be used. That certainly
>> seems reasonable (because right now the generator itself appears to
>> be assuming that)...
> What about an annotation on attributes with "non-standard" default
> value literals to exclude them from validation? Or a general
> preference setting?
>
> Is it okay that I file a bugzilla?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>>
>> Eike Stepper wrote:
>>> Hi,
>>>
>>> We've had some hard time to find an issue with one of our models.
>>> Finally we found that the default value literal for an EEnum
>>> attribute did not match any of the literals in that EEnum. The
>>> validator did not complain about that. Is that intentional or could
>>> it be "enhanced" to show up an error inthat case? Or a warning?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Validation of default alue literals [message #651691 is a reply to message #633578]

Tue, 01 February 2011 09:55

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 18.10.2010 14:45, schrieb Ed Merks:
> Eike,
>
> Feel free.
Markus Surudo submitted https://bugs.eclipse.org/bugs/show_bug.cgi?id=335942

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
>
> Eike Stepper wrote:
>> Am 17.10.2010 19:45, schrieb Ed Merks:
>>> Eike,
>>>
>>> This discussion sounds familiar. In general, the value of a default will be converted using the generated factory which can have hand-written conversion code. Perhaps in the case of known data types (e.g., ones from generated packages in the core EcorePackage/XMLTypePackage) we could do better always. For things like EEnums we could assume that 99.9% of the time no one would specialize the code. Or perhaps we should assume that in the model itself, the literal value of the enum must be used. That certainly seems reasonable (because right now the generator itself appears to be assuming that)...
>> What about an annotation on attributes with "non-standard" default value literals to exclude them from validation? Or a general preference setting?
>>
>> Is it okay that I file a bugzilla?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>>
>>>
>>> Eike Stepper wrote:
>>>> Hi,
>>>>
>>>> We've had some hard time to find an issue with one of our models. Finally we found that the default value literal for an EEnum attribute did not match any of the literals in that EEnum. The validator did not complain about that. Is that intentional or could it be "enhanced" to show up an error inthat case? Or a warning?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://www.esc-net.de
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Previous Topic:	EMF Transaction UI/RAP
Next Topic:	cdo builds on twitter (@cdobuilds), not anymore?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 02:25:22 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter