Ruby

=begin
Hi Marco, awesome lib. I read trough it and here are the thoughts I had:

• IPAddr#[] and IPAddr#each don't hold the same elements, could it be a source of confusion ?
• Is it possible to avoid extending the ruby core ?

Cheers,
Jonas
=end

=begin
Jonas Pfenniger wrote:

Hi Marco, awesome lib.

Thank you Jonas

• IPAddr#[] and IPAddr#each don't hold the same elements, could it be a source of confusion ?

Never thought about that, but it's a good point. IPv4#[] is an alias to IPv4#octet, just some syntax sugar, could be easily removed if we think it may lead to confusion.

• Is it possible to avoid extending the ruby core ?

It is possible indeed, especially if that's a requirement for the replacement. I chose to extend the core to make some algorithms much clearer, but nothing prevents to make them private methods and removing the extensions. Do you feel it would be better?

Regards,
Marco

=end

Hello,

I have released version 0.8.0.

The most important change related to the this discussion is the removal of the extension methods and the extension directory, as requested by Jonas. Hope this will make the replacement work easier.

Announcement is here
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/383370

Regards,
Marco

Hi,

I just came across this issue and had a question about it: why not remove things from core instead of adding new ones ?
I love the IPAddress gem and I already use it on many projects but why including it in core ? (if anyone is using the current IPaddr it may be extracted as a gem)

From my point of view it will only makes upgrading the gem painful and require a ruby version upgrade instead of a simple gem install ipaddress,
I would love to see parts of the standard library go away, I may be an exception but I never used even 50% (and the truth may even be below 25% ) of it and I have used ruby for many years now. Most of the things are just better done by existing gems than standard libraries and installing/using them is now even easier than ever with bundler so why not just use it and aim for a small core ?

Julien A wrote:

I just came across this issue and had a question about it: why not remove things from core instead of adding new ones ?
I love the IPAddress gem and I already use it on many projects but why including it in core ? (if anyone is using the current IPaddr it may be extracted as a gem)

From my point of view it will only makes upgrading the gem painful and require a ruby version upgrade instead of a simple gem install ipaddress,

Hello Julien

I agree with you, there should be a decision whether to remove the standard library and having a set of standard gems distributed with each release. I think there was a long discussion on the mailing list months ago, unfortunately rather inconclusive.

However, the situation today is quite different and it is my understanding that ruby-core is not moving in that direction. The standard library will stay, at least for the moment. And since I believe that IPAddr is obsolete and a bit bugged, I have opened this proposal to replace it with IPAddress.

Hello,

are there any news on this request? Can I do something to help?

I plan to release 0.9.0 in September with some added features, but at the same time I don't want to grow the library too much, as it would make it more difficult to integrate in the stdlib.

Thanks,
Marco

The library is very stable, it is used in production in many other projects (600k downloads on rubygems), and the compatibility layer with IPAddr has been proven to work well.

Version 1.0 (which addresses a few minor bugs) was planned to be released after receiving feedback from this feature request.

I've made a hopefully last set of changes to ipaddr.rb in trunk a couple months ago:

• introduction of IPAddr::Error for ease of selectively catching IP address errors
• inhibition of zero-filled IPv4 address notation which is ambiguous (as to number bases)
• removal of unexpectedly exposed IPSocket.valid* methods

Marco, can you please take a look, and if you agree with it would you reflect them into the compatibility layer?

Hello knu,

just back from a quick holiday :)

Thanks very much for your update. Here's my feedback:

• introduction of IPAddr::Error for ease of selectively catching IP address errors

that's an easy change for IPAddress, shouldn't modify anything existing; will work on it in the following days and perhaps release a new version of the library

• inhibition of zero-filled IPv4 address notation which is ambiguous (as to number bases)

I'll check IPAddr changelog and let you know on this one

• removal of unexpectedly exposed IPSocket.valid* methods

That was already removed from IPAddress