fxruby users - Jul 2004 - [Q] Proposed FXRuby 1.2 Feature Name Change

All,

I am strongly considering changing the feature name -- that is, the 
string that you pass to the require() method -- from "fox" to
"fox12"
for FXRuby version 1.2. I''d like to hear any comments for and against 
such a change.

There are at least a couple of reasons for the change. One reason has 
to do with the RubyGems "stub library" feature. If you''ve
been
experimenting with the first few alpha releases of FXRuby 1.2, 
specifically the gems-based packages, you know that I''ve been 
recommending this pattern for loading FXRuby:

	require ''rubygems''
	require_gem ''fxruby''

Well, as it turns out, RubyGems also installs what they call a "stub 
library" in the standard Ruby load path, so that you can simply do 
this:

	require ''fox''

and it invokes the magic to load the gem instead. This is, generally 
speaking, a nice idea and provides some measure of 
backwards-compatibility for legacy (i.e. pre-RubyGems) code that didn''t
know to use require_gem. But what in means for FXRuby is that you can''t
really have both FXRuby 1.0 and the gem for FXRuby 1.2 installed 
simultaneously; if you do, then:

	require ''fox''

will always load FXRuby 1.2 and never "see" your FXRuby 1.0 
installation. Not a good thing. If on the other hand we change the 
feature name for FXRuby 1.2 from "fox" to "fox12", RubyGems
will
install a stub library called "fox12.rb", which won''t clash
with older
FXRuby 1.0 installations that used the "fox" feature name.

But perhaps the more compelling reason for a name change at this point 
is that the APIs for FXRuby versions 1.0 and 1.2 are so different. 
Unless you get incredibly lucky, it''s unlikely that a program written 
against the FXRuby 1.0 API is going to work out of the box when run 
with FXRuby 1.2. And it will be disastrous, in terms of support, if 
application developers have this variable floating around, i.e. when 
they say require ''fox'', is it going to load up version 1.0 or
1.2?

So there you go. If this change goes through, I''m specifically thinking
that (1) the gem name will change from "fxruby" to
"fxruby12"; and, (2)
the feature name will change from "fox" to "fox12". If you
have an
application or library based on FXRuby 1.0, and don''t wish to port it 
to FXRuby 1.2 anytime soon, there will be less pressure to do so since 
both versions would be able to peacefully co-exist.

I don''t intend to change the module name from "Fox", because
you can''t
use both versions simultaneously within the same application and hence 
there should be no opportunity for namespace clashes.

OK, I think that''s all I wanted to say to get the ball rolling. Now 
please shoot holes in my plan. ;)

Thanks,

Lyle

On Tue, 27 Jul 2004, Lyle Johnson wrote:
> All,
>
> I am strongly considering changing the feature name -- that is, the string 
> that you pass to the require() method -- from "fox" to
"fox12" for FXRuby
> version 1.2. I''d like to hear any comments for and against such a
change.
I''d suggest fox1_2 to save any confusion when Fox 12.x comes out....
Will you be backporting this into FXRuby 1.0 as well, as fox1_0, for
consistency?

         Hugh

On Tue, 27 Jul 2004 21:20:53 -0500
Lyle Johnson <lyle@knology.net> wrote:
>      Well, as it turns out, RubyGems also installs what they call a
"stub
>      library" in the standard Ruby load path, so that you can simply
do
>      this:
>      
>      	require ''fox''
I have both 1.2.x and 1.2.x libraries installed, and I had to rename this
stub library to be able to require the old version.

This problem wouldn''t exist if this RubyGems feature were controllable
via RubyGems package spec file.

Maybe we should propose this feature to the RubyGems developers ?


-- 
Best regards,
Yuri Leikind

On Jul 28, 2004, at 5:01 AM, Hugh Sasse Staff Elec Eng wrote:
> I''d suggest fox1_2 to save any confusion when Fox 12.x comes
out....
Ugh, I recoil in horror at that underscore. Given Jeroen''s conservative
approach to versioning, I think it''s safe to say I''ll be
pushing up
daisies before FOX version 12 ever materializes. If I''m proven wrong, I
will gladly accept your "See, I told you so". ;)

I think I''ll stick with "fox12".
> Will you be backporting this into FXRuby 1.0 as well, as fox1_0, for
> consistency?
I don''t think there''s any point, at this juncture (besides
which it
would break existing code that tries to require ''fox''). So the
unadorned "fox" feature name will always be associated with FXRuby
1.0.

On Jul 28, 2004, at 9:20 AM, Yuri Leikind wrote:
> I have both 1.2.x and 1.2.x libraries installed, and I had to rename 
> this
> stub library to be able to require the old version.
Yes, this is one of the problems I was referring to with the current 
naming situation.
> This problem wouldn''t exist if this RubyGems feature were
controllable
> via RubyGems package spec file.
True, but we''d still have a name clash for people who prefer to install
it from some other, non-RubyGems source (such as RPA).
> Maybe we should propose this feature to the RubyGems developers?
Regardless of whether we personally could take advantage of such a 
feature, I agree that it''s a good idea. I can give you their e-mail 
address if you''d like. ;)

Lyle,

   I''m all for it.

   What you suggested sounds great.

   Thanks for being worried about my old applications.

-Rich


On Wed, 28 Jul 2004 18:19:38 -0500, Lyle Johnson <lyle@knology.net>
wrote:
> 
> On Jul 28, 2004, at 9:20 AM, Yuri Leikind wrote:
> 
> > I have both 1.2.x and 1.2.x libraries installed, and I had to rename
> > this
> > stub library to be able to require the old version.
> 
> Yes, this is one of the problems I was referring to with the current
> naming situation.
> 
> > This problem wouldn''t exist if this RubyGems feature were
controllable
> > via RubyGems package spec file.
> 
> True, but we''d still have a name clash for people who prefer to
install
> it from some other, non-RubyGems source (such as RPA).
> 
> > Maybe we should propose this feature to the RubyGems developers?
> 
> Regardless of whether we personally could take advantage of such a
> feature, I agree that it''s a good idea. I can give you their
e-mail
> address if you''d like. ;)
> 
> 
> 
> _______________________________________________
> fxruby-users mailing list
> fxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/fxruby-users
>

On Wed, 28 Jul 2004, Lyle Johnson wrote:
>
> On Jul 28, 2004, at 5:01 AM, Hugh Sasse Staff Elec Eng wrote:
>
>> I''d suggest fox1_2 to save any confusion when Fox 12.x comes
out....
>
> Ugh, I recoil in horror at that underscore. Given Jeroen''s
conservative
:-)  Well, it is better than a space! :-)
         [...]
> I think I''ll stick with "fox12".
OK.
>
>> Will you be backporting this into FXRuby 1.0 as well, as fox1_0, for
>> consistency?
>
> I don''t think there''s any point, at this juncture
(besides which it would
> break existing code that tries to require ''fox''). So the
unadorned "fox"
I wasn''t thinking of making it mandatory for current code, just
optional to be clear.
> feature name will always be associated with FXRuby 1.0.
>
         Hugh
>

It''s a shame that ruby doesn''t provide a

require_version ''fox'' ''1.2''

function.

That way you could "pin" your app to a specific
version of the module you want and if it wasn''t
available to take appropriate action to warn/other.

Maybe even extend it to get a code block on
non-availability

eg:

require_version ''fox'' ''1.0'' { |e|
	puts "Fox version 1.0 required."
}

or

require_version ''fox'' ''1.2'' { |e|
	# limp mode: redefines/overrides/mappings
}

Cheers,
-- Tom. 
> -----Original Message-----
> From: fxruby-users-bounces@rubyforge.org 
> [mailto:fxruby-users-bounces@rubyforge.org] On Behalf Of Lyle Johnson
> Sent: Tuesday, July 27, 2004 9:21 PM
> To: fxruby-users@rubyforge.org
> Subject: [fxruby-users] [Q] Proposed FXRuby 1.2 Feature Name Change
> 
> All,
> 
> I am strongly considering changing the feature name -- that is, the 
> string that you pass to the require() method -- from "fox" to
"fox12"
> for FXRuby version 1.2. I''d like to hear any comments for and
against
> such a change.
> 
> There are at least a couple of reasons for the change. One reason has 
> to do with the RubyGems "stub library" feature. If
you''ve been
> experimenting with the first few alpha releases of FXRuby 1.2, 
> specifically the gems-based packages, you know that I''ve been 
> recommending this pattern for loading FXRuby:
> 
> 	require ''rubygems''
> 	require_gem ''fxruby''
> 
> Well, as it turns out, RubyGems also installs what they call a "stub 
> library" in the standard Ruby load path, so that you can simply do 
> this:
> 
> 	require ''fox''
> 
> and it invokes the magic to load the gem instead. This is, generally 
> speaking, a nice idea and provides some measure of 
> backwards-compatibility for legacy (i.e. pre-RubyGems) code 
> that didn''t 
> know to use require_gem. But what in means for FXRuby is that 
> you can''t 
> really have both FXRuby 1.0 and the gem for FXRuby 1.2 installed 
> simultaneously; if you do, then:
> 
> 	require ''fox''
> 
> will always load FXRuby 1.2 and never "see" your FXRuby 1.0 
> installation. Not a good thing. If on the other hand we change the 
> feature name for FXRuby 1.2 from "fox" to "fox12",
RubyGems will
> install a stub library called "fox12.rb", which won''t
clash
> with older 
> FXRuby 1.0 installations that used the "fox" feature name.
> 
> But perhaps the more compelling reason for a name change at 
> this point 
> is that the APIs for FXRuby versions 1.0 and 1.2 are so different. 
> Unless you get incredibly lucky, it''s unlikely that a program
written
> against the FXRuby 1.0 API is going to work out of the box when run 
> with FXRuby 1.2. And it will be disastrous, in terms of support, if 
> application developers have this variable floating around, i.e. when 
> they say require ''fox'', is it going to load up version
1.0 or 1.2?
> 
> So there you go. If this change goes through, I''m 
> specifically thinking 
> that (1) the gem name will change from "fxruby" to 
> "fxruby12"; and, (2) 
> the feature name will change from "fox" to "fox12". If
you have an
> application or library based on FXRuby 1.0, and don''t wish to port
it
> to FXRuby 1.2 anytime soon, there will be less pressure to do 
> so since 
> both versions would be able to peacefully co-exist.
> 
> I don''t intend to change the module name from "Fox",
because
> you can''t 
> use both versions simultaneously within the same application 
> and hence 
> there should be no opportunity for namespace clashes.
> 
> OK, I think that''s all I wanted to say to get the ball rolling.
Now
> please shoot holes in my plan. ;)
> 
> Thanks,
> 
> Lyle
> 
> _______________________________________________
> fxruby-users mailing list
> fxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/fxruby-users
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.726 / Virus Database: 481 - Release Date: 7/22/2004
>  
> 
---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.726 / Virus Database: 481 - Release Date: 7/22/2004
 

This e-mail or the documents accompanying this e-mail contain
information that may be confidential and/or privileged. It may
also be prohibited from disclosure under applicable law. The
information is intended to be for the use of the individual or
entity named on this transmission. If you are not the intended
recipient, be aware that any disclosure, copying, distribution
or use of the contents of this information is without
authorization and is prohibited. If you have received this
e-mail in error, please notify us immediately so that we can
take action to correct the problem.