Destructive String Methods

[John W. Long]

Is there a way to tell when a destructive method has been called? I've
created a subclass of String to represent a URL. It has handy methods
for extracting parts of the string like the host, port, path, or query
(yes I know about URI). I'd like to cache the results of calling my
extract methods unless the string has changed, in which case I'll
extract and return the correct value again.

The only way I can think of to tell when the string has changed is to
dup in the initialize method and compare with self on every method
call. Are there other options?

 

[Dan Doel]

Well, here -- http://www.rubycentral.com/ref/ref_c_string.html -- is
the reference for the Ruby String class.

The first thing that comes to mind is going through the list, finding
destructive methods, and overriding them in your subclass with a call
to some update function, like so:

class String
def chop!
super

update
end

# ...

def update
# invalidate the cache somehow
end

# ...
end

- Dan

 

[Robert Klemme]

Well, here -- http://www.rubycentral.com/ref/ref_c_string.html -- is
the reference for the Ruby String class.

The first thing that comes to mind is going through the list, finding
destructive methods, and overriding them in your subclass with a call
to some update function, like so:

class String
def chop!
super

update
end

# ...

def update
# invalidate the cache somehow
end

# ...
end

Just keep in mind to preserve the return values like in

def chop!
result = super
update
result
end

The other thing is constness... I feel, that - apart from freeze - Ruby is
not so well suited to differentiating between const and non const instances.
There are too many methods one has to take care of (just think of
instance_eval and instance_variable_get). And even languages that are
better suited to this task (C++ to name one) have problems of their own with
constness...

Kind regards

robert

 

[John W. Long]

I was hoping for something other than that. I like to maintain forward
compatibility.

Of course some of this process could be automated by cycling through the
methods and aliasing and redefining methods that end in !, but this wouldn't
work for << or other methods that don't have the !.

--
John Long
www.wiseheartdesign.com


----- Original Message -----
From: "Dan Doel" <[email protected]>
To: "ruby-talk ML" <[email protected]>
Sent: Monday, February 02, 2004 2:44 PM
Subject: Re: Destructive String Methods

 

[Nathaniel Talbott]

I was hoping for something other than that. I like to maintain forward
compatibility.

Of course some of this process could be automated by cycling through
the
methods and aliasing and redefining methods that end in !, but this
wouldn't
work for << or other methods that don't have the !.

I don't know what you're doing with it, but this seems to be begging
for a custom object. Perhaps the difficulty of doing what you want to
is Ruby's way of telling you to adjust your design. Just a thought.


Nathaniel

<(><

 

[John W. Long]

I don't know what you're doing with it, but this seems to be begging

for a custom object. Perhaps the difficulty of doing what you want to
is Ruby's way of telling you to adjust your design. Just a thought.

Right. A to_s method on a custom object may be just the thing... Strings are
strange objects though. In order to make an effective subclass it seems like
there are times when an #updated method would be nice.