Hi.
This fails:
USING System.IO.*.
message Path:GetRandomFileName() view-as alert-box.
with the error " ** Path is ambiguous with rtb_path.path-guid and rtb_pname.path-guid (72)"
The following works:
message System.IO.Path:GetRandomFileName() view-as alert-box.
This behavior was observed on OE 11.3.2. This seems like a bug to me.
This is a known.... Um... For me it is an issue, but Progress responded with "So what? We designed it that way."
So I logged this enhancement request: https://community.progress.com/community_groups/products_enhancements/i/openedge/do_not_allow_possible_abbreviated_table_and_field_names_to_take_priority_over_class_names.aspx
In short, Progress decided to eliminate a close to zero risk by introducing a moderate to high risk.
Long version
The rationale is that namespaces are searched in the sequence it was added to the language, so abbreviated field names takes precedence over fully named (but not fully qualified) class names. That way they can't break existing code.
That way of reasoning is plain dumb.
Pre-exiting code from pre-OO times will not have USING statements. Giving priority to a class name ABOVE an abbreviated field name can't break pre-exiting code. Risk factor? Close to zero. The exception is if someone create the classes in the root of the propath, thus having no namespace, in which case the Afrikaans saying applies: "Dom mense moet seerkry." (Dumb people must get hurt [in order to learn].)
On the other hand, take any class with a static member in your code that is used in conjunction with USING. Add a new field to any table in the DB and let the name start with the class name. (Say you have a MyCompany.SomeSystem.Data.Util.Validate() class, add a logical field called "ValidateEmail" to a control file.)
Now everything using that class, which is often a worker class, built to reduce typing and therefore intended to be used with USING, will fail to compile. Risk factor? Moderate to high.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
Flag this post as spam/abuse.
This is a known.... Um... For me it is an issue, but Progress responded with "So what? We designed it that way."
So I logged this enhancement request: https://community.progress.com/community_groups/products_enhancements/i/openedge/do_not_allow_possible_abbreviated_table_and_field_names_to_take_priority_over_class_names.aspx
In short, Progress decided to eliminate a close to zero risk by introducing a moderate to high risk.
Long version
The rationale is that namespaces are searched in the sequence it was added to the language, so abbreviated field names takes precedence over fully named (but not fully qualified) class names. That way they can't break existing code.
That way of reasoning is plain dumb.
Pre-exiting code from pre-OO times will not have USING statements. Giving priority to a class name ABOVE an abbreviated field name can't break pre-exiting code. Risk factor? Close to zero. The exception is if someone create the classes in the root of the propath, thus having no namespace, in which case the Afrikaans saying applies: "Dom mense moet seerkry." (Dumb people must get hurt [in order to learn].)
On the other hand, take any class with a static member in your code that is used in conjunction with USING. Add a new field to any table in the DB and let the name start with the class name. (Say you have a MyCompany.SomeSystem.Data.Util.Validate() class, add a logical field called "ValidateEmail" to a control file.)
Now everything using that class, which is often a worker class, built to reduce typing and therefore intended to be used with USING, will fail to compile. Risk factor? Moderate to high.
This is a known.... Um... For me it is an issue, but Progress responded with "So what? We designed it that way."
So I logged this enhancement request: https://community.progress.com/community_groups/products_enhancements/i/openedge/do_not_allow_possible_abbreviated_table_and_field_names_to_take_priority_over_class_names.aspx
In short, Progress decided to eliminate a close to zero risk by introducing a moderate to high risk.
Long version
The rationale is that namespaces are searched in the sequence it was added to the language, so abbreviated field names takes precedence over fully named (but not fully qualified) class names. That way they can't break existing code.
That way of reasoning is plain dumb.
Pre-exiting code from pre-OO times will not have USING statements. Giving priority to a class name ABOVE an abbreviated field name can't break pre-exiting code. Risk factor? Close to zero. The exception is if someone create the classes in the root of the propath, thus having no namespace, in which case the Afrikaans saying applies: "Dom mense moet seerkry." (Dumb people must get hurt [in order to learn].)
On the other hand, take any class with a static member in your code that is used in conjunction with USING. Add a new field to any table in the DB and let the name start with the class name. (Say you have a MyCompany.SomeSystem.Data.Util.Validate() class, add a logical field called "ValidateEmail" to a control file.)
Now everything using that class, which is often a worker class, built to reduce typing and therefore intended to be used with USING, will fail to compile. Risk factor? Moderate to high.
Flag this post as spam/abuse.