[squeak-dev] The Inbox: Collections-fbs.516.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu May 2 20:32:08 UTC 2013


Yes, what I mean is that we can live with simple hacks and don't need to
worrry whether it can be generalized or not, because we already know the
answer, it cannot in current form


2013/5/2 Frank Shearar <frank.shearar at gmail.com>

> On 2 May 2013 21:18, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
> wrote:
> > Anyway you can't cover much, storeString is very very limited to a few
> core
> > objects.
> > Even for the most simple objetcs, precedence is broken, just try
> 1->(1->2).
> > For Pharo, I made a utility based on generating AST and then printing it,
> > which work a bit further for simple objects.
> >
> > See SLICE-Issue-4943--Implement-printSelfEvaluating-with-AST-nice.3.mcz
>
> Agreed: the _proper_ solution is to work with ASTs. For the purpose of
> fixing the Trait issue, only the #printOn: part is vital. Excuse me
> while I boggle once again at that idea.
>
> frank
>
> > In http://ss3.gemstone.com/ss/PharoTreatedInbox.html
> > 2013/5/2 Frank Shearar <frank.shearar at gmail.com>
> >>
> >> On 2 May 2013 19:48, Frank Shearar <frank.shearar at gmail.com> wrote:
> >> > On 2 May 2013 19:15, Chris Muller <asqueaker at gmail.com> wrote:
> >> >> I like how your comment describes _why_ the change rather than what
> >> >> the change, since what would be redundant with the code.
> >> >>
> >> >> But it also gave me an idea -- whether it would be good to only space
> >> >> it out if it must; e.g., if key and/or value are binary selectors.
> >> >> Otherwise, maintian the traditional compact print.
> >> >>
> >> >> I have an app that makes heavy use of user-specified Arrays of
> >> >> Associations for parameterizing objects, which may be using their
> >> >> printString output.  Unless you'd like to take the above suggestion,
> >> >> I'd like to run with this for a couple of weeks, see how things look,
> >> >> before trunking it.  (A new verbification for you Tim!).
> >> >
> >> > I'd be happy to get the compact form back: I hemmed and hawed over
> >> > whether or not to do it, hence asking for, well, not _consensus_, but
> >> > sanity.
> >>
> >> As it happens, this commit breaks two tests. Chris, one possible way
> >> for getting the compact form back is to say something like
> >>
> >> storeOn: aStream
> >>     | arrow |
> >>     arrow := key isBinarySelector ifTrue: [' -> '] ifFalse: ['->'].
> >>     key storeOn: aStream.
> >>     aStream nextPutAll: arrow.
> >>     value storeOn: aStream
> >>
> >> and similarly for #printOn:.
> >>
> >> I dislike the conditional; I'm not _certain_ that it's sufficient to
> >> cover all the cases, and conditionals are always ugly.
> >>
> >> frank
> >>
> >> > frank
> >> >
> >> >> On Thu, May 2, 2013 at 3:46 AM, Frank Shearar <
> frank.shearar at gmail.com>
> >> >> wrote:
> >> >>> On 1 May 2013 22:14,  <commits at source.squeak.org> wrote:
> >> >>>> Frank Shearar uploaded a new version of Collections to project The
> >> >>>> Inbox:
> >> >>>> http://source.squeak.org/inbox/Collections-fbs.516.mcz
> >> >>>>
> >> >>>> ==================== Summary ====================
> >> >>>>
> >> >>>> Name: Collections-fbs.516
> >> >>>> Author: fbs
> >> >>>> Time: 1 May 2013, 10:14:23.588 pm
> >> >>>> UUID: e787006a-d096-47f3-93da-c4681285fae2
> >> >>>> Ancestors: Collections-ul.515
> >> >>>>
> >> >>>> Surrounding the -> in an Assocation in printed form allows the left
> >> >>>> side to be a binary selector without things breaking: #* -> #+
> otherwise
> >> >>>> prints as '#*->#+', which is the Symbol #*-> followed by garbage.
> >> >>>>
> >> >>>> =============== Diff against Collections-ul.515 ===============
> >> >>>
> >> >>> Just to be clear, you're +1'ing this change, Nicolas?
> >> >>>
> >> >>> (I didn't add tests for the Association >> #printString; I'll
> >> >>> understand if you demand these!)
> >> >>>
> >> >>> frank
> >> >>>
> >> >>
> >>
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130502/0199da24/attachment-0001.htm


More information about the Squeak-dev mailing list