[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[ANN] parseargs-0.0.0

Ara.T.Howard

5/31/2005 3:06:00 PM

22 Answers

Hal E. Fulton

6/1/2005 12:23:00 AM

0

Ara.T.Howard wrote:
>
> ABOUT
>
> parseargs is a library that faciltates the parsing of arguments and
> keywords
> from method paramters, setting of default values, validation,
> contraints via
> class based or duck based typing, and coercion/convincing to
> type/ducktype
> when possible.

Interesting. I look forward to checking this out.

>
> HISTORY
>
> 0.0.0

Hmm, I think I used a prior version of it... ;)


Hal




Joel VanderWerf

6/1/2005 12:33:00 AM

0

Hal Fulton wrote:
> Ara.T.Howard wrote:
>> HISTORY
>>
>> 0.0.0
>
>
> Hmm, I think I used a prior version of it... ;)

Was that 0.0.0.0, or 0.0.0.0.0? ;)

Ruby folks are so conservative in version numbering that it wouldn't be
surprising to see negative versions... "Your library looks nice, but I'm
not going to use use it until it goes positive."


Ara.T.Howard

6/1/2005 3:04:00 AM

0

Ara.T.Howard

6/1/2005 3:16:00 AM

0

Zev Blut

6/1/2005 5:27:00 AM

0

Hello,

This looks like a nice tool!
Looking at your samples made me think about a few interesting details
about Ruby. To start the discussion, below is your posted (a.rb)
sample:

On Wed, 01 Jun 2005 00:20:25 +0900, Ara.T.Howard <Ara.T.Howard@noaa.gov>
wrote:

> def method(*a)
> pa =
> parseargs(a) {
> required_argument :a
> optional_argument :b => 2
> }
>
> puts "#{ pa.a }#{ pa.b }"
> end
>
> method 4
>
> ~ > ruby sample/a.rb
>
> 42

This looks like a fairly reasonable API, but one thing really struck
me was that your variables needed to be referenced with the pa
instance. This is understandable, but I kind of feel that if I were
to use this API a lot I would really rather have parseargs just go
ahead and set the variables in the current method's binding. Thus I
can just reference a and b without the need to use pa.

I was going to post a patch to your code, but decided it might be
better to flesh out this idea. Below is some sample code that will
display how I implemented a simple example of how you could remove the
need to reference pa.

------
def parse_data_hash(data, bd = binding)
data.each do |k,v|
vid = v.object_id
eval("#{k.to_s} = ObjectSpace._id2ref(#{vid})", bd)
end
end

def parse_test(data_hash)
parse_data_hash(data_hash)
puts local_variables.join(",")

puts "Explicit binding passed"
parse_data_hash(data_hash, binding)
puts local_variables
local_variables.each do |k|
print "#{k} => "
eval("print #{k}.inspect")
puts
end
end

parse_test({:a => [1,2,3], :b => "hello"})
------

Writing this brought out a few really interesting details about Ruby
that I would like to discuss.

1) I had to use ObjectSpace._id2ref in order to achieve the ability to
set variable a to the passed Array. I did not like using this method,
even without the warning not to use it found in the "Ruby in a
Nutshell" book. Interestingly this warning is not found in the RDoc
and ri generated description. Is there a better way to do this?

2) In parse_data_hash I attempted to make passing the binding
optional. As you see in the parse_test that does not work, because it
is assigning the binding to the binding of the parse_data_hash method
and not from its' caller.

2.1 ) eval currently makes passing the binding optional. Is there a
way to do this in Ruby or is this something only available to the
internal implementation?

2.2) I was thinking it might be interesting if you could get the
binding of the caller from calling "caller". Of course, having this
ability opens your self up to a lot of dangerous usages and possibly
some powerful usages too. One usage would be a way to get the binding
of the caller for parse_data_hash. I am wondering if this is a bad
idea and if any other languages allow you to do this?

2.3) Does anyone have an example of how you can use eval with a Proc
object instead of an binding? The docs say you can do this, but does
not provide an example and my test below does not work either..

----
p = Proc.new { x = "Hello" }
eval("puts x", p)
t.rb:1: undefined local variable or method `x' for main:Object (NameError)
from t.rb:1
----


I have some other fuzzy ideas about the binding and method objects,
but I better save that for another day when I can unfuzz them.
Although, one quick idea is if it would be possible in the future to
save the binding to disk or send it to another Ruby process?


Cheers,
Zev Blut


Stephan Kämper

6/1/2005 10:56:00 AM

0

Joel VanderWerf wrote:
> Hal Fulton wrote:
>
>> Ara.T.Howard wrote:
>>
>>> HISTORY
>>>
>>> 0.0.0
>>
>> Hmm, I think I used a prior version of it... ;)
>
> Was that 0.0.0.0, or 0.0.0.0.0? ;)
>
> Ruby folks are so conservative in version numbering that it wouldn't be
> surprising to see negative versions... "Your library looks nice, but I'm
> not going to use use it until it goes positive."

And the version numbers of ideas (read: vapour ware) might well be
imaginary numbers....
"I' won't think about using it, before it becomes real." :-)


Happy rubying

Stephan

Jim Weirich

6/1/2005 11:51:00 AM

0

On Tuesday 31 May 2005 11:16 pm, Ara.T.Howard wrote:
> i use the libtool/ld versioning system:
>
>    interface.implementation.age
>
> the first two are pretty self explanatory, the age bit need examples to
> explain.

I hadn't seen age used like that before. Interesting.

> i'd be curious to know the rational behind other ruby project's version
> numbers and what information can be gleaned from them.

The recommended RubyGems versioning policy is summarized at
http://docs.rubygems.org/read.... The main purpose of the policy is
to allow reasonable version comparisons for dependency declarations,
especially the use of the "approximately greater than" version operator (see
http://docs.rubygems.org/read/chapter...)

The libtool/ld policy would work gems as well, except that RubyGems wouldn't
know the fine distinctions provided by the age field.

--
-- Jim Weirich jim@weirichhouse.org http://onest...
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)


Ara.T.Howard

6/1/2005 8:30:00 PM

0

Ara.T.Howard

6/1/2005 8:35:00 PM

0

Zev Blut

6/2/2005 3:17:00 AM

0

Hello,

On Thu, 02 Jun 2005 05:30:28 +0900, Ara.T.Howard <Ara.T.Howard@noaa.gov>
wrote:

> the problem here is that the variables will only be __available__
> through eval
> either. eg. you'd have to
>
> p 'eval a'
>
> and could never
>
> p a
>
> i seem to recall a way of working around this but can't remember the
> thread...
> if i can figure it out i'll add this feature.

Wow I am quite surprised at this! It is quite odd that adding a
variable through the use of eval, makes the variable appear in the
local_variables method, but that you cannot access the variable unless
you use eval... Below is a simpler example showing how using eval
modifies the the local_variables response.

----------------------------------------------------------------------
puts "[" + local_variables.join(" , ") + "]"
#=> []
eval 'a = 42'
puts "[" + local_variables.join(" , ") + "]"
#=> [a]
puts a
#=> undefined local variable or method `a' for main:Object (NameError)
----------------------------------------------------------------------

If you cannot access a in your binding, why would eval add a to the
local_variables? Can anyone explain this? I would like to know.

Thanks,
Zev Blut