Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / December 2007

Tip: Looking for answers? Try searching our database.

Type Safe Units of Temperature

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jeff Louie - 16 Dec 2007 07:10 GMT
Here is a type safe unit of temperature that can be used to enforce type
safety at compile time.

http://www.geocities.com/jeff_louie/OOP/oop38.htm

Regards,
Jeff
Nick - 17 Dec 2007 10:27 GMT
> Here is a type safe unit of temperature that can be used to enforce type
> safety at compile time.
>
> http://www.geocities.com/jeff_louie/OOP/oop38.htm

In terms of efficacy do you think it is better to spend additional
coding time using type safe classes such as this or do you think it
better to spend the extra time giving clear specs and coding rules and
doing more tests.

To my mind what was needed was a clear communication that all
measurements should be performed in metric.

I have worked on a few projects that have spent far to much effort
designing mechanisms to get a round project management failures.
Jeff Louie - 18 Dec 2007 03:21 GMT
Hi Nick... A type safe unit library certainly does not replace
documentation and design requirements. But "to err is human" so IMHO
system solutions are a worthy goal. C# is type safe so we are all
_currently_ coding using type safety such as double or decimal or int. I
see no extra effort necessary to code using Meter, Grams and Celsius. In
fact, coding using Meter, Grams and Celsius is self documenting and
moves us toward the goal of self documenting code.

Regards,
Jeff
Nick - 19 Dec 2007 11:31 GMT
> Hi Nick... A type safe unit library certainly does not replace
> documentation and design requirements. But "to err is human" so IMHO
[quoted text clipped - 3 lines]
> fact, coding using Meter, Grams and Celsius is self documenting and
> moves us toward the goal of self documenting code.

It definitely would be more effort to use temperature classes.

It is often much harder to understand a project which uses a number of
new Types to wrap normal more familiar type. Rather than follow the flow
of the code you need to take time out to investigate and understand the
new type. If you are putin a seat and asked to make a change to a
unknown large project the last thing you want is unnecessary complexity.

In this case it is also a bit heavy to have multiple classes why not
have one class which can be converted/from displayed as any of the other
temperature types. The four temperature types are equivalent the only
difference being the formatting and conversion from/to a double.
Redefining the FREEZE_H2O constants for each type is also a recipe for
disaster and may lead to inconsistency. A similar concept occurs with
DateTime where a locale is used to determine how UCT is displayed.

It may be that you have a project where the benefits of some kind of
type safety outweigh the drawbacks but I doubt it.

The SI unit of temperature is Kelvin I would need tremendously strong
reasons to allow anything else to be used.

> Regards,
> Jeff
>
> *** Sent via Developersdex http://www.developersdex.com ***

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.