rename #toString......... again

[GoogleCodeExporter]

Discussion at ESUG suggests #toString is going to conflict with other code.

#asSeasideString or similar was suggested.

Original issue reported on code.google.com by [email protected] on 28 Aug 2008 at 12:47

[GoogleCodeExporter]

What about #seasideAsString or #waAsString?

Original comment by [email protected] on 28 Aug 2008 at 1:40

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by [email protected] on 29 Aug 2008 at 7:23

• Added labels: Priority-Critical, Version-Seaside2.9
• Removed labels: Priority-Medium

[GoogleCodeExporter]

How would #toString conflict with other code?

Original comment by [email protected] on 29 Aug 2008 at 10:17

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Niall and John did a quick examination of VW, the dialect that dislikes 
Object>>asString.  The problem is a couple of methods on GenericException that 
do 
not know whether an evaluable object (probably a block) has been passed in or a 
String-like object.  Object already responds to value (thanks to the Squeak 
porting 
layer) so they use whether the instance responds to asString to distinguish the 
two 
classes of object.

This should be changed to eliminate respondsTo: in favour of isEvaluable or 
similar.  Niall will raises this as a possible 7.7 fix;  for something as 
fundamental as exceptions, it may not be a quick patch earlier but watch this 
space.

First cut summary, to be reviewed, is:
- endure another method name
- expect to rename back to asString when VW can endure that

Original comment by [email protected] on 29 Aug 2008 at 1:12

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This is fixed in upstream.

All affected packages have been committed with the comment: "- #toString 
renamed to #seasideString"

Original comment by renggli on 30 Aug 2008 at 2:32

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****