New to PHP 5.4: Traits

http://simas.posterous.com/new-to-php-54-traits

really really excellent!


On Nov 21, 2010, at 12:22 PM, jaayer wrote:

> http://simas.posterous.com/new-to-php-54-traits
>
>

---- On Sun, 21 Nov 2010 04:22:51 -0800 Stéphane Ducasse  wrote ----

>really really excellent!

Excellent that other, lesser languages like PHP, Perl 6 and Scala have already adopted and standardized Traits while the reactionaries in the Smalltalk community still resist doing the same?

>
>On Nov 21, 2010, at 12:22 PM, jaayer wrote:
>
>> http://simas.posterous.com/new-to-php-54-traits 
>>
>>
>
>
>

Hi:

On 21 Nov 2010, at 21:47, jaayer wrote:
> Excellent that other, lesser languages like PHP, Perl 6 and Scala have already adopted and standardized Traits while the reactionaries in the Smalltalk community still resist doing the same?
Ignoring all the sarcasm in that comment:
I don't see any form of standardization here. I am not aware that any of the other existing PHP implementations has picked up Traits so far.

And well, it is about 3 years from the first implementation to a first release in an official alpha version of PHP. There is still a loooong way to go...

Best regards
Stefan


--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525

---- On Sun, 21 Nov 2010 13:06:35 -0800 Stefan Marr  wrote ----

>Hi:
>
>On 21 Nov 2010, at 21:47, jaayer wrote:
>> Excellent that other, lesser languages like PHP, Perl 6 and Scala have already adopted and standardized Traits while the reactionaries in the Smalltalk community still resist doing the same?
>Ignoring all the sarcasm in that comment:
>I don't see any form of standardization here. I am not aware that any of the other existing PHP implementations has picked up Traits so far.

PHP has no standard; the implementation is the standard, and Traits are being added to the implementation, hence, "standardization." My point remains; other languages are or have already adopted Traits while the Smalltalk community, from which the concept sprang, continues to drag its heels after nearly a decade since their introduction.

>And well, it is about 3 years from the first implementation to a first release in an official alpha version of PHP. There is still a loooong way to go...

No, there isn't, at least not compared with the rate of Smalltalk's adoption of Traits. Face it. There are just too many Smalltalkers who seem to think the language is a complete revelation that no mortal has the right to amend. Other languages can grow to accommodate new features; Smalltalk, which went through a number major revisions in the 70s at PARC, remains frozen in the amber of 1980.

Am 21.11.2010 um 22:53 schrieb jaayer <[hidden email]>:
> ... the Smalltalk community, from which the concept sprang, ...

Self, right? And "Self includes: Smalltalk". ;-)

Best,

Michael

for the record we know that and our traits are not the same as we mentioned in our paper. We went back on pre self traits of 1981!
So I'm not even sure that self papers refers to this work.

stef

On Nov 22, 2010, at 6:43 AM, Michael Haupt wrote:

:)
You are somehow right :).
Now some points if you want to help:
        - I would love to have more support for traits in pharo
                        - using them
                        - improving tool support
                        - revisiting their implementation: this is on my todo since andreas (with a certain marketing effect) "cleaned"
                        the version of squeak.
                                - one question there is can we make traits pluggable on top of the core and does it make sense.

        - we want other features like modules but but but but but
        but but but but we want to have the time to work and try out ideas (this is 8 years - yes I'm slow that we
        started with classboxes - and classboxes does not look like the solution)
                        - now the first step in that direction that we started in 2002 (but people did not understand it :))
                        was to clean all the smalltalk reference
                        - now we are working on making sure that we can have multiple systemDictionaries side by side
                                it will support not only module design exploration but
                                        - OOPAL bootstrap
                                        - atomic loading (like in VW)
                                        - Moose analysis (ie Moose/pharo1.1 should be able to analyse Moose/pharo1.3 unstable)
                                        - remote debugging/development

Now my problem is time.
So if people want to help please contact us and we could have a lot of fun.

stef

On Nov 21, 2010, at 10:53 PM, jaayer wrote:
>>
>
> No, there isn't, at least not compared with the rate of Smalltalk's adoption of Traits. Face it. There are just too many Smalltalkers who seem to think the language is a complete revelation that no mortal has the right to amend. Other languages can grow to accommodate new features; Smalltalk, which went through a number major revisions in the 70s at PARC, remains frozen in the amber of 1980.


I think there are two forces at work:

1) Those that block any change because Smalltalk is not supposed to be changed by mortals.

2) Those that want to go "beyond Smalltalk". But it has to be perfect!  So better do nothing.
    (Aka: The Squeak Desease). This is the far greater problem.

Point 2 actually has fractal properties. You can see it at all scales. From the small. (Why fix a typo when you want to do something oh-so-great!)
up to the big picture. The old man story. One can not quote this too often:

"One of the sad memories of my life is a visit to the celebrated  
mathematician and inventor, Mr Babbage. He was far advanced in age,  
but his mind was still as vigorous as ever. He took me through his  
work-rooms. In the first room I saw parts of the original Calculating  
Machine, which had been shown in an incomplete state many years before  
and had even been put to some use. I asked him about its present form.  
'I have not finished it because in working at it I came on the idea of  
my Analytical Machine, which would do all that it was capable of doing  
and much more. Indeed, the idea was so much simpler that it would have  
taken more work to complete the Calculating Machine than to design and  
construct the other in its entirety, so I turned my attention to the  
Analytical Machine.'"

"After a few minutes' talk, we went into the next work-room, where he  
showed and explained to me the working of the elements of the  
Analytical Machine. I asked if I could see it. 'I have never completed  
it,' he said, 'because I hit upon an idea of doing the same thing by a  
different and far more effective method, and this rendered it useless  
to proceed on the old lines.' Then we went into the third room. There  
lay scattered bits of mechanism, but I saw no trace of any working  
machine. Very cautiously I approached the subject, and received the  
dreaded answer, 'It is not constructed yet, but I am working on it,  
and it will take less time to construct it altogether than it would  
have token to complete the Analytical Machine from the stage in which  
I left it.' I took leave of the old man with a heavy heart."

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Really cool! Thanks Stefan for your work!

Alexandre


On 21 Nov 2010, at 18:06, Stefan Marr wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Mon, 22 Nov 2010 10:45:30 +0100, Marcus Denker <[hidden email]>  
wrote:

1) Those that block any change because Smalltalk is not supposed to be  
changed by mortals.

2) Those that want to go "beyond Smalltalk". But it has to be perfect!  So  
better do nothing.
     (Aka: The Squeak Desease). This is the far greater problem.

<old man story snipped>

Marcus, you are so right! We should not wait to *share*
until what we have made is perfect (or fully functional,
or polished or some other excuse for not sharing).

Let me tell you a story of my own.

I was at a Smalltalk meeting in Cologne a little while ago
and it was my first time there and I did not know the people
there. I thought: let me, as a newcomer, try to contribute
in return for their organizing effort and hospitality.

So I said I would be happy to show some code (a class) that
I had written and that I used a lot and found very useful.
They said please show us, so I browsed the class and its
tests and a few examples and showed most of the code and
answered a few questions and we had a little discusion.

During the break a few guys said to me we should have more
of these presentations, where someone shows code. I said:
so why don't you do that more? And you know what the core
answer was? Everyone is more or less ashamed to show their
code because they think it is not very good.

Will you believe that I was very surprised to hear that THAT
was the problem? My own code, which I showed, was ugly, incomplete,
unfinished, inconsistent in places. But I knew that it had value,
because it implemented ONE valuable IDEA effectively. I had
been using it for several years and always just implemented
what I needed the code to do.

I didn't care that other people saw my unpolished code,
in fact I was happy and hoped they would give me some
inspiration to maybe improve it, or more motivation to
share it more widely than I had done.

So I agree, imperfect solutions have value and
please do not feel afraid to share what is not "perfect"!


BABBAGE

But the Babbage in the story had a point too. Continuing on
something that you know you can't finish seems irrational and
the fact that his replacement projects were also unattainable
does not mean that he should have continued with the old stuff.

If you work only for yourself, you can of course do what you want.


TRAITS/MIXINS

But what about these traits? I don't understand what all the
fuss is about. Wasn't the point of Traits that it is *sooo*
frustrating to have to duplicate all kinds of code in various
classes, which wouldn't be necessary in a multiple inheritance
language? And *sooo* frustrating that we would love to refactor
Collections and stuff but we can't because of we only have
subclass inheritance?

But full-fledged multiple inheritance is too much work, too
big a step, or we could never agree on the semantics/details...


And isn't there a problem in that the browsers expect classes
and not traits and that it is too much work to change the tools,
expecially as they are moving targets?


If these are really the problems, then why can't we simply
allow a class to mix in another class? Could that be a 70%
(imperfect) solution, for 10% of the effort?

Class1 mixIn: Class2


CONFLICTS CANNOT EXIST

Class2 must be suitable to be mixed in with Class1 or the
operation fails. If it succeeds, the definition of the
second class is merged into that of the first.

If we change either class, these changes are acceptable only
if the two classes remain compatible for mixing and the
compiler must take into account the dependencies so that
when a mixed in class is changed, the compatibility is
verified and the receiving class is recompiled as required

ANY class can be mixed in to another as long as they
are compatible for mixing. No tools need be updated.
The class definition source will not change.

There WILL have to be a class method something like

mixInClasses

^
{Class2 . Class3}

Of course some smart person will teach the browsers about
this method but there is no requirement for this.
At first all that is needed is that the
compiler knows to use this method to make sure that
Class1 is compiled as if the mixed in classes were
part of its definition.

There will be NO RENAMING of anything to resolve conflicts.
Conflicts simply cannot exist. All the variable names
(instance, class, class instance, pool) in the definitions
of both classes will remain the same when mixing is done.

instance, class instance, and pool variables with the
same name in both classes can, by nature, never "clash".

Class variables will refer to the same variable in both
classes if both mixed classes inherit the class variable
 from the same superclass, or to a different one in each
class otherwise.

If a method with the same name exists in a class AND its
mixin (as will happen when you mix a class with at least one
method in to another), they must have the same definition.

Programmers defining classes for the purpose of mixing them
in will simply have to take these limitations into account.
This is nothing new or special; with subclass inheritance
there are also things you can and things you cannot do, and
the compiler already takes al the relevant rules into account
and enforces compliance.


HOW TO USE

When you have this mixin scheme in your image, you can start
with an empty Class2 or with Class2 being a copy of the Class1
and mix Class2 into Class1. The effect on Class1 is the same
since conflicts cannot exist.

You can then proceed to remove methods from either class,
add methods (if added to the trait, they will also be added
to the base), remove methods (removing only from the base will
have no effect), change methods (synchronized).

In short, you can gradually and incrementally reorganize
the code in your image, without changing any functionality.
All the existing tools for code management keep on working

Later on people will figure out to improve the browsers,
and to remove duplication in the compiled structures. But
for a start we can remove a whole class of source duplication
and this seems a worthy goal.


HOW MUCH WORK

SimpleTraits should not be more than a few days work for
someone reasonable familiar with the compiler infrastructure.
(Of course I have no idea but I can conjecture). Does
anyone think they would want to use it if it existed?

Who will build this and give a nice Christmas present
to the community? I hereby donate the design inasfar as
it contributes anything original, and provided it is
implemented and integrated in Pharo within 6 months :-).

Cheers, Peter

P.S. Traits/MixIns? For SimpleTraits, I would propose to
keep both names. We say we mix in (the compiler mixes in)
a class using Class1 mixIn: Class2.
The compiler finds the mixInClasses from the methods
with the same name.
When we talk about Class1 and Class2 in relation to each
other we call Class1 the base, and Class2 the trait (of
course both classes can conceivably play the other role
as well, in other mixin relationships, but we need not
concern ourselves with this at first and simply not
implement multi-stage mixin relationships although this
may become desired at some later point in time).

P.P.S. Stéphane, let me know if this SimpleTraits design
addresses what you require from a Traits system. I had dreamed
up this design some time ago but thought Traits were already
"there". Now it seems that Traits have somehow not "made it" into
Pharo and I believe with you that it is a shame not to have it.

P.P.P.S. Inherited elements (vars, methods) of a trait class are
(of course) part of what is synchronized and shared with its
bases so be mindful of what you inherit!

On 29 Nov 2010, at 16:38, Peter van Rooijen wrote:

> Now it seems that Traits have somehow not "made it" into
> Pharo and I believe with you that it is a shame not to have it.

there's no need to despair: traits *are* in Pharo ;-)

:)

On Mon, 29 Nov 2010 17:14:25 +0100, Johan Brichau <[hidden email]>  
wrote:


--
Peter van Rooijen
Nijlring 83
5152 VJ Drunen
m: 06-2854 2048