Good enough for me! 1.2 is shaping up to be another great release.
Joe
On Tue, Feb 17, 2009 at 9:46 PM, Charles Oliver Nutter <
[email protected]> wrote:
> I appreciate your position, and I totally agree. Just look at the number of
> deprecated methods we have collected. I did a pass during
I appreciate your position, and I totally agree. Just look at the number
of deprecated methods we have collected. I did a pass during 1.2 to
strip that number down a bit (especially since many were over a year
old) but we're definitely erring on the side of caution when it comes to
user-visible
No, I don't think personally I have any code that would be effected, I'm
just thinking it might be good to formalize a process for when these kinds
of issues come up. Since the behavior was never exactly specified I don't
think this problem can be considered a "bug" that is being fixed. It's more
Is this going to affect code of yours? I suppose it could be reduced to
a warning, but it's pretty hard to fix the issue I resolved without
breaking this behavior. And for what it's worth it was never really
advocated or recommended, though I know that's little consolation.
Joseph Athman wrote
Is there any way to deprecate the current frowned upon usage of require and
release a new point release of JRuby before 1.2? It seems a little harsh to
simply remove something that used to work (even poorly) without giving
people a nice way of checking their code for this problem. Rails seems to
On Tue, Feb 17, 2009 at 12:31 AM, Charles Oliver Nutter
wrote:
> Stephen Bannasch wrote:
>>
>> At 8:38 PM -0600 2/16/09, Charles Oliver Nutter wrote:
>>>
>>> I'm working on http://jira.codehaus.org/browse/JRUBY-3214 and I think we
>>> need to ratchet down what load and require do when loading .cla
I think this has come around a few times with Monkeybars apps for some
of our users. The workaround for it is pretty easy, but I think some
greater separation between Java and Ruby is better here. It could also
help the developer in thinking that $LOAD_PATH != $CLASSPATH, which is
a somewhat relat
Sounds like a worthwhile change to me.
On Mon, Feb 16, 2009 at 9:38 PM, Charles Oliver Nutter <
[email protected]> wrote:
> I'm working on http://jira.codehaus.org/browse/JRUBY-3214 and I think we
> need to ratchet down what load and require do when loading .class files.
> They've started to
2009/2/17 Charles Oliver Nutter :
> No, this would remain the same. The only behavior that would change is
> using:
>
> require 'some.java.Class'
>
> as a way of getting that class loaded and callable. It will now raise an
> error saying you should use 'java_import' to load it in (I could have said
Stephen Bannasch wrote:
At 8:38 PM -0600 2/16/09, Charles Oliver Nutter wrote:
I'm working on http://jira.codehaus.org/browse/JRUBY-3214 and I think
we need to ratchet down what load and require do when loading .class
files. They've started to get overloaded for loading an individual
Java clas
At 8:38 PM -0600 2/16/09, Charles Oliver Nutter wrote:
I'm working on http://jira.codehaus.org/browse/JRUBY-3214 and I
think we need to ratchet down what load and require do when loading
.class files. They've started to get overloaded for loading an
individual Java class, which was never the in
Charles Oliver Nutter wrote:
I'm working on http://jira.codehaus.org/browse/JRUBY-3214 and I think we
need to ratchet down what load and require do when loading .class files.
They've started to get overloaded for loading an individual Java class,
which was never the intended purpose. This gener
I'm working on http://jira.codehaus.org/browse/JRUBY-3214 and I think we
need to ratchet down what load and require do when loading .class files.
They've started to get overloaded for loading an individual Java class,
which was never the intended purpose. This generally circumvents normal
Java
13 matches
Mail list logo
