Smalltalk › Redline Smalltalk

String questions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Lee Breisacher-2

String questions

I thought I would try to tackle String next (then maybe go back to Behavior, Class, etc).

First thing I run into is #new: and #at: and primitives in general.

String new: fails with DNU, so I added new: class method to String. Now it works, but I'm not sure I'm really getting a legitimate object with a Java String behind it. I can do at:put: and subsequent at: but am I really operating on a Strng? Also, when I try #at: on a string literal, I get a ClassCastException. Oh wait, Java Strings are immutable. Hm, have you thought much about Smalltalk strings vs. Java Strings and related classes such as StringBuffer? If not, I suppose this is my opportunity to dig into the internals a bit more?

Also, I glanced at Primitives.java (for example, I was looking for prim #63 which is String>at: in the Blue Book), and I noticed (1) none of the pNN methods have comments indicating which primitive they are, (2), some of the primitives with "real" implementations (e.g. p62) have a "// does this primitive make sense for Redline?" comment.

I haven't put my name by String in OBJECTS-AND-PROTOCOLS yet -- want to see if I can make any real progress first.

Thanks,

Lee

James Ladd

Re: String questions

Im digesting this and will post a response soon.
Most likely we need to change the underlying java object to something that supports the string operations.

On Sun, Jan 1, 2012 at 5:20 AM, Lee Breisacher <[hidden email]> wrote:

I thought I would try to tackle String next (then maybe go back to Behavior, Class, etc).

First thing I run into is #new: and #at: and primitives in general.

String new: fails with DNU, so I added new: class method to String. Now it works, but I'm not sure I'm really getting a legitimate object with a Java String behind it. I can do at:put: and subsequent at: but am I really operating on a Strng? Also, when I try #at: on a string literal, I get a ClassCastException. Oh wait, Java Strings are immutable. Hm, have you thought much about Smalltalk strings vs. Java Strings and related classes such as StringBuffer? If not, I suppose this is my opportunity to dig into the internals a bit more?

Also, I glanced at Primitives.java (for example, I was looking for prim #63 which is String>at: in the Blue Book), and I noticed (1) none of the pNN methods have comments indicating which primitive they are, (2), some of the primitives with "real" implementations (e.g. p62) have a "// does this primitive make sense for Redline?" comment.

I haven't put my name by String in OBJECTS-AND-PROTOCOLS yet -- want to see if I can make any real progress first.

Thanks,

Lee

Lee Breisacher-2

Re: String questions

Just one quick (not very deep) thought: Perhaps we could back a Smalltalk String with an ordinary Java String that can "morph" itself into a mutable StringBuffer when at:put: (or similar) is called. Sortof like the CopyOnWriteArray classes in Java.

James Ladd

Re: String questions

Exactly, or it could be a string buffer all the time, since output will to string it
Sent from my iPhon

On 01/01/2012, at 11:22 AM, Lee Breisacher <[hidden email]> wrote:

> Just one quick (not very deep) thought: Perhaps we could back a Smalltalk String with an ordinary Java String that can "morph" itself into a mutable StringBuffer when at:put: (or similar) is called. Sortof like the CopyOnWriteArray classes in Java.

Robert Roland

Re: String questions

My suggestion would also be to use StringBuffer exclusively. ToString
it when necessary.

On Dec 31, 2011, at 5:28 PM, James Ladd <[hidden email]> wrote:

> Exactly, or it could be a string buffer all the time, since output will to string it
> Sent from my iPhon
>
> On 01/01/2012, at 11:22 AM, Lee Breisacher <[hidden email]> wrote:
>
>> Just one quick (not very deep) thought: Perhaps we could back a Smalltalk String with an ordinary Java String that can "morph" itself into a mutable StringBuffer when at:put: (or similar) is called. Sortof like the CopyOnWriteArray classes in Java.

Lee Breisacher-2

Re: String questions

A nit: Actually, StringBuilder is preferred over StringBuffer these days.

Robert Roland

Re: String questions

I get the two of them backwards, name-wise, every time.

On Jan 1, 2012, at 8:59 AM, Lee Breisacher <[hidden email]> wrote:

> A nit: Actually, StringBuilder is preferred over StringBuffer these days.