And yet another Ruby question

[Doug_N]

If I add a conversion unit via the Preferences DBX can I use that unit in Ruby somehow?

 

For example, I have set acre to be 43570 sq ft, and Ha to be 10000 sq m.  

 

I can set 10 to sq ft by %10.to_sq_ft% but not %10.to_Ha% nor %10.to_acre%

 

Is there a way to set that up?

[Chopsaw]

Let me know if this works for you:

 

 

[Doug_N]

22 minutes ago, Chopsaw said:

Let me know if this works for you:

 

 

Like a charm, thanks for the link.    You know, after reading the dialog in that post, I can't see way CA wouldn't allow "area.to_acre".  Let's assume that I make a mistake with the unit conversion.  

 

If %area.to_acre% produces an erroneous result so would %area.to_s("acre")%  Same output, with a lot less typing.  

CA lets users put in their own conversion factors, as I have done for Ha, hectare and acre.  What is the risk to CA?

[Alaskan_Son]

19 hours ago, Doug_N said:

If %area.to_acre% produces an erroneous result so would %area.to_s("acre")%  Same output, with a lot less typing.  

CA lets users put in their own conversion factors, as I have done for Ha, hectare and acre.  What is the risk to CA?

 

Read through the dialog again.  I think I pointed out pretty clearly why Chief does what they're doing.  Its not to protect against "erroneous results".  Its due to Ruby's naming conventions.  Chief will allow for a unit called "Clown Feet" but to_Clown Feet would be invalid Ruby method naming syntax.  In fact, there are plenty of OOB units that will not work using to_unit for that very reason that will work just fine using convert_to("unit").  I suppose Chief could probably write some code that would test to see if the unit's name is valid and then create a matching to_unit method but I'm guessing they just went for a one size fits all approach.  I personally don't care at all.   

[Doug_N]

4 hours ago, Alaskan_Son said:

 

Read through the dialog again.  I think I pointed out pretty clearly why Chief does what they're doing.  Its not to protect against "erroneous results".  Its due to Ruby's naming conventions.  Chief will allow for a unit called "Clown Feet" but to_Clown Feet would be invalid Ruby method naming syntax.  In fact, there are plenty of OOB units that will not work using to_unit for that very reason that will work just fine using convert_to("unit").  I suppose Chief could probably write some code that would test to see if the unit's name is valid and then create a matching to_unit method but I'm guessing they just went for a one size fits all approach.  I personally don't care at all.   

I see where you are coming from Michael.  From my point of view saving the extra typing would be worth it, as I use area analysis a lot on my projects, and most of that involves units that are not supported by value.to_unit.  Typing value.to_s("unit") just adds places where I will make a typing mistake. (I know, a typing mistake while coding?  Unheard of.)  Besides it would be great to have just one standard way of doing something.  

[Alaskan_Son]

38 minutes ago, Doug_N said:

I see where you are coming from Michael.  From my point of view saving the extra typing would be worth it, as I use area analysis a lot on my projects, and most of that involves units that are not supported by value.to_unit.  Typing value.to_s("unit") just adds places where I will make a typing mistake. (I know, a typing mistake while coding?  Unheard of.)  Besides it would be great to have just one standard way of doing something.  

 

Based on your response, I think you're typing way more than you should be.  You might consider writing a custom text macro or method that keeps you from re-typing all the time.

 

[Doug_N]

2 minutes ago, Alaskan_Son said:

 

Based on your response, I think you're typing way more than you should be.  You might consider writing a custom text macro or method that keeps you from re-typing all the time.

 

Yes I suppose I could write a series of macros for the conversions that I do the most.  Maybe I should stop whining about this ..... lol