NanoTraits are go

Folks -

NanoTraits are ready to ship now. I've decided on a loading mechanism
which preserves the original Trait classes in the image and reshapes
them instead of having a different set of classes. This achieves maximum
compatibility with external packages. The loading is done by first
loading NanoTraits, converting all traits, reshaping the existing
classes, and converting everything back. If you have a fully updated
image, you can try the process by executing:

        MCMcmUpdater updateFromRepositories: #(
                'http://www.squeaksource.com/NanoTraits'
        ).

I decided to preserve *all* of the original structure (incl. class
TraitBehavior and incl. all of the Kernel traits) since I noticed that
various packages have extensions on those classes and would fail to load
otherwise. This should provide very good backward compatibility for
external packages.

Unless people voice concerns about this version I'll be pushing it into
the trunk over the next couple of days.

Finally, we can measure the differences between the implementations more
accurately, for example:

Measure 1: Complexity of Kernel-Classes and Traits
--------------------------------------------------

#('Traits' 'Kernel-Classes' ) do:[:pkgName| | pkg |
     pkg := PackageInfo named: pkgName.
     Transcript cr; show: pkg name;
         tab; show: pkg classes size;
         tab; show: pkg methods size.
].

Before                  Classes       Methods
Traits                    59            873
Kernel-Classes            10            468
Total                     69           1341

After                   Classes       Methods
Traits                    27(*)         188
Kernel-Classes            10            589
Total                     37(*)         777

(*) includes 17 otherwise unused compatibility traits

Measure 2: Complexity of Behavior
---------------------------------

{Behavior. ClassDescription. Class. Metaclass}
     collect:[:each| each -> each selectors size].

Version         Behavior   ClassDescription    Class Metaclass Total
3.10              244            141             88     48     521
After             190            161             82     44     477

Cheers,
   - Andreas

>>>>> "Andreas" == Andreas Raab <[hidden email]> writes:

Andreas> I decided to preserve *all* of the original structure (incl. class
Andreas> TraitBehavior and incl. all of the Kernel traits) since I noticed
Andreas> that various packages have extensions on those classes and would fail
Andreas> to load otherwise. This should provide very good backward
Andreas> compatibility for external packages.

"Egg-sellent!" </voice style="Egghead from Batman">

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

On Tue, Dec 29, 2009 at 09:58:34PM +0100, Andreas Raab wrote:
>
> Unless people voice concerns about this version I'll be pushing it into
> the trunk over the next couple of days.

The only thing that I would want to check - and apologies for my ignorance
here - is backward compatibility with regards to image segments. My
recollection is that Squeak 3.9 broke all kinds of things, including
SqueakMap and EToys projects, as a result of incompatibilities associated
with the introduction of traits into the image. So I would just want to
make sure that NanoTraits does not introduce further incompatibilities
that might make it more difficult to support EToys projects in the future.

> Finally, we can measure the differences between the implementations more
> accurately, for example:

Outstanding. Simplifying traits can only be a good thing, regardless of
how much or how little they may be used in practice.

Dave
 

On Tue, 29 Dec 2009, Andreas Raab wrote:

> After                   Classes       Methods
> Traits                    27(*)         188
> Kernel-Classes            10            589
> Total                     37(*)         777
>
> (*) includes 17 otherwise unused compatibility traits

These 17 Traits seem to be empty (no methods). Is that intentional?


Levente

ClassDescription , Metaclass ivars:
  traitComposition localSelectors
has no uses.

Andreas using a TraitMethodProperties to hold a reference to original
method, and then to trait. So, its easy to tell whether method is
local or not, by asking it, without need of keeping a separate state.
I find such approach less error prone, since method is the unit of
manipulation for traits and asking it directly, where it came from is
more appropriate. And sure thing, copying method over multiple method
dicts, does not require you to care about keeping something else in
sync (except categorizer, maybe).

--
Best regards,
Igor Stasenko AKA sig.

Levente Uzonyi wrote:
Yes, that's intentional. It appears that there may be external packages
that define extension methods on those traits. I've actually not found a
current example but there were some *foo categories in various images I
looked at and consequently it felt safer to keep them. I think we should
deprecate those traits over time.

Cheers,
   - Andreas

David T. Lewis wrote:
> The only thing that I would want to check - and apologies for my ignorance
> here - is backward compatibility with regards to image segments. My
> recollection is that Squeak 3.9 broke all kinds of things, including
> SqueakMap and EToys projects, as a result of incompatibilities associated
> with the introduction of traits into the image. So I would just want to
> make sure that NanoTraits does not introduce further incompatibilities
> that might make it more difficult to support EToys projects in the future.

Yes, a very good point. The changes that I'm making make Etoys and
Squeak *more* compatible, not less. As Igor was pointing out I have been
pushing various bits of state that were scattered around all over the
places (in some cases duplicated in *three* places) into separate
entities: TraitOrganizer and TraitMethodState. Those are only used when
you actually use traits, and as a consequence, when you don't use traits
the structure is identical to Etoys and consequently image segments will
work fine.

So at least this level of incompatibility will cease to exists. Oh, and
score one more point for delegation over inheritance.

Cheers,
   - Andreas

On 2009-12-30 14:35, Andreas Raab wrote: How about Tweak and NanoTraits ?

Karl

Karl Ramberg wrote:
> How about Tweak and NanoTraits ?

The problem with Tweak was more the obfuscation of the compiler
interface by traits (i.e., the use of traits in Behavior and friends).
Fortunately, Eliot took care of the problem earlier when he merged the
various compilers. I haven't announced this yet (since it's not
complete) but I've done a maintenance release of Tweak on Squeaksource.
To install, fetch a recent trunk image (I've used
http://ftp.squeak.org/trunk/Squeak3.11-8472-alpha.zip),and execute:

MCMcmUpdater updateFromRepositories: #(
     'http://squeaksource.com/TweakCore'
).

CProjectMorph open: CSampleApp.

This is the bare minimum and fairly close to what we use in our
products. The second part includes all the scripting and project builder
bits (I apologize for the error handler, I still need to fix that):

[MCMcmUpdater updateFromRepositories: #(
     'http://squeaksource.com/TweakExtras'
)] on: CUnsynchronizedModification do:[:ex| ex resume].

CProjectMorph open: CProjectBuilder.

You'll find that in the extras there are still various things broken
that I haven't looked at yet.

Cheers,
   - Andreas

On Wed, Dec 30, 2009 at 02:35:22PM +0100, Andreas Raab wrote:
> David T. Lewis wrote:
> >So I would just want to
> >make sure that NanoTraits does not introduce further incompatibilities
> >that might make it more difficult to support EToys projects in the future.
>
> Yes, a very good point. The changes that I'm making make Etoys and
> Squeak *more* compatible, not less.

Well then bravo! and please proceed.

Dave