www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.pattern..mixin temptes..std.concurrency

reply BLS <windevguy hotmail.de> writes:
Hi,
Unfortunately Andrei has canceled his efforts on std.pattern.

Despite that I would like to hear your opinion regarding std.patterns in 
general,  I have a concrete problem in implementing patterns (like GOF 
stuff) with the help of mixin templates..

A concrete example (atm. an evolving idea) is the implementation of a 
mixin template based "observer pattern".      (publisher/subscriber)

I've startet a discussion on d.learn and
it would be very generous if you can have a look at :
news://news.digitalmars.com:119/i1094m$7b8$1 digitalmars.com
and follow the thread.

Further :
What do you think ?
  Would it makes sense to use the std.concurrency message passing system 
for OO patterns that require message passing ?

bjoern
Jul 08 2010
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
BLS Wrote:

   Would it makes sense to use the std.concurrency message passing system 
 for OO patterns that require message passing ?


I think so.  It's certainly safer than the traditional callback method, and
seems best to standardize on one form of notification if at all practical to do
so.
Jul 08 2010
parent BLS <windevguy hotmail.de> writes:
On 08/07/2010 23:37, Sean Kelly wrote:

 BLS Wrote:

    Would it makes sense to use the std.concurrency message passing system
 for OO patterns that require message passing ?


 I think so.  It's certainly safer than the traditional callback method, and
seems best to standardize on one form of notification if at all practical to do
so.


Thank You Sean !! ,
I had so many doubts about the implementation .. Good to have such a 
dedicated feedback. May I ask for a review of my humble efforts to 
implement std.pattern. ***

I would like to start with the observer pattern.. next pattern will be 
the decorator pattern. ( This is 'cause many collections/containers are 
final. )
bjoern
***hopefully with support of D(i)mitry  :)
Jul 08 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/08/2010 10:26 AM, BLS wrote:

 Hi,
 Unfortunately Andrei has canceled his efforts on std.pattern.

 Despite that I would like to hear your opinion regarding std.patterns in
 general, I have a concrete problem in implementing patterns (like GOF
 stuff) with the help of mixin templates..

 A concrete example (atm. an evolving idea) is the implementation of a
 mixin template based "observer pattern". (publisher/subscriber)

 I've startet a discussion on d.learn and
 it would be very generous if you can have a look at :
 news://news.digitalmars.com:119/i1094m$7b8$1 digitalmars.com
 and follow the thread.

 Further :
 What do you think ?
 Would it makes sense to use the std.concurrency message passing system
 for OO patterns that require message passing ?


I think Observer is a very difficult pattern to make generic. There's 
very much variability. Here's an article I wrote about it:

http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-04.pdf

http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-06.pdf


Andrei
Jul 08 2010
next sibling parent reply BLS <windevguy hotmail.de> writes:
On 09/07/2010 01:04, Andrei Alexandrescu wrote:

 I think Observer is a very difficult pattern to make generic. There's
 very much variability. Here's an article I wrote about it:

 http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-04.pdf


 http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-06.pdf



 Andrei


Hi Andrei,
hope you still remember that it was me who brings in the EIFFEL pattern 
library.... erm...

I have to fight here with several problems. (And creating an templated 
Publisher/ Subscriber pattern based on mixin templates is not the 
biggest one :) )

1) std.collections classes , as well as Steven's dcollections are 
final.. This keeps me away from sub classing and mixin a Publisher template.
As already said on D Learn, not everything is lost.. We still have the 
option to implement the decorator pattern on any given collection.

( Funny .. it's a another pattern I would like to implement as META 
pattern )

But Ouch,  implementing this stuff requires more brain food than 
expected, however, once we have a working hard-doable observer in 
std.pattern. (mixin based), a couple of other patterns should be not 
that far away.. visitor.. composite, and so on. However I think not 
every pattern could be "templated".  but the observer stuff seem to be 
doable.. He Andrei we are using D.. and as PhD Guy did it in EIFFEL.

bjoern
Jul 08 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Jul 2010 19:38:59 -0400, BLS <windevguy hotmail.de> wrote:


 1) std.collections classes , as well as Steven's dcollections are  
 final.. This keeps me away from sub classing and mixin a Publisher  
 template.


Have you tried using composition?

The classes in dcollections are final for performance reasons.  Otherwise,  
the functions will not get inlined when the concrete class is used.  I  
wish there was a way to optionally make the class final (i.e. make it a  
parameter).

-Steve
Jul 09 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Steven Schveighoffer <schveiguy yahoo.com> wrote:

 I wish there was a way to optionally make the class final (i.e. make it  
 a parameter).


I first thought this to work:

template bar( bool b ) {
     mixin( b ? "final:" : "" );
     class bar {
     }
}

static assert( msg, __traits( isFinalClass, bar!true ) );
static assert( msg, !__traits( isFinalClass, bar!false ) );

But I guess mixin creates a new scope, rendering it useless.

-- 
Simen
Jul 09 2010
prev sibling parent BLS <windevguy hotmail.de> writes:
On 09/07/2010 14:04, Steven Schveighoffer wrote:

 Have you tried using composition?


Thanks fro feedback Steve.
No, NO Chance.

The composite pattern requires inheritances (and the use of the 
composite pattern does not makes sense in our case)  .... but also my 
idea of using the decorator pattern is not doable 'cause the need of 
inheritance...

So "final" is the end of implementing the publisher/subscriber pattern 
this way.  What remains is code injection.. but this is hackish..
May be we can use opDefault { mixin ...}.
bjoern
Jul 12 2010
prev sibling next sibling parent BLS <windevguy hotmail.de> writes:
On 09/07/2010 01:04, Andrei Alexandrescu wrote:

 I think Observer is a very difficult pattern to make generic. There's
 very much variability. Here's an article I wrote about it:

 http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-04.pdf


 http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-06.pdf



 Andrei


OK, got the message, Still not a Murder-Death-Kill argument.

The biggest problem I (just me) see is, to push or to pull.
I am not kidding. Using std.concurreny for message passing, the thing is 
quit clear.. and anyway pull is sometimes too late, and furthermore hard 
to make thread safe.

In example ..
I am watching a list []  Whenever the list class gets an delete, insert, 
update event it triggers the delegate , no problem so far, even if I 
want to know which data was added, respective deleted.
My  (without std.concurrency message passing)

void delegate(const ref msg) callback;
callback[] CallBack;
is keeping me informed ..

struct Message {T}{
T data;
string msg;
}
BUT  What if I add a list to my list ?

...if we have a look at std.concurrency  receive(), things are more 
shiny.. what do you think Andrei ?
bjoern
Jul 08 2010
prev sibling parent BLS <windevguy hotmail.de> writes:
On 09/07/2010 01:04, Andrei Alexandrescu wrote:

 I think Observer is a very difficult pattern to make generic. There's
 very much variability. Here's an article I wrote about it:

 http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-04.pdf


 http://docs.google.com/viewer?url=http://erdani.com/publications/cuj-2005-06.pdf



 Andrei


Sorry for making so much noise.. Are we talking about :

mixin template Observer(T)
{
}

?

Or do you have a completely other strategy ? Your beginnings in 
std.pattern are somehow lost. :)
Jul 08 2010