Attr; and Moving Namespaces

Okay, just two more questions, I swear.

First of all, how prevalent is the use of #attr?

Secondly, if I create a module, is it possible to "reload" it into another
namespace? ex-

module ObjectModifier
  class Object
    def new_method
      ...
    end
  end
end

# reload into toplevel
reinclude ObjectModifier #?

···

--
T.

Okay, just two more questions, I swear.

First of all, how prevalent is the use of #attr?

I know of one person who uses it, but his keyboard seems to lack a
shift key and parentheses, so perhaps his underscore key is also
broken :slight_smile:

I dislike 'attr', as the attr_* methods have a clearer intent and
consistent style.

I do wish, however, that Ruby collected attribute metadata so you
could use it later in the class, to wit:

  class X
    attr_reader :x, :y
    attr_accessor :z

    attributes.include? :x # -> true
    attribute(:x).writer? # -> false
  end

That particular API is the result of less thinking than typing, so
it's not a literal suggestion; just a germ of an idea.

Secondly, if I create a module, is it possible to "reload" it into another
namespace? ex-

module ObjectModifier
  class Object
    def new_method
      ...
    end
  end
end

# reload into toplevel
reinclude ObjectModifier #?

s/reinclude/include/ and give it a try. I think you'll be pleasantly
surprised.

Gavin

···

On Tuesday, August 24, 2004, 1:09:26 AM, T. wrote:

I know of one person who uses it, but his keyboard seems to lack a
shift key and parentheses, so perhaps his underscore key is also
broken :slight_smile:

lol :slight_smile:

I dislike 'attr', as the attr_* methods have a clearer intent and
consistent style.

That's interesting. I'm preparing to release Duckbill and it includes
modifications to the attribute methods. This is the reason I had asked
because I was thinking of using attr for my new primary method. Basically
works like this:

  attr :r, :w=

Which creates a reader and a writer. (It can do other cool things but I'll
save those for release). Its there a better name?

  def_attr
  attr_def
  attribute
  attributes

I do wish, however, that Ruby collected attribute metadata so you
could use it later in the class, to wit:

  class X
    attr_reader :x, :y
    attr_accessor :z

    attributes.include? :x # -> true
    attribute(:x).writer? # -> false
  end

That particular API is the result of less thinking than typing, so
it's not a literal suggestion; just a germ of an idea.

Actually I can do this with my library (I think). In my library every
attribute method routes through a single master function called
"define_attribute". So as long as you use the new methods (and not any of the
aliased old ones) its a piece of cake. Maybe that's a good reason to loose
the old functionality altogether.

> Secondly, if I create a module, is it possible to "reload" it into
> another namespace? ex-
>
> module ObjectModifier
> class Object
> def new_method
> ...
> end
> end
> end
>
> # reload into toplevel
> reinclude ObjectModifier #?

s/reinclude/include/ and give it a try. I think you'll be pleasantly
surprised.

I've tried it three times. Unless I'm missing something it doesn't fly:

  module Tes
    class Object
      def t
          puts "x"
      end
    end
  end

  include Tes
  o = Object.new
  o.t

  #=> undefined method `t' for #<Object:0x402a8d7c> (NoMethodError)

Thanks,
T.

···

On Monday 23 August 2004 02:11 pm, Gavin Sinclair wrote:

T. Onoma schrieb:

I've tried it three times. Unless I'm missing something it doesn't fly:

  module Tes
    class Object
      def t
          puts "x"
      end
    end
  end

  include Tes
  o = Object.new
  o.t

  #=> undefined method `t' for #<Object:0x402a8d7c> (NoMethodError)

Hi T.,

the Object class you define in module Tes isn't the top-level class Object but the new class Tes::Object. So either change the calling code to

   # include Tes <-- not needed anymore
   o = Tes::Object.new
   o.t

or don't define a new class in Tes but simply include the module in the top-level class Object:

   module Tes
     def t
       puts "x"
     end
   end

   class Object
     include Tes
   end

   o = Object.new
   o.t

or extend only the new Object instance with the module:

   module Tes
     def t
       puts "x"
     end
   end

   o = Object.new
   o.extend Tes
   o.t

Regards,
Pit

Thanks Pit. Just to be clear, I am indeed attempting to accomplish exactly
what my original example pretends to do. I have some modifications for the
the core ruby libs (like Object) and I was hoping that I could encapsulate
them in a namespace and then "reload" them into the toplevel at a later point
in execution. In effect gaining (somewhat) dynamically controllable core
class modifications. While not nearly as concise as I had hoped, your 2nd
example above can be made to do the job. Thanks!

T.

···

On Wednesday 25 August 2004 05:45 am, Pit Capitain wrote:

[snip]
or don't define a new class in Tes but simply include the module in the
top-level class Object:

   module Tes
     def t
       puts "x"
     end
   end

   class Object
     include Tes
   end

   o = Object.new
   o.t

or extend only the new Object instance with the module:
[snip]
Regards,
Pit

T. Onoma schrieb:

Thanks Pit. Just to be clear, I am indeed attempting to accomplish exactly what my original example pretends to do. I have some modifications for the the core ruby libs (like Object) and I was hoping that I could encapsulate them in a namespace and then "reload" them into the toplevel at a later point in execution. In effect gaining (somewhat) dynamically controllable core class modifications. While not nearly as concise as I had hoped, your 2nd example above can be made to do the job. Thanks!

Ah I see.

If you want to add/modify some singular methods then you could implement the namespaces not as modules but simply as files, which you require/load dynamically. Not as nice as modules but maybe still useful.

If you want to add functionality spanning more than one class then maybe Object Teams (http://www.objectteams.org) is what you're looking for. Ther's also a Ruby implementation. With Object Teams, you express a concept as a "team" of objects working together (one of their examples is the observer pattern with the "roles" observable and observer). Then you can "connect" those teams to existing classes, thereby adding new behaviour to them.

Regards,
Pit