Potential type-safety issues on object parsing function in DXL
$begingroup$
I have inherited the maintenance of a DXL script (for IBM Doors).
In this, I came across various examples of stuff that make me scratch my head. Take this example:
int key = 3
print key
Running this in Doors, results in the expected output: 3.
However, in the documentation, we see that key
is also the name of a function.
Object o
for o in numberCache do {
// must cast the key command.
int i = (int key numberCache)
print i
}
While even the reference docs are full of examples declaring stuff like string key
, Item key
and so on, my concern is about safety.
What bad things I can run into, potentially, leaving the code I'm maintaining as is, knowing that it works, despite the fact it contains several functions using key
as a variable name?
For instance, I'm really worried about this function right here:
void linkFindObjects(string value, Module m, string key_name, Skip objectList)
{
Object o
string key, key2, key3
bool match1 = false
bool match2 = false
bool match = false
for o in m do {
key = probeAttr_(o, key_name)
if(key == value)
{
put (objectList, o, o)
}
}
}
My concern is that in DXL parenthesis are not mandatory: as you can see in the example, casting key(numberCache)
can be simplified in key numberCache
. When declaring the first three strings, the only thing preventing the whole code to blow up seems to be the comma. Please ignore for now the fact that the code declares a lot of unused stuff. It is as I got it.
Am I worrying too much?
Apparently, nobody is asking about DXL reviews on this site. I hope somebody will listen. Maybe I can ask a good soul to create a ibm-doors or dxl tag?
type-safety
New contributor
$endgroup$
add a comment |
$begingroup$
I have inherited the maintenance of a DXL script (for IBM Doors).
In this, I came across various examples of stuff that make me scratch my head. Take this example:
int key = 3
print key
Running this in Doors, results in the expected output: 3.
However, in the documentation, we see that key
is also the name of a function.
Object o
for o in numberCache do {
// must cast the key command.
int i = (int key numberCache)
print i
}
While even the reference docs are full of examples declaring stuff like string key
, Item key
and so on, my concern is about safety.
What bad things I can run into, potentially, leaving the code I'm maintaining as is, knowing that it works, despite the fact it contains several functions using key
as a variable name?
For instance, I'm really worried about this function right here:
void linkFindObjects(string value, Module m, string key_name, Skip objectList)
{
Object o
string key, key2, key3
bool match1 = false
bool match2 = false
bool match = false
for o in m do {
key = probeAttr_(o, key_name)
if(key == value)
{
put (objectList, o, o)
}
}
}
My concern is that in DXL parenthesis are not mandatory: as you can see in the example, casting key(numberCache)
can be simplified in key numberCache
. When declaring the first three strings, the only thing preventing the whole code to blow up seems to be the comma. Please ignore for now the fact that the code declares a lot of unused stuff. It is as I got it.
Am I worrying too much?
Apparently, nobody is asking about DXL reviews on this site. I hope somebody will listen. Maybe I can ask a good soul to create a ibm-doors or dxl tag?
type-safety
New contributor
$endgroup$
$begingroup$
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
$endgroup$
– Toby Speight
43 mins ago
add a comment |
$begingroup$
I have inherited the maintenance of a DXL script (for IBM Doors).
In this, I came across various examples of stuff that make me scratch my head. Take this example:
int key = 3
print key
Running this in Doors, results in the expected output: 3.
However, in the documentation, we see that key
is also the name of a function.
Object o
for o in numberCache do {
// must cast the key command.
int i = (int key numberCache)
print i
}
While even the reference docs are full of examples declaring stuff like string key
, Item key
and so on, my concern is about safety.
What bad things I can run into, potentially, leaving the code I'm maintaining as is, knowing that it works, despite the fact it contains several functions using key
as a variable name?
For instance, I'm really worried about this function right here:
void linkFindObjects(string value, Module m, string key_name, Skip objectList)
{
Object o
string key, key2, key3
bool match1 = false
bool match2 = false
bool match = false
for o in m do {
key = probeAttr_(o, key_name)
if(key == value)
{
put (objectList, o, o)
}
}
}
My concern is that in DXL parenthesis are not mandatory: as you can see in the example, casting key(numberCache)
can be simplified in key numberCache
. When declaring the first three strings, the only thing preventing the whole code to blow up seems to be the comma. Please ignore for now the fact that the code declares a lot of unused stuff. It is as I got it.
Am I worrying too much?
Apparently, nobody is asking about DXL reviews on this site. I hope somebody will listen. Maybe I can ask a good soul to create a ibm-doors or dxl tag?
type-safety
New contributor
$endgroup$
I have inherited the maintenance of a DXL script (for IBM Doors).
In this, I came across various examples of stuff that make me scratch my head. Take this example:
int key = 3
print key
Running this in Doors, results in the expected output: 3.
However, in the documentation, we see that key
is also the name of a function.
Object o
for o in numberCache do {
// must cast the key command.
int i = (int key numberCache)
print i
}
While even the reference docs are full of examples declaring stuff like string key
, Item key
and so on, my concern is about safety.
What bad things I can run into, potentially, leaving the code I'm maintaining as is, knowing that it works, despite the fact it contains several functions using key
as a variable name?
For instance, I'm really worried about this function right here:
void linkFindObjects(string value, Module m, string key_name, Skip objectList)
{
Object o
string key, key2, key3
bool match1 = false
bool match2 = false
bool match = false
for o in m do {
key = probeAttr_(o, key_name)
if(key == value)
{
put (objectList, o, o)
}
}
}
My concern is that in DXL parenthesis are not mandatory: as you can see in the example, casting key(numberCache)
can be simplified in key numberCache
. When declaring the first three strings, the only thing preventing the whole code to blow up seems to be the comma. Please ignore for now the fact that the code declares a lot of unused stuff. It is as I got it.
Am I worrying too much?
Apparently, nobody is asking about DXL reviews on this site. I hope somebody will listen. Maybe I can ask a good soul to create a ibm-doors or dxl tag?
type-safety
type-safety
New contributor
New contributor
edited 9 mins ago
Daemon Painter
New contributor
asked 52 mins ago
Daemon PainterDaemon Painter
12
12
New contributor
New contributor
$begingroup$
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
$endgroup$
– Toby Speight
43 mins ago
add a comment |
$begingroup$
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
$endgroup$
– Toby Speight
43 mins ago
$begingroup$
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
$endgroup$
– Toby Speight
43 mins ago
$begingroup$
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
$endgroup$
– Toby Speight
43 mins ago
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Daemon Painter is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211604%2fpotential-type-safety-issues-on-object-parsing-function-in-dxl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Daemon Painter is a new contributor. Be nice, and check out our Code of Conduct.
Daemon Painter is a new contributor. Be nice, and check out our Code of Conduct.
Daemon Painter is a new contributor. Be nice, and check out our Code of Conduct.
Daemon Painter is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211604%2fpotential-type-safety-issues-on-object-parsing-function-in-dxl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
Welcome to Code Review! The current question title, which states your concerns about the code, is too general to be useful here. Please edit to the site standard, which is for the title to simply state the task accomplished by the code. Please see How to get the best value out of Code Review: Asking Questions for guidance on writing good question titles.
$endgroup$
– Toby Speight
43 mins ago