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


 

Forums >

comp.lang.ruby

Mutable strings

Mystifier

1/13/2005 6:49:00 PM

Hi All,

Since my communications skills have be questioned on the ML, I am trying to
be better :)


I saw few last posts by matz categorically saying that strings shall be
mutable.

I have nothing against or for it as a language specification. What interests
me that if string are immutable, we can use strings as symbols. This can
bring about few important effects on VM.

1) Symbols and FixNum have few exceptions to the usual rules. Symbols may
not have any exceptions, since symbol and strings will be basically same.

2) Efficiency of VM will improve because Symbols and Strings can be used
interchangeably.

3) It might help on security, perhaps.

A Mutable string class can be created for mutating strings.

No, I am not trying to create another java, but as Users, how many times
have you mutated your strings?

A mailing list to discuss Vuby Specifications has been created on Berlios
and will be active shortly for discussions.

https://developer.berlios.de/proj...

regards,
Mystifier
19 Answers

Austin Ziegler

1/13/2005 6:57:00 PM

0

On Fri, 14 Jan 2005 03:48:58 +0900, Mystifier
<mystifier@users.berlios.de> wrote:
> Hi All,
>
> Since my communications skills have be questioned on the ML, I am trying to
> be better :)
>
> I saw few last posts by matz categorically saying that strings shall be
> mutable.
>
> I have nothing against or for it as a language specification. What interests
> me that if string are immutable, we can use strings as symbols. This can
> bring about few important effects on VM.

"Foo Bar".to_sym
:"Foo Bar".to_s

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca

Charles Mills

1/13/2005 8:16:00 PM

0


Mystifier wrote:
> Hi All,
>
> Since my communications skills have be questioned on the ML, I am
trying to
> be better :)
>
>
> I saw few last posts by matz categorically saying that strings shall
be
> mutable.
>
> I have nothing against or for it as a language specification. What
interests
> me that if string are immutable, we can use strings as symbols. This
can
> bring about few important effects on VM.
>
> 1) Symbols and FixNum have few exceptions to the usual rules. Symbols
may
> not have any exceptions, since symbol and strings will be basically
same.

Symbols are immutable. The current implementation of symbols seems
like a good one to me. They are just a number that uniquely identifies
a string (contained in a symbol table somewhere in the interpreter).

>
> 2) Efficiency of VM will improve because Symbols and Strings can be
used
> interchangeably.
>
Ruby already uses some nice tricks for sharing memory between string
instances (and between array instances).

> 3) It might help on security, perhaps.
>
> A Mutable string class can be created for mutating strings.
>
> No, I am not trying to create another java, but as Users, how many
times
> have you mutated your strings?

Try ri String. About 1/2 the methods change the reciever.

>
> A mailing list to discuss Vuby Specifications has been created on
Berlios
> and will be active shortly for discussions.
>
> https://developer.berlios.de/proj...
>

There are already a number of Ruby VM projects. Many of them
relatively mature. Perhaps you should take a look at those.
If you are writing a VM, I don't see why you would need to rewrite the
standard library, or even break the Ruby API at the C level.

-Charlie

Nikolai Weibull

1/13/2005 10:11:00 PM

0

* Mystifier (Jan 13, 2005 19:50):
> I have nothing against or for it as a language specification. What
> interests me that if string are immutable, we can use strings as
> symbols. This can bring about few important effects on VM.

Python has immutable strings. If you want 'em, use Python.

Now, lets begin a long thread about Python versus Ruby, starting off by
discussing the merits of immutable versus mutable strings, but soon
trailing off by discussing the fact that Guido is Dutch and matz is
Japanese and how this makes Python/Ruby better/worse,
nikolai

--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Mystifier

1/14/2005 5:00:00 AM

0

Dear Charles,

I have no intensions of changing the language APIs for it really does not
matter to a VM Implementation. All the components that inherently affects
the VM implementations are those that VM uses natively like File, Strings,
Numbers and Threads.

I surprisingly found Symbols are exactly not Immutable...., they are just
like any other class

irb(main):001:0> foo = :foo
=> :foo
irb(main):002:0> class Symbol
irb(main):003:1> def bar=(value)
irb(main):004:2> @bar = value
irb(main):005:2> end
irb(main):006:1> def printbar
irb(main):007:2> print @bar
irb(main):008:2> end
irb(main):009:1> end
=> nil
irb(main):010:0> foo.bar = "eee"
=> "eee"
irb(main):011:0> foo.printbar
eee=> nil
irb(main):012:0> zoo = :foo
=> :foo
irb(main):013:0> zoo.printbar
eee=> nil
irb(main):014:0>

We can think that keys that are strings of the Symbol table are immutable,
while the values which are objects of the instances Symbol are mutable. I
had thought that symbol table was a hash_set but it turns out that it is a
hash_map.

In that case it appears immutable strings are be called as symbols and Ruby
has Immutable strings. of course, by implementing additional methods.

Regards,
Mystifier

Robert Klemme

1/14/2005 9:42:00 AM

0


"Mystifier" <mystifier@users.berlios.de> schrieb im Newsbeitrag
news:000901c4f9a0$899eb620$1a87103d@vubydump...

> I saw few last posts by matz categorically saying that strings shall be
> mutable.
>
> I have nothing against or for it as a language specification. What
interests
> me that if string are immutable, we can use strings as symbols. This can
> bring about few important effects on VM.
>
> 1) Symbols and FixNum have few exceptions to the usual rules. Symbols
may
> not have any exceptions, since symbol and strings will be basically
same.

Do you mean that the current restrictions of Symbol will no longer apply?

> 2) Efficiency of VM will improve because Symbols and Strings can be used
> interchangeably.

Not necessarily: you can see with a Java VM that efficiency of the
application degrades if you have many string manipulations that use String
instead of a more suited class (StringBuffer for example). The same will
happen in Ruby if you need to create a new object for each mutated string.

> 3) It might help on security, perhaps.

Ruby has already #freeze and $SAFE. What additional security do we gain?

> A Mutable string class can be created for mutating strings.

I don't understand what we gain by this. We have this situation already:

- Symbols and frozen Strings are immutable

- Other Strings are mutable

With the added benefit that Symbols are unique: there is at most one
Symbol instance representing a certain character sequence.

> No, I am not trying to create another java, but as Users, how many times
> have you mutated your strings?

Often enough to say it's a very common scenario.

Regards

robert

Florian Gross

1/14/2005 2:18:00 PM

0

Mystifier wrote:

> I surprisingly found Symbols are exactly not Immutable...., they are just
> like any other class

They are mostly immutable. I'd still consider them value objects. In
Ruby you can set instance variables of all Objects, even if they're
immutable.

Austin Ziegler

1/14/2005 2:29:00 PM

0

On Fri, 14 Jan 2005 14:00:07 +0900, Mystifier
<mystifier@users.berlios.de> wrote:
> Dear Charles,
>
> I have no intensions of changing the language APIs for it really
> does not matter to a VM Implementation. All the components that
> inherently affects the VM implementations are those that VM uses
> natively like File, Strings, Numbers and Threads.
>
> I surprisingly found Symbols are exactly not Immutable...., they
> are just like any other class

Um. That's not the same at all. Symbols themselves are immutable.
The Symbol Class is not immutable.

Yes, this means that someone could override #to_s on Symbol to do
something else entirely, but Symbols themselves are immutable -- and
they cannot have virtual (singleton) classes:

irb(main):001:0> foo = :foo
=> :foo
irb(main):002:0> class << foo
irb(main):003:1> end
TypeError: no virtual class for Symbol
from (irb):2
irb(main):004:0>

There is a significant difference between the two sorts of
immutability that you would be advised to understand before even
thinking of attempting to implement a VM to support Ruby.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca

Austin Ziegler

1/14/2005 2:32:00 PM

0

On Fri, 14 Jan 2005 03:48:58 +0900, Mystifier
<mystifier@users.berlios.de> wrote:
> No, I am not trying to create another java, but as Users, how many
> times have you mutated your strings?

All the time.

I'm working on Text::Format again to get it cleaned up for a 1.0
release, and it does:

line << " " if sentence_end and extra_space
line << " #{next_word}"

There's your mutable strings. They are a necessary component of most
languages that do a lot of string manipulations. (Most of my
projects end up doing quite a bit of string manipulation; Ruwiki
uses a lot of gsub! calls, no less.)

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca

Mystifier

1/14/2005 3:05:00 PM

0

Dear Austin,

Immutability as I understand is preserving state of the Object. State of
Object are instance variables in Ruby. My example does sot change class
variables, but the instance variable. Symbol class being immutable or not is
besides the point. I am talking about symbol instance, and ability to change
symbol instance variables makes them not immutable as such. Yes, the
sequence of chars they represent are immutable. Hence, I get an impression
that the Symbol is a immutable string class.

About learning things before writing VM, I am sure I have to. What I feel No
VM or Interpreter can exists with reasonable performance with have an
immutable string class. It is altogether a different matter what you call
them.



-----Original Message-----
From: Austin Ziegler [mailto:halostatue@gmail.com]
Sent: Friday, January 14, 2005 7:59 PM
To: ruby-talk ML
Subject: Re: Mutable strings


On Fri, 14 Jan 2005 14:00:07 +0900, Mystifier <mystifier@users.berlios.de>
wrote:
> Dear Charles,
>
> I have no intensions of changing the language APIs for it really does
> not matter to a VM Implementation. All the components that inherently
> affects the VM implementations are those that VM uses natively like
> File, Strings, Numbers and Threads.
>
> I surprisingly found Symbols are exactly not Immutable...., they are
> just like any other class

Um. That's not the same at all. Symbols themselves are immutable. The Symbol
Class is not immutable.

Yes, this means that someone could override #to_s on Symbol to do something
else entirely, but Symbols themselves are immutable -- and they cannot have
virtual (singleton) classes:

irb(main):001:0> foo = :foo
=> :foo
irb(main):002:0> class << foo
irb(main):003:1> end
TypeError: no virtual class for Symbol
from (irb):2
irb(main):004:0>

There is a significant difference between the two sorts of immutability that
you would be advised to understand before even thinking of attempting to
implement a VM to support Ruby.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca

Austin Ziegler

1/14/2005 4:01:00 PM

0

On Sat, 15 Jan 2005 00:04:39 +0900, Mystifier
<mystifier@users.berlios.de> wrote:
> Immutability as I understand is preserving state of the Object.
> State of Object are instance variables in Ruby. My example does
> sot change class variables, but the instance variable. Symbol
> class being immutable or not is besides the point. I am talking
> about symbol instance, and ability to change symbol instance
> variables makes them not immutable as such. Yes, the sequence of
> chars they represent are immutable. Hence, I get an impression
> that the Symbol is a immutable string class.

Yes. The intrinsic value of a symbol is immutable -- and it doesn't
have support for virtual classes; the fact that it's an Object like
everything else, though, says that it can have additional methods or
even instance variables added at any time.

> About learning things before writing VM, I am sure I have to. What
> I feel No VM or Interpreter can exists with reasonable performance
> with have an immutable string class. It is altogether a different
> matter what you call them.

And I think that the existence of Ruby -- which is quite performant
for a lot of people -- suggests otherwise.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca