Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: Paolo F Cantoni on May 10, 2016, 05:13:08 pm
-
The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists. Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."
Perversely, HasTag(tagname,””) will fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."
Reported,
Paolo
-
As long as Sparx will proudly clinch to their own "language" inventions (namely shape script and code generation) rather than adopting a commonly used language, we need to get used to those anomalies. So likely forever :(
q.
-
The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists. Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."
To be a pedant it doesn't exist if it is null, the only thing that exists is a descriptor. Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.
Perversely, HasTag(tagname,””) will fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."
Obviously does null equal null will evaluate as true. See previous point about null.
-
The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists. Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."
To be a pedant it doesn't exist if it is null, the only thing that exists is a descriptor. Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.
Perversely, HasTag(tagname,””) will fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."
Obviously does null equal null will evaluate as true. See previous point about null.
Let's hear it for Pedantry!
I absolutely agree on NULL.
However, given the definition of NULL (that is, NOT being a value), one can't use equality with null, one can only use IsNull().
Further, it IS the case that a Tagged Value consists of two parts: The Value (the primary concept) and the Tag (Descriptor/Identifier). The problem is that the Tag can exist in EA without a Value. This would appear to be a conceptual defect.
One should not be allowed to create a tagged value without supplying and maintaining a value. Then the documentation can specify:
HasTag(tagname) will evaluate to true if the Tagged Value tagname exists (regardless of the assigned value).
HasTag(tagname, tagvalue) will evaluate to true if the value of the tagname is tagvalue.
Now it works.
If EA insists on allowing tags with empty/null values, then the documentation needs to be adjusted and the code updated since the tag can exist without the value (and so, I guess, isn't a tagged value ;))
Paolo
-
One should not be allowed to create a tagged value without supplying and maintaining a value. Then the documentation can specify:
HasTag(tagname) will evaluate to true if the Tagged Value tagname exists (regardless of the assigned value).
HasTag(tagname, tagvalue) will evaluate to true if the value of the tagname is tagvalue.
I agree. It should be a zero-length string, which is different from null (apparently not in older versions of Oracle tho).
-
One should not be allowed to create a tagged value without supplying and maintaining a value. Then the documentation can specify:
HasTag(tagname) will evaluate to true if the Tagged Value tagname exists (regardless of the assigned value).
HasTag(tagname, tagvalue) will evaluate to true if the value of the tagname is tagvalue.
I agree. It should be a zero-length string, which is different from null (apparently not in older versions of Oracle tho).
Ah...
I didn't mean that an empty (zero length) string was a value. It's another extrinsic and should be tested with IsEmpty() - I will allow ,however, that ="" is the equivalent of IsEmpty(). However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».
-
However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».
I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.
At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.
Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.
I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.
-
However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».
I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.
At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.
Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.
I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.
You're allowed to be wrong... ;D
Seriously though, it DOES revolve around how language works...
Is an Empty string a Value - pretty clearly not. If it is, then how?
In the term "Tagged Value", the word "Tagged" is an adjective qualifying the noun "Value". Consequently we are talking about Values not Tags (the potential container). A Value cannot hold a non-Value. Since Empty is a non-value, it can't be meaningfully held by a "Tagged Value". If you wanted to allow Tags to hold empty strings (which might well be useful), then they should be called Tags not Tagged Values. A Tag IS NOT a Tagged Value! As you say, it is a container for a Tagged Value.
In the words of GBS "Madam, we've established what you are, we're just arguing the price..."
We allow the use of Null and Empty in situations where we cannot control input to the requisite degree to maintain conceptual consistency. For example: A mandatory attribute that allows null or empty IS, by definition, an optional attribute. We should not confuse the practical necessities with the correct conceptualisation.
-
Paolo,
I'm not interested in arguing about the theoretical concepts, but from a practical standpoint I would not like to see my empty tagged values be purged by EA.
The fact that we define a set of tagged values on a stereotype allows us to control what metadata a user can/must fill in on that particular type of element.
Purging the empty tagged values would make that impossible as the user wouldn't see them anymore.
So let's leave the tagged values handling in EA as it is now, and maybe only fix the shapescript issue at hand.
Geert
-
However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».
I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.
At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.
The analogy is the Axiom of the empty set (https://en.wikipedia.org/wiki/Axiom_of_empty_set).
Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.
I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.
The article that first brought it to my attention is here (https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/), but if you google there's plenty of discussion of it.
-
Paolo,
I'm not interested in arguing about the theoretical concepts, but from a practical standpoint I would not like to see my empty tagged values be purged by EA.
The fact that we define a set of tagged values on a stereotype allows us to control what metadata a user can/must fill in on that particular type of element.
Purging the empty tagged values would make that impossible as the user wouldn't see them anymore.
So let's leave the tagged values handling in EA as it is now, and maybe only fix the shapescript issue at hand.
Geert
Geert,
There is actually, a practical result of my (theoretical) argument... You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones? As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.
Unfortunately, in the current MDG definition, you can ONLY define mandatory Tagged Values! If, however, you allowed the (theoretically) correct ability to define optional Tagged Values in the MDG, then if they were defined for a metatype at the MDG level, they could be displayed in the Tagged Value Window - just as at present - but with rendering to indicate the value wasn't (yet) present. They would NOT be created in the model until a value was supplied. It would improve the rigour of the model, as well as saving unneeded space.
Your (and my) practical response to the current theoretically incorrect implementation - I believe, just goes to prove my point. ;) As I mentioned, I also use non-metatype related Tagged Values (that is, NOT specified in the MDG against the metatype) to get around the problem.
Paolo
-
There is actually, a practical result of my (theoretical) argument... You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones? As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.
No it isn't. An empty value conveys meaning in exactly same way as a non-empty value. At a very crude level it says the information does not exist or is not known. That information helps us evaluate the completeness of what we are modeling.
The descriptor existing but not the value only says that tagged values were poorly implemented.
-
There is actually, a practical result of my (theoretical) argument... You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones? As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.
No it isn't. An empty value conveys meaning in exactly same way as a non-empty value. At a very crude level it says the information does not exist or is not known. That information helps us evaluate the completeness of what we are modeling.
The descriptor existing but not the value only says that tagged values were poorly implemented.
Depends on the semantics you apply to the two extrinsics: Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown». You can't tell which is meant and certainly you can't assign both meanings to the one non-value.
As you may know, I'm a great supporter of extrinsics but they can't be universally applied. This being a case in point. In this case, if the Tagged Value has no value, it conceptually doesn't exist (I think we're agreed on that). I don't think any other interpretation is allowed. What the non-existence of the Tagged Value means for the Element depends on the nature of the Element. If I want the Tagged Value to communicate extrinsic concepts (about the property that the Tagged Value is representing), then the value domain of the Tagged Value is separated into intrinsic and extrinsic values. Null or Empty are NOT permitted.
We can agree that TVs are poorly implemented. :(
Paolo
-
Depends on the semantics you apply to the two extrinsics: Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown». You can't tell which is meant and certainly you can't assign both meanings to the one non-value.
This is where I disagree I think both «Missing» and «Unknown» are part of your test for completeness, and in practical terms missing equals unknown anyway. It's just slightly more nuanced.
-
Depends on the semantics you apply to the two extrinsics: Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown». You can't tell which is meant and certainly you can't assign both meanings to the one non-value.
This is where I disagree I think both «Missing» and «Unknown» are part of your test for completeness, and in practical terms missing equals unknown anyway. It's just slightly more nuanced.
Whoops! As per Helsinki, I should have defined my terms:
«Empty», «Missing», «Not present» There should be a value, but none was provided
«Unknown» There is a value but we don't know what it is
«None», «No one», «Nothing» There is NO Value
«Not applicable» NO value can be applied
are just some of the standard extrinsic definitions I use.
The difference between «Nothing» and «Unknown» is what got me started on the "Extrinsics Lark" in the late 70s after Reading J.R.Abrial's "Data Semantics". It is used to distinguish: " I know you nave no spouse"; from: "I know you have a spouse, but I don't know who they are".
Anyway, we can agree to disagree. :D
Paolo
-
In terms of the practical purpose of this thread as a discussion of if EA should be changed.
Both forms of HasTag behave as if they are evaluating based on a single call to get the value. As a result:
HasTag(tagname) gives a result that doesn't match the function name when an empty tag is present
HasTag(tagname, tagvalue) gives a result that doesn't match the function name when no tag is present and checking for an empty value
Unfortunately, changing the behavior of either of these cases would almost certainly break existing shape scripts out there in user land. I'm not willing to do that. The documentation will have to be updated to clarify the behavior and there will have to a be a separate solution to your requirement of distinguishing between an empty value and a missing tag.
Additionally, don't expect to see any change to purge tagged values that are empty. There are too many users that depend on the way it currently works. Not just in the UI, but in documentation, API and export functions.
For the conceptual topic that is diverging further and further from being useful...
Whoops! As per Helsinki, I should have defined my terms:
«Empty», «Missing», «Not present» There should be a value, but none was provided
«Unknown» There is a value but we don't know what it is
«None», «No one», «Nothing» There is NO Value
«Not applicable» NO value can be applied
are just some of the standard extrinsic definitions I use.
Useful categories in theory. Like you, I could add additional categories. Where I disagree with you is the inclusion of «Empty» into no value was provided. I would define a string as a sequence of zero or more characters. Similar to sets, I consider empty to be a useful value in its own right. Empty may not be permitted in your model, but the appropriate place to specify that is in a constraint, not the definition of what a (string) value is. As an example, I define a function that removes all instances of a single character from a string. Logically it has to result in a string. If the string only contained the specified character there's certainly a value there. As far as I'm concerned it's still a string.
How does that impact EA?
For string tagged values, the only category that can be stored against a tag in EA is the empty string. As I said, in my opinion this is distinct from a null value and still useful. The only way to represent a none or missing value is to delete the tag. In addition to shape scripts, reporting, code generation and csv exports that request the value of a tag by name will be unable to distinguish between these two states. For that reason I would no recommend placing too much significance on the that difference.
For other tagged values (eg. Boolean, enumeration, Dates) the situation is slightly different because unless otherwise specified the default will still be represented by an empty string. For those types there is a missing or none state, but often the UI doesn't allow you to go back to it after it gets a value.
-
In terms of the practical purpose of this thread as a discussion of if EA should be changed.
Both forms of HasTag behave as if they are evaluating based on a single call to get the value. As a result:
HasTag(tagname) gives a result that doesn't match the function name when an empty tag is present
HasTag(tagname, tagvalue) gives a result that doesn't match the function name when no tag is present and checking for an empty value
Unfortunately, changing the behavior of either of these cases would almost certainly break existing shape scripts out there in user land. I'm not willing to do that. The documentation will have to be updated to clarify the behavior and there will have to a be a separate solution to your requirement of distinguishing between an empty value and a missing tag.
You somewhat seem to address your own point. Introduce a new properly named function call that returns results for all possible conditions. Deprecate the old function calls.
-
You somewhat seem to address your own point. Introduce a new properly named function call that returns results for all possible conditions. Deprecate the old function calls.
+1, and noting the previous link to the billion$ mistake, don't introduce any new 'null' values.
-
Actually, I intentionally didn't describe what any alternate solution might be.
For the record:
- The referenced article about null never implies that null isn't necessary.
- It just proposes wrapping it in a type called Optional.
- From my point of view a C/C++ pointer is effectively that construct.
- All Java objects are optional (but the primitives aren't).
- Null doesn't have to be considered breaking a type system because it's an overloaded constant.
- The "double null" described for javascript undefined constant seems to be a total misconception. I'd prefer that over the default C/C++ behavior of there's no way to check for that situation.
- Apart from that, it's just about rigorous programming practices. (Which avoiding the presence of null in a language would force)
-
The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists. Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."
Perversely, HasTag(tagname,””) will fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."
Reported,
Paolo
After all that, are we agreed that the above implementation is WRONG and needs to be fixed...
HasTag (from its name) is a function that deals with Tags, with or without an applied value. So HasTag cannot return true (in either form) if the tag doesn't exist.
I'll leave it at that.
Without some sort of extrinsic(s) or pattern matching syntax, I don't think one can check for:
Null/Empty only tag; any non-empty value; specific non-empty value(s). With the currently available function syntax.
-
After all that, are we agreed that the above implementation is WRONG and needs to be fixed...
HasTag (from its name) is a function that deals with Tags, with or without an applied value. So HasTag cannot return true (in either form) if the tag doesn't exist.
You seem very selective on what you read. The conclusion was that changing either HasTag function could negatively impact existing scripts and therefore a new function would be required to detect the situations you described.
-
After all that, are we agreed that the above implementation is WRONG and needs to be fixed...
HasTag (from its name) is a function that deals with Tags, with or without an applied value. So HasTag cannot return true (in either form) if the tag doesn't exist.
You seem very selective on what you read. The conclusion was that changing either HasTag function could negatively impact existing scripts and therefore a new function would be required to detect the situations you described.
How can fixing HasTag(tagname, value) to NOT return true if the tag doesn't exist (not the value, the tag) adversely affect existing shapescripts? It's a bug, !
Paolo
-
It's a bug, !
I feel the forum needs some form of voting functionality so we can sweepstakes on what decade your pop culture references are from :-)
-
It's a bug, !
I feel the forum needs some form of voting functionality so we can sweepstakes on what decade your pop culture references are from :-)
Just reply with your guesses... ;D The first right answer...
is the first right answer. 8)
It's not a sweepstakes, it's a quiz... :P
Paolo
-
I would have thought its a bug 'Grace' to be closer to the
etymology entomology.
Of course this could be a West Island colloquiality (see http://www.kevinservices.com.au/bed-bug-treatments/)
-
With the current behavior of HasTag, a technology developer can use either version of the function to determine if it should use that value or another value.
shape main
{
rectangle(0,0,100,100);
if(HasTag("NameOverride"))
{
println("#TAG:NameOverride#");
}
else
{
println("#name#");
}
if(HasTag("NameOverride", ""))
{
println("#name#");
}
else
{
println("#TAG:NameOverride#");
}
}
I consider this usage in user profiles not only possible, but likely. Therefore, the behavior of those functions can't be changed.
-
With the current behavior of HasTag, a technology developer can use either version of the function to determine if it should use that value or another value.
shape main
{
rectangle(0,0,100,100);
if(HasTag("NameOverride"))
{
println("#TAG:NameOverride#");
}
else
{
println("#name#");
}
if(HasTag("NameOverride", ""))
{
println("#name#");
}
else
{
println("#TAG:NameOverride#");
}
}
I consider this usage in user profiles not only possible, but likely. Therefore, the behavior of those functions can't be changed.
Not sure what you are trying to achieve with this snippet. The behaviour with an empty tag or no tag is identical. Consequently, I can't tell if the tag (again, not the value) exists or not.
I guess users don't need to know if the tag exists or not. If they do, then I guess they use the TagExists(tagname) function.
Paolo
-
My point is that existing shape scripts that we don't have control of are likely to be using HasTag and don't care about which of those scenarios it is.
To prevent changing the behavior of existing scripts we need to preserve the current behavior for HasTag, and introduce something new the check if no matching tag exists.
-
I would have thought its a bug 'Grace' to be closer to the etymology entomology.
That's what I was thinking, but the nifty pun hadn't occurred to me :-) Possibly there's a Norman Gunston boxed set we could get shipped over to help with these references.
-
My point is that existing shape scripts that we don't have control of are likely to be using HasTag and don't care about which of those scenarios it is.
To prevent changing the behavior of existing scripts we need to preserve the current behavior for HasTag, and introduce something new the check if no matching tag exists.
Yes, which the whole point of deprecation (https://en.wikipedia.org/wiki/Deprecation).
-
I would have thought its a bug 'Grace' to be closer to the etymology entomology.
That's what I was thinking, but the nifty pun hadn't occurred to me :-) Possibly there's a Norman Gunston boxed set we could get shipped over to help with these references.
While Norman is an Excellent "Little Aussie Bleeder", he's not the culprit in this case... :P :-X
Paolo