2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2009/10/31 Igor Stasenko <siguctua at gmail.com>:
>> 2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> 2009/10/31 Bert Freudenberg <bert at freudenbergs.de>:
>>>>
>>>> On 30.10.2009, at 19:13, Nicolas Cellier wrote:
>>>>
>>>>> 2009/10/30 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>>>>
>>>>>> 2009/10/30 Eliot Miranda <eliot.miranda at gmail.com>:
>>>>>> currently it is a 3 stages rocket:
>>>>>>
>>>>>> Array with: 1. -> #(1)
>>>>>> Array with: 1 at 2. -> {1 at 2}
>>>>>> Array with: OrderedCollection new. -> an Array(an OrderedCollection())
>>>>>>
>>>>>>> prints as { OrderedCollection () } than #(OrderedCollection ()).  The
>>>>>>> first
>>>>>>> is a syntax error but the second is completely ambiguous (i.e. evaluates
>>>>>>> to
>>>>>>>  #(#OrderedCollection #())).
>>>>>>> So I don't see the need to provide isSelfEvaluating.  isLiteral gives
>>>>>>> you
>>>>>>> all that you need to avoid printing an Array as a literal when it isn't.
>>>>>>>  And if you've drunk the braces kool aid (which I have, while studying
>>>>>>> my
>>>>>>> agrippa) you're happy with Arrays printing themselves as brace
>>>>>>> constructs
>>>>>>> naively even when the naive print produces non-code.
>>>>>>
>>>>>> That's a fair and simple approach.
>>>>>>
>>>>>
>>>>> I gave it a try, now every Array print as #( ... ) if literal, { ... }
>>>>> otherwise
>>>>> Please vote
>>>>
>>>> I like the self-evaluating print string. It's useful for interactive use and
>>>> debugging. Plus shorter, usually.
>>>>
>>>> - Bert -
>>>>
>>>
>>> Hi Bert,
>>>
>>> You don't loose it.
>>> Array that previously printed as literal #( .. ) still do
>>> Array that previously printed with braces { .. } (isSelfEvaluating) still do.
>>> Array that did print anArray( ... ) now print using { ... }
>>> So, you only loose quick identification of Array that can't be
>>> re-evaluated to itself
>>>
>>> Note that isSelfEvaluating is plenty implementors for 1 sender, and
>>> was not correct anyway, and would be overkill to correct
>>> A killing example:
>>>    (Array with: (0 at 0 extent: 1 at 1) -> 0)
>>> So that was the rationale to trade off quick identification
>>>
>>> Is this acceptable ?
>>>
>>>
>>
>> My 2 cents.
>>
>> Again, this #isXXXX pattern..
>> As someone noted before: don't ask - tell.
>> If array wants to print itself as an array literal, why not tell all
>> its elements to print as literals inside the array?
>> Something like
>> #printAsLiteralOn:
>> which prints the object on stream, and returns a boolean which is
>> false if printed result can't be represented as a literal inside
>> array.
>> Then a wrapping #printOn: can choose to use {} syntax, if any of
>> elements failed to print as pure literal.
>>
>>
>
> Yes, and printing seems almost sole use of #isLiteral.
> but that would also mean rewinding the stream
> (or duplicating the print on a temporary stream if we care of non
> positionable streams)
> and I'm not sure it's particularly more simple/expandable/readable
>
yes, if goal is to provide an efficient implemenation, then some tests
would be better.

The problem with isXXX pattern that its often hides the real intent of
developer, for what purposes this test
is used.
A more explanatory selector can be choosen, like
#canBePrintedAsLiteral, then there will be no confusion
whether such method useful or not and for what purpose.

Personally, i assumed that isLiteral test exists for quite different
purpose - to test whether a given object
is  (or can be) referenced inside one of compiled methods literal
frame. So, then some code could test and avoid modifying the literal
arrays, or other compound literal objects, which should be immutable,
because as we know Squeak VM don't provides immutability flag for
objects.

> Beware, someone clever might refactor #printAsLiteralOn: code as
> printAsLiteralOn: aStream
>  self isLiteral [^false].
>  self printOn: aStream.
>  ^true
>
> Or another clever one would implement missing generic #isLiteral
> isLiteral
>   ^self printLiteralOn: Stream null
>
> Just kidding
>
Yeah :)
But seriously, it is important to choose carefully the message
selector, to avoid confusion and abuses.

> Nicolas
>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.