S
Simon L. Prinsloo
Guest
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.
Continue reading...
Continue reading...