Traits or not Traits that is the question

>
>
> El 2/5/08 2:37 AM, "Yoshiki Ohshima" <[hidden email]> escribió:
>
> >   I just modified two lines in Scanner and now you can use left arrow
> > for assignment.  (Which is not for the first time and has been done by many.)
> >
> >   In the attached picture, variable "a" gets 10 and the assignment
> > symbol is U+2190 (taken from a Japanese font).  Variable "b" gets "a *
> > 3" and the assignment is traditional one.
> >
> >   As for input the character, it doesn't have to be a single
> > keystroke.  What I suggested here:
> >
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/085348.ht
> > ml
> >
> > got implemented as announced here:
> >
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-April/115513.html
> >
> > -- Yoshiki
>
>
> Any against having the Yoshiki modifications in the next Squeak image ?
>
>
>
>

> Paul D. Fernhout wrote:
> > Andreas Raab wrote:
> >> Paul D. Fernhout wrote:
> >>> So, for the 21st century, Squeak gets underscore *wrong*.
> >>>   http://en.wikipedia.org/wiki/ASCII
> >>>
> >>> And for a dozen years. Every knows it is wrong. There was even a recent
> >>> discussion on it. It still can't be fixed!
> >> Sure it can. Croquet fixed it.
> >
> > That's exactly my point. :-) Why only Croquet (or some other images)?
>
> Because you need authority to make certain changes and these changes
> certainly will be seen as controversial by some. And no, that's not your
> point as far as I can tell - unless your point is that there is no
> unambiguous authority for Squeak today (which I agree).
>
> Cheers,
>    - Andreas
>

> > As regards a given release, it seems to me the authority is fairly
> > clear: the release team and perhaps more specifically the release team
> > leader.  At that point of course the release team is in the position of
> > having to guage the community's reaction to a change.  And here is where
> > I think we have trouble in practice.  Our current methodology is to
> > listen to the vocal minority (those who actually go to the trouble to
> > post to squeak-dev or reply to the submitter).  My experience has been
> > that it is those who feel negatively about something that feel most
> > compelled to respond.  Correspondingly I strongly suspect there is a
> > significant minority (at least) who is quite happy with the idea but
> > either can't be bothered to respond or don't feel their opinion is
> > relevant; then there's another quite possibly larger group who have no
> > real opinion.
> >
> > Within this community I've come to feel that the only day to day
> > practical solution is to do it and then ask for forgiveness when it goes
> > all pear shaped (badly).  Of course when that happens it really helps
> > when it is something that can be readily reversed with no harm done.
> > And that's where it seems we have a problem because the current release
> > management schemes don't well-support removing something readily and in
> > such a way that few if any are inconvenienced.  I don't have a ready
> > solution to that, it is something I find myself thinking about more and
> > more.
> >
> > In the interim it seems to me that each release team has to make the
> > choice.  They can either take a chance, make a change simply based on
> > the vocal few and prepare for possible flames at a later date.  Or in
> > cases where it seems desirable, go to a little more trouble and call for
> > a semi-formal vote.  Clearly that's not something any of us want to do
> > every week.  But I don't think it would be that big of a deal to do it a
> > few times a year.  Details would need to be worked out but I think it
> > would not be all that difficult and would be easier each time we did it.
> >
> > I have other thoughts on this and related issues, but I find myself
> > getting more and more annoyed with long emails, and this one is already
> > over the threshold,
> >
> > Ken
> >
> There is a solution: enable multiple versions of same package in same
> image and keep track of package dependency.
> So, when you loading an updated package, all code which worked before,
> continues to work in same way as it was before.
> We need a way to be able developer to choose, what parts of system can
> use new version and what should use older version due to
> incompatibility reasons by simply checking dependencies and updating
> dependency links.