[Seaside-dev] Re: Seaside2.8a1-mb.487

James Robertson jrobertson at cincom.com
Mon Oct 1 17:13:22 UTC 2007


I can't really speak to historical Seaside use, but in terms of VW, 
#displayString has never been considered to be a conversion method.  In 
general, the theory of operation has been:

#displayString -- send to an object to get a string/text object for use in a 
UI widget

#printString -- send to an object to get a string for use in a dev tool (eg, 
an inspector).

#asString  -- This one is the conversion method, but it's not implemented 
everywhere in VW - for instance, it's not in Object, and putting one there 
can be problematic.

I'm not sure this helps - I'm just trying to exlain the VW based background.

----- Original Message ----- 
From: "Philippe Marschall" <philippe.marschall at gmail.com>
To: "Seaside - developer list" <seaside-dev at lists.squeakfoundation.org>
Sent: Monday, October 01, 2007 12:42 PM
Subject: Re: [Seaside-dev] Re: Seaside2.8a1-mb.487


> 2007/10/1, Bany, Michel <mbany at cincom.com>:
>> > > I do not see #displayString as a conversion method but rather as a
>> > > method that produces string representations of objects for the user
>> > > interface, somehow similar to #printString. Also, using
>> > #displayString
>> > > is a little more than a convention. VW does not and cannot have
>> > > #asString implemented in Object, therefore using  something
>> > else than
>> > > #asString for getting string representations of objects was an
>> > > obligation in order to make Seaside portable, rather than a
>> > > convention. See below the (nearly) complete story as to why Seaside
>> > > uses #displayString.
>> >
>> > So basically neither #displayString nor #asString will ever work.
>> > Which just means we will have to introduce our own method for
>> > string conversion that is used by no other Smalltalk (or wait
>> > for ANSI, *jk*). This doesn't really take me by surprise to
>> > so I have a concrete
>> > proposal: #toString. Yes, it's Java-esque but this is good
>> > thing since it means that we have no conflicts with existing dialects.
>>
>> Again, #displayString is not intended as a string conversion method,
>> but as a method for displaying an object to the user interface. When
>> you need a string conversion method use #asString. When you need a
>> displayable string for an object use #displayString. Most of the time
>> the result will be the same, but the intentions are different.
>
> Wow, that is a huge change to the current system. Today we use
> #displayString as a conversion method because we have been told again
> and again that we can not use #asString as a reliable string
> conversion method on VW. To make matters worse in some cases (again on
> VW) #displayString does actually not return a String but a Text. There
> is a very fine distinction between 'for conversion' and 'for display'.
> Going through the roughly hundred senders of #displayString we have
> for many of them I can't say which one it should be. Wasn't Smalltalk
> about making simple things simple?
>
>> So why no just accept the change I suggested to #asFilename: where
>> we do not want to display anything to the user interface and where
>> we clearly need to convert a selector Symbol to a String.
>
> Because it is extremely inconsitent. We use #displayString everywhere
> but there as a conversion method.
>
> Cheers
> Philippe
>
>> asFilename: aSelector
>>         | dotIndex extension |
>>         dotIndex := self lastUpperCaseIndexIn: aSelector.
>>         dotIndex = 0
>>                 ifTrue: [^ aSelector asString].
>>         extension := (aSelector last: aSelector size - dotIndex + 1)
>> asLowercase.
>>         ^ (aSelector first: dotIndex - 1)
>>                 , '.' , extension
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> 



More information about the seaside-dev mailing list