Re: [incquery-dev] default string representation for null label features

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

I have looked into the code, and found that we are implicitly calling a toString() on the value of the calculated observable feature in ObservableLabelFeature#calculate(), line 84.

The null behaviour seems to me more like a side-effect/corner case than a planned feature (and I was who implemented it this way), so unless there is some kind of clear objection, I suggest simply placing a null-check to the mentioned place to avoid this implicit conversion.

Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2014.01.20., at 16:51, Ábel Hegedüs <abel.hegedus@xxxxxxxxxx> wrote:

> Hi all!
> 
> In the current version, if you create a label (or databinding format string) like "$A.name$" and the value of name for the match parameter A is null, then the string representation will be "null".
> 
> While this does offer a distinction between null value and empty string, it creates another collision with the "null" string. When used in Viewers, it seems that using empty string for null values (or null strings at least) would be more convinient than the "null" value.
> 
> What do you think? I have added the question as a topic for the next meeting.
> 
> Cheers,
>   Ábel Hegedüs
> 
> Fault Tolerant Systems Research Group (FTSRG)
> Department of Measurement and Information Systems (MIT)
> Budapest University of Technology and Economics (BME)
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/incquery-dev