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 BLS <windevguy hotmail.de> writes:
On 09/07/2010 14:04, Steven Schveighoffer wrote:
 Have you tried using composition?

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 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

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
prev sibling next sibling parent "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
prev 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