Hello, at the moment the lib behaves like following. ip = IPAddr.new("192.168.2.43/24") => #<IPAddr: IPv4:192.168.2.0/255.255.255.0> So so orgin information is lost IMHO this is a bad behavior. I discussed this matter already in the ruby ml a year ago. Somebody was the opinion thats this is what he expect, cause 192.168.2.43/24 is not a valid notation. He said the valid notation is either 192.168.2.43/32, 192.168.2.43 or 192.168.2.0/24. If I would agree with him ( I don't) I would say that IPAddr still behaves wrong. It should raise an execption if the argument (notation) is invalid and should not alter the argument silently. But I state it is a valid notation. Many network administrator use this notation to express the address and the prefixlen/netmask in one string. So I suggest to change the behavior of the lib a following and like to read your opinions about it. ip = IPAddr.new("192.168.2.43/24") => #<IPAddr: IPv4:192.168.2.43/255.255.255.0> ip.addr => "192.168.2.43" ip.netmask => "255.255.255.0" ip.net => "192.168.2.0" # just for ipv4 family" ip.broadcast "192.168.2.255" # just for ipv4 family" ip.prefix => "192.168.2.0/24" ip.prefixlen => "24" And I would also suggest to migrate to cidr in all places cause this is the future. So the class should internal just use the prefixlen and net the netmask anymore. BTW A 6to4 method would be a nice feature too. exp. ip = IPAddr.new("192.168.2.43") => #<IPAddr: IPv4:192.168.2.43/255.255.255.255> ip.6to4_prefix => "2002:3eb0:e08c::0621:7622:4140/48" ip.6to4 => "2002:3eb0:e08c::0621:7622:4140/128" or ip.6to4 => "2002:3eb0:e08c::0621:7622:4140" bye Markus Disclaimer:-) Cause my english is not as good as it should be. Everything I've written should be interpreted as objective and open minded. I don't have a unalterable opinion, how it could seem.
on 2005-12-31 12:02
on 2005-12-31 12:15
Markus Werner wrote: > > > ip.netmask => "255.255.255.0" > BTW > > > > bye > > Markus My suggestion is to submit a patch to ruby-core and see what folks think. It may be rejected, but at least it will be considered. Another option is to submit your idea to the author of the ip-address project on RubyForge at http://rubyforge.org/projects/ip-address/ and see what Erik thinks of it. Regards, Dan
on 2005-12-31 12:21
Dear Daniel, > My suggestion is to submit a patch to ruby-core and see what folks > think. It may be rejected, but at least it will be considered. Since I'm not a real programmer I would discuss the different ways to do it. So I don't chose a bad way. > Another option is to submit your idea to the author of the ip-address > project on RubyForge at http://rubyforge.org/projects/ip-address/ and > see what Erik thinks of it. I'll consider this, thanks for this hint. Just an overview: 1. Easy way would be do just extend the Method IPAddr#new to save also the IPAdress and not only the net. So it would be easy to derive from ipaddr. 2. Simple derive from ipaddr and write your own initialize function which stores the required attr. In this case it is necessary to reimplement (cut & paste :-) things that are already in the superclass. I don't like this way. 3. Implementing a different behavior with an migration strategy. .... with kind regards Markus