Need feedback on simple idea

PhiHo Hoang phiho.hoang at rogers.com
Sat Apr 12 09:40:26 UTC 2003


> Of course, I suppose one could argue that we should fork off a Squeak
> image to become Eek, a Smalltalk,

    Nah! Make it eTalk or kRocket ;-)

> while Squeak moves on to become something else...
>
> Nah!  :-)

    Why nat ;-)

    Cheers,

    PhiHo.

----- Original Message ----- 
From: "Donald Major" <Donald.Major at sas.com>
To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, April 11, 2003 2:34 PM
Subject: Re: Need feedback on simple idea


> I have what I consider a better reason not to want to see the suggested
> idea researched in the public core Squeak code -- I use Squeak because
> it's free (important to me) and Smalltalk (more important to me) -- NOT
> some other language, like Self.  From postings I've seen, both for this
> thread and (much) earlier ones, I gather that any time I want to program
> with Self, I can download an image and start hitting keys.  But I don't
> want to program in Self, I want to program in Smalltalk, and Squeak fits
> that model closely enough for my purposes.
>
> Conversely, I see nothing wrong with *forking* a copy of the public core
> Squeak code, making the changes suggested for the research, and making
> it publically available as something else, such as "Eek" or "Squawk", or
> whatever, and setting up "Eek" web sites, Eek discussion lists, and
> encouraging Eek porting efforts.  I might even subscribe myself, and
> after a while might even think it worth my time to drop Squeak in favor
> of Eek.  I just think that despite the intent of Alan Kay, Dan Ingalls
> and company to do research with Squeak as a starting point, in both
> "pink" and "blue" planes of  endeavor, Squeak-as-a-Smalltalk has too
> much momentum to change into Squeak-as-a-something-else -- unless a
> relatively clean break is made to create something like
> Eek-as-something-other-than-Smalltalk.
>
> And of course, what anyone does in the privacy of their own personal
> Squeak (or Eek) image is their own business, and I have no objections to
> research conducted therein at all.
>
> Of course, I suppose one could argue that we should fork off a Squeak
> image to become Eek, a Smalltalk, while Squeak moves on to become
> something else...
>
> Nah!  :-)
>
> Stephen Pair wrote:
>
> > Nathanael Schärli wrote:
> >
> >> Hi Martin,
> >>
> >>
> >>
> >>> But you loose something, namely encapsulation. Every object outside
> >>> morph can screw the state of this morph, without doing 'more' to it,
> >>> meaning this morph will be put in an unvalid state.
> >>>
> >>
> >>
> >> I think that the argument about "loosing encapsulation" is complete
> >> bogus because it has no relevance in practice. In fact, encapsulation
> >> means:
> >>
> >
> > [lot's of good stuff snipped]
> >
> > I totally agree with Nathanael's comments...looking at instance
> > varaibles as if they were somehow untouchable or private is the wrong
> > way of looking at it.  It's very similar to the argument in favor of
> > having public/protected/private methods.  First, you can always get an
> > an object's inst vars using #instVarAt:(put:)...so any argument that
> > there is encapsulation is wrong.  There isn't.  There's just some
> > notion that gives the user of the class some idea of what's safe and
> > what's not safe to do.  I tend to view the notion of
> > public/protected/private methods as a feeble attempt at classifying
> > methods based on how likely it is that their interface will change
> > over time (private being the most likely, public being the least).
> > Similarly, an instance variable without direct getters/setters is
> > simply a comment saying "don't directly get or set this inst var, or
> > if you do, then be prepared to accept the consequences when I release
> > my next version."
> > Encapsulation is really only achieved by responsible usage of the
> > interfaces exposed by a class.
> > So, to say that you're losing encapsulation is simply not accurate.
> > You might be loosing some interface notational capability, but you are
> > not losing encapsulation because you cannot lose what you never had in
> > the first place.
> >
> > - Stephen
> >
> >
> >
> >
>
> -- 
>  .. Donald Major "Tech Support..your Windows machine doesn't
> dtm SAS Institute Inc. work?  Have you tried installing a Macintosh?"
> Cary, NC 27513 - me          SAS - "The Power to Know"
> AKA "Ol' Baby Lee"
>
>
>



More information about the Squeak-dev mailing list