Re: [squeak-dev] IWST 2010 Call for Papers

One of the reasons I created [hidden email] was exactly not having to do this ;)

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Mariano!

On Tue, Mar 30, 2010 at 10:05 AM, Mariano Martinez Peck
<[hidden email]> wrote:
> One of the reasons I created [hidden email] was exactly
> not having to do this ;)

You are perfectly right - I completely forgot about *this* mailing list. :-D

Maybe because traffic was recently low ...?

Best,

Michael

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Hi,

On Tue, Mar 30, 2010 at 10:16 AM, Mariano Martinez Peck
<[hidden email]> wrote:
> Probably. The traffic is up to us. If we are interested and make sense, it
> will survive and have traffic. Otherwise, it will be forgotten and not used.
> You never know.

maybe the IWST CfP spawns some communication. :-)

Best,

Michael

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

Hi,

let's just keep as a note that I forgot the ST-research list, OK?
Sorry about that. No need to start counting beans. For the sake of
completeness, the CfP is attached to this message. :-)

And YES, PLEASE submit your papers! This is probably THE venue where
no one will bash you for using a dynamically typed language that makes
things easy. ;-)

Best,

Michael


-----


* Apologies for multiple copies. *

Call for Papers

International Workshop on Smalltalk Technologies (IWST) 2010

co-located with European Smalltalk User Group Conference (ESUG)
Barcelona, Spain, September 11-17, 2010


** Description

The goal of the IWST workshop series is to create and foster a forum
around advances or experience in Smalltalk. We welcome contributions
on all aspects, theoretical as well as practical, of Smalltalk-related
topics.

There are two possible kinds of submissions, which must be in ACM SIGPLAN style:

* Research papers (up to 10 pages). Submissions in this category will
be rigorously reviewed, and accepted papers will be published in the
ACM Digital Library (ACM SIGPLAN has approved, the final ACM approval
is pending).

* Demonstration papers (up to 4 pages). Submissions in this category
will not be published in the ACM Digital Library, but will be
available for download from the workshop web page.


** Submission and Reviewing Process

The EasyChair submission web site is at
http://www.easychair.org/conferences/?conf=iwst10.

Authors will be given the opportunity to comment on reviewers' work by
providing feedback on the reviews. For this purpose, a questionnaire
will be sent to authors. Their answers will be evaluated anonymously,
and feedback will be handed on to reviewers.


** Important Dates

Submission: May 14, 2010 (Samoa time)
Feedback: June 28, 2010
ESUG Early Registration Deadline: July 9, 2010
Workshop: September 12, 2010, Barcelona, Spain


** Programme Committee

Co-Chairs:
Michael Haupt, Hasso-Plattner-Institut, University of Potsdam, Germany
Robert Hirschfeld, Hasso-Plattner-Institut, University of Potsdam, Germany

PC Members:
Gabriela Arevalo, Universidad Nacional de La Plata, Argentina
Johannes Brauer, NORDAKADEMIE, Germany
Johan Brichau, Université catholique de Louvain, Belgium
Marcus Denker, INRIA Lille - Nord Europe, France
Theo D'Hondt, Vrije Universiteit Brussel, Belgium
Stéphane Ducasse, INRIA Lille - Nord Europe, France
James Foster, GemStone Systems, Inc., USA
Andy Kellens, Vrije Universiteit Brussel, Belgium
Andreas Raab, Teleplace Inc., USA
Lukas Renggli, Software Composition Group (SCG), University of Bern, Switzerland
Randal L. Schwartz, Stonehenge Consulting Services, Inc.
Dave Ungar, IBM Research

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

On Mar 30, 11:16 am, Mariano Martinez Peck <[hidden email]>
wrote:
> On Tue, Mar 30, 2010 at 6:07 AM, Michael Haupt <[hidden email]> wrote:
> Probably. The traffic is up to us. If we are interested and make sense, it
> will survive and have traffic. Otherwise, it will be forgotten and not used.
> You never know.
Right, should have asked my Traits question here, but I knew that
there where discussions on the pharo list before.

So, well, if anyone knows a simple way to handle state with traits, I
would be happy to read the paper (and include it in PHP...)

Best regards
Stefan

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

On Mar 30, 2010, at 9:43 PM, Stefan Marr wrote:

I'm thinking about it and would like a really simple solution.
Now that in Pharo we do not share methods between traits and their users it is like a copydown
so having a simple disambigation mechanism + merging of state at the composite level (no merging)
+ only use of accessors to perform merging if needed could work and still be simple.

Stef

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

On Mar 30, 10:42 pm, stephane ducasse <[hidden email]>
wrote:
> On Mar 30, 2010, at 9:43 PM, Stefan Marr wrote:
>
> I'm thinking about it and would like a really simple solution.
> Now that in Pharo we do not share methods between traits and their users it is like a copydown
> so having a simple disambigation mechanism + merging of state at the composite level (no merging)
> + only use of accessors to perform merging if needed could work and still be simple.
Hm, think in PHP there is a lot less compilation magic going on.

PHPs objects are very similar to Python objects, they are basically
just hashmaps, even so, in PHP you have two hashmaps, one for the
properties, and one for the methods, and the problem is, you can just
use them as hashmaps.

The feature which basically forbids all kind of compile-time magic is
that you can use a string variable to access a property: $obj->
$propertyName = 'myNewValue';
Any strategies like name-mangling on flattening to introduce state
which is only visible to the trait method becomes hard this way.

So, assume a 'trait-local is default' strategy: every property access
from a method, which originates from a trait would have to be handled
differently. I could introduce a property hashmap per trait, but then
the question arises, how do you define the semantics of accesses to
properties which have not be specified in the class (which is allowed
and common in a lot of code).
And how do you combine that with accessing state from the object, or
an other trait. I think your answer would be: use accessors. With
regard to that, unspecified properties should also be trait-local by
default.

And well, I think, then we are really fast a point were we are not
talking about traits anymore. At least my conclusion was it is
different. It is more like an elaborated delegation mechanism, like
grafting an object on another one:
http://wiki.php.net/rfc/horizontalreuse#grafts_-_class_composition

Best regards
Stefan

To unsubscribe from this group, send email to smalltalk-research+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

ok I see.

you lost me.