[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Run-time parameterized modules - ruby style?

Its Me

1/29/2005 5:36:00 PM

I think I want to use this design in a few places in my code, to write a
single module that can be adapted to different needs:

module M
<normal stuff>
def self.[](params)
create new module
populate using params and (M or <normal stuff>)
return new module
end
end

class A
include M[p1, p2]
end

Is this reasonable Ruby style? Have others found uses for this?

If the generated module did not include M, what would be a good way of
keeping the instantiated M[param] in sync with changes in M? e.g. new
methods are added to M, or an M method is re-defined?

If this is still roughly within the Ruby way, would it be reasonable style
to use this in multi-class modules, as follows:
module M
module Mx...end
module My...end
def self.[] (x,y)
end

module Mine
class A...end
class B...end
include M[p1, p2]
# effectively same as
# class A; include M::Mx[p1]
# class B; include M::My[p2]
end

Thanks.
3 Answers

Ilmari Heikkinen

1/29/2005 6:41:00 PM

0

Hallo,
On 29.1.2005, at 19:41, itsme213 wrote:

> I think I want to use this design in a few places in my code, to write
> a
> single module that can be adapted to different needs:
>
> module M
> <normal stuff>
> def self.[](params)
> create new module
> populate using params and (M or <normal stuff>)
> return new module
> end
> end
>
> class A
> include M[p1, p2]
> end
>
> Is this reasonable Ruby style? Have others found uses for this?

Don't know much about Ruby style, but I'll open my trap anyhow.

Less code you have to write, less code you have to change.

Though there are some pitfalls in this technique.
Marshalling might not work, code might become harder to read,
documentation tools might not work.

Overall.. *shrug*
dunno
If it makes the code easier to maintain, go for it.
If it makes the code more readable, go for it.
If it makes you happy, go for it.

I used run-time generated modules to implement a mimetype
hierarchy with multiple inheritance (text/html is subclass of
text/plain, text, and application/octet-stream).
So that it was possible to do
Mime['text/html'].is_a? Mime['application/octet-stream'] #=> true
Mime['text/html'].is_a? Mime['text/plain'] #=> true
etc.

> If the generated module did not include M, what would be a good way of
> keeping the instantiated M[param] in sync with changes in M? e.g. new
> methods are added to M, or an M method is re-defined?

One would usually use include for that, yes. If you don't want the
generated
module to be related to M, it shouldn't care about changes to M anyhow,
no?

------------------------------------------------------------------------
----------------
DASH 100M GO!!

Pit Capitain

1/29/2005 8:36:00 PM

0

itsme213 schrieb:
>
> class A
> include M[p1, p2]
> end
>
> Is this reasonable Ruby style? Have others found uses for this?

The delegate module in the standard library uses a similar technique:

require "delegate"

class ArrayProxy < DelegateClass(Array)
...
end

I haven't seen it very often, though.

Regards,
Pit

Its Me

1/30/2005 12:51:00 AM

0


"Ilmari Heikkinen" <kig@misfiring.net> wrote

> > If the generated module did not include M, what would be a good way of
> > keeping the instantiated M[param] in sync with changes in M? e.g. new
> > methods are added to M, or an M method is re-defined?
>
> One would usually use include for that, yes. If you don't want the
> generated
> module to be related to M, it shouldn't care about changes to M anyhow,
> no?

It is related, but not by inclusion e.g. the generated module may put
wrappers around or re-name M's methods. I don't want M's methods to be
callable or visible in classes that include the generated module. But I
would like to propagate changes to M into the corresponding wrappers. I'll
look again at hooks in Module, like #method_added and #method_removed.