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


 

Forums >

comp.lang.ruby

dynamically changing superclass/mixins

Zoogle

10/3/2006 10:10:00 AM

I have strong interest in highly dynamic languages, particularly
prototype-based languages - and am still looking for the language that I
have to "abuse least" to achieve what I want (for my attempt in Java,
see http://diamondmud.source..., particularly
http://diamondmud.source...architecture.html)

Ruby, apart from just being a great language, has two features that are
fantastic for me:
- open classes: I can add and remove methods "at runtime"
- mixins; this is highly reminiscient of prototype based languages anyway.

Now I have two questions:

1. Can I change the superclass for an already defined class? That is,
remove an existing relationship or add a new one? I haven't been able to
figure that out.

2. Can I also remove modules that I included into a class? I have only
found a very ugly way to do this: undefine the class (Klass = nil) and
define it anew. I am not sure even, what the effect was on existing
instances; if they adapted the new behaviour or not.

I am fairly new to Ruby, so please forgive fundamental misunderstandings!

Thanks a lot,
Michael
17 Answers

Trans

10/3/2006 5:26:00 PM

0


Michael Keller wrote:
> I have strong interest in highly dynamic languages, particularly
> prototype-based languages - and am still looking for the language that I
> have to "abuse least" to achieve what I want (for my attempt in Java,
> see http://diamondmud.source..., particularly
> http://diamondmud.source...architecture.html)
>
> Ruby, apart from just being a great language, has two features that are
> fantastic for me:
> - open classes: I can add and remove methods "at runtime"
> - mixins; this is highly reminiscent of prototype based languages anyway.
>
> Now I have two questions:
>
> 1. Can I change the superclass for an already defined class? That is,
> remove an existing relationship or add a new one? I haven't been able to
> figure that out.

Not going to happen. But you can use modules and delegation to get a
similar effect. Subclassing is over rated anyway.

> 2. Can I also remove modules that I included into a class? I have only
> found a very ugly way to do this: undefine the class (Klass = nil) and
> define it anew. I am not sure even, what the effect was on existing
> instances; if they adapted the new behaviour or not.

Here again, not happening, but this one might not be so far out of
reach "one day". For now at least you have use other techniques.

In both cases, there's probably a good alternative to accomplish what
you trying to do.

T.

Logan Capaldo

10/4/2006 2:35:00 AM

0

On Tue, Oct 03, 2006 at 07:10:10PM +0900, Michael Keller wrote:
> I have strong interest in highly dynamic languages, particularly
> prototype-based languages - and am still looking for the language that I
> have to "abuse least" to achieve what I want (for my attempt in Java,
This may be considered blashpemous, but have you seen Io?
(http://www.iola...) It lets you alter the prototypes for an
object dynamic, which effectively gives you the abilities of removing
mixins and changing the superclass.

> see http://diamondmud.source..., particularly
> http://diamondmud.source...architecture.html)
>
> Ruby, apart from just being a great language, has two features that are
> fantastic for me:
> - open classes: I can add and remove methods "at runtime"
> - mixins; this is highly reminiscient of prototype based languages anyway.
>
> Now I have two questions:
>
> 1. Can I change the superclass for an already defined class? That is,
> remove an existing relationship or add a new one? I haven't been able to
> figure that out.
>
> 2. Can I also remove modules that I included into a class? I have only
> found a very ugly way to do this: undefine the class (Klass = nil) and
> define it anew. I am not sure even, what the effect was on existing
> instances; if they adapted the new behaviour or not.
>
Setting the constant to nil will not effect existing instances.
> I am fairly new to Ruby, so please forgive fundamental misunderstandings!

Trans

10/5/2006 4:39:00 AM

0


Logan Capaldo wrote:
> On Tue, Oct 03, 2006 at 07:10:10PM +0900, Michael Keller wrote:
> > I have strong interest in highly dynamic languages, particularly
> > prototype-based languages - and am still looking for the language that I
> > have to "abuse least" to achieve what I want (for my attempt in Java,
> This may be considered blashpemous, but have you seen Io?
> (http://www.iola...) It lets you alter the prototypes for an
> object dynamic, which effectively gives you the abilities of removing
> mixins and changing the superclass.

Io does look interesting but I for one couldn;t help but shy aways b/c
of it's lack of a block notation. Passing lambdas as regulat prameters
can get pretty rough on the old eyes.

T.

Jeremy Tregunna

10/5/2006 4:54:00 AM

0


On 06-10-05, at 00:39, Trans wrote:

>
> Logan Capaldo wrote:
>> On Tue, Oct 03, 2006 at 07:10:10PM +0900, Michael Keller wrote:
>>> I have strong interest in highly dynamic languages, particularly
>>> prototype-based languages - and am still looking for the language
>>> that I
>>> have to "abuse least" to achieve what I want (for my attempt in
>>> Java,
>> This may be considered blashpemous, but have you seen Io?
>> (http://www.iola...) It lets you alter the prototypes for an
>> object dynamic, which effectively gives you the abilities of removing
>> mixins and changing the superclass.
>
> Io does look interesting but I for one couldn;t help but shy aways b/c
> of it's lack of a block notation. Passing lambdas as regulat prameters
> can get pretty rough on the old eyes.

We don't need block notation, everywhere you'd use blocks in Ruby, we
just use message objects. They're cheap, have the same benefits, and
tie well into Io's conceptual unification.

--
Jeremy Tregunna
Io Language Developer
jtregunna@blurgle.ca

Trans

10/5/2006 11:58:00 AM

0


Jeremy Tregunna wrote:

> We don't need block notation, everywhere you'd use blocks in Ruby, we
> just use message objects. They're cheap, have the same benefits, and
> tie well into Io's conceptual unification.

Which is why you write a for loop like this?

for(i, 99, 1,
writeln(i, " of beer on the wall, ", i, " of beer,")
writeln("take one down, pass it around,")
writeln(bottle(i - 1), " of beer on the wall.")
)

T.

Paul Battley

10/5/2006 12:19:00 PM

0

On 05/10/06, Trans <transfire@gmail.com> wrote:
>
> Jeremy Tregunna wrote:
>
> > We don't need block notation, everywhere you'd use blocks in Ruby, we
> > just use message objects. They're cheap, have the same benefits, and
> > tie well into Io's conceptual unification.
>
> Which is why you write a for loop like this?
>
> for(i, 99, 1,
> writeln(i, " of beer on the wall, ", i, " of beer,")
> writeln("take one down, pass it around,")
> writeln(bottle(i - 1), " of beer on the wall.")
> )

Clippy says, 'It looks like you're being sarcastic!' (Correct me if I'm wrong.)

It doesn't look much like Ruby, granted, but it *does* tie in with the
rest of Io. Consider if/else:

if(cond, writeln("aye"), writeln("nay"))

Being able to pass multiple 'blocks' to a method facilitates things
like the above, which aren't possible with Ruby's single-block
approach.

Io's an interesting language.

Paul.

Trans

10/5/2006 1:30:00 PM

0


Paul Battley wrote:
> Clippy says, 'It looks like you're being sarcastic!' (Correct me if I'm wrong.)

A tinge perhaps, but not meant in a mean way. Just pointing out what I
meant by the lack of blocks.

> It doesn't look much like Ruby, granted, but it *does* tie in with the
> rest of Io. Consider if/else:
>
> if(cond, writeln("aye"), writeln("nay"))
>
> Being able to pass multiple 'blocks' to a method facilitates things
> like the above, which aren't possible with Ruby's single-block
> approach.

I agree. Multiple blocks are nice, but it could be be done with a block
notation too if one wanted:

if(cond) {writeln("aye")} {writeln("nay")}

Hmm... does Io support currying? Then:

if(cond)(writeln("aye"))(writeln("nay"))

wouldn't be so bad actually.

> Io's an interesting language.

I can agree. I'm just very asthetically guided with my initial contact
with things. Some of the code examples had me feeling a bit "lispy".
Camelcase too is something I'm no longer fond. I guess maybe I've just
gotten very used to the over all look of Ruby.

But I argee, Io's a tempting lanugage.

T.

Jeremy Tregunna

10/5/2006 2:45:00 PM

0


On 06-10-05, at 08:00, Trans wrote:

>
> Jeremy Tregunna wrote:
>
>> We don't need block notation, everywhere you'd use blocks in Ruby, we
>> just use message objects. They're cheap, have the same benefits, and
>> tie well into Io's conceptual unification.
>
> Which is why you write a for loop like this?
>
> for(i, 99, 1,
> writeln(i, " of beer on the wall, ", i, " of beer,")
> writeln("take one down, pass it around,")
> writeln(bottle(i - 1), " of beer on the wall.")
> )

Well yes. But only three of those arguments are evaluated (99, 1, and
the body of the loop). "i" is never evaluated, we just inspect the
name supplied by the user, and use it to set a slot which you can use
in the body which represents the element you're looping over. 99 and
1 have a cached result set so they're nice and quick. The cost of a
method/block to activate in Io is roughly 4x to 20x greater than for
a message to evaluate, which is why we tend to use messages instead
of blocks. (Just as a side note, I generally avoid using the for loop
and opt for Ranges myself, they just read better: 99 to(1) foreach
(i, ...); but the same principal applies.)

That said, you could extend Io's syntax without even having to get
involved with the parser to support ruby style block notation. I have
an example of manipulating Io's AST to create a small subset of C by
doing nothing but manipulating the parse tree[1]. Not the best way to
go about doing it, but certainly evil and clever.

[1] - http://blurgle.blogspot.com/2006/09/fun-with-...

--
Jeremy Tregunna
jtregunna@blurgle.ca

Jeremy Tregunna

10/5/2006 2:50:00 PM

0


On 06-10-05, at 09:35, Trans wrote:

>> It doesn't look much like Ruby, granted, but it *does* tie in with
>> the
>> rest of Io. Consider if/else:
>>
>> if(cond, writeln("aye"), writeln("nay"))
>>
>> Being able to pass multiple 'blocks' to a method facilitates things
>> like the above, which aren't possible with Ruby's single-block
>> approach.
>
> I agree. Multiple blocks are nice, but it could be be done with a
> block
> notation too if one wanted:
>
> if(cond) {writeln("aye")} {writeln("nay")}
>
> Hmm... does Io support currying? Then:
>
> if(cond)(writeln("aye"))(writeln("nay"))

No, Io doesn't support currying out of the box; we just don't empose
an arity field on our methods/blocks. That is to say, you could
define a method which takes 3 arguments, if you only supply 2, the
last argument will receive "nil" as its value instead of a message
expression.

However, many attempts have been made (successfully I might add) to
add different levels of currying to Io. Asking on our mailing list is
likely to get you one or two examples =]

--
Jeremy Tregunna
jtregunna@blurgle.ca

Ara.T.Howard

10/5/2006 3:10:00 PM

0