[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5613] [RRFC] versioning revisited

From: hipster <hipster@...4all.nl>
Date: 2000-10-16 20:20:35 UTC
List: ruby-talk #5613
[Ruby Request For Comments]

Matz noted he wants to take the versioning logic a step further to include
libraries (and I'll even consider versioning classes). This is a draft
proposal for such a versioning scheme.

If we can shake this down to an intuitive, future-proof scheme, I'd be
happy to implement it.

	I welcome your comments,
	Michel

(PS: Matz, congratulations with the grant!)


1. Version check syntax

ruby version
  require "1.6"               # at least 1.6

probably generalised into:
  require "ruby 1.6"          # at least 1.6
  require "ruby == 1.6.1"     # exactly 1.6.1

library version check:
  require "thread"            # any version of thread
          "thread 4.2"        # at least 4.2
          "thread >= 4.2"     # at least 4.2
          "thread == 4.2"     # exactly 4.2
          etc. with <, >, <=, !=

(Maybe even multiple conditions:
  require "thread 4.2; != 4.2.7" # at least 4.2 but not 4.2.7
but that becomes quite ugly real fast...)

The "thread 4.2"-form could also be interpreted as `exactly 4.2' but that
would break a lot of scripts once a library gets updated.


2. How libraries (can) specify their versions

for script libraries (*.rb):
  version "4.2"               # requires a new keyword/builtin
  LIBRARY_VERSION = "4.2"     # this is better, but pollutes namespace

for binary libraries (*.so), every .so implements (e.g.):
  char* library_version(){
    return "4.2";
  }

then retrieve the version string with dlopen/dlsym. This is probably
portable into win*-api's.

2.1 A more fine-grained scheme

> brainstorm = true

Although the former file-level versioning does the job, class-level
versioning might be the future way to go. Something along the lines of

class Aisumasen
  version "4.2"
  ...
end

This of course collides with the current file-level semantics of require.
And, taking this one step further into the realm of versioned interfaces:

class Aisumasen
  version "4.2"

  def apologise
    version "1.1"
    ...
  end

  def apologise
    version "1.0"
    ...
  end
end

But this is probably -- leaving usefulness alone -- too much.

> brainstorm = false


3. Backward compatibility

AFAICS the above scheme does not collide with the current versionless
requires and libraries.

             require "lib"    require "lib 4.2"

lib w/o         current           fall-back*
version        behaviour        (with warning)

lib with        current              new
version        behaviour            check

* to loading the versionless lib

If there are multiple versions of the same library present in the search
path, they are all tried until a match is found. If no library matches the
first on the path is loaded (with a warning?). <uneasy feeling>

In This Thread

Prev Next