Results 1 to 4 of 4

Thread: an idea of callbacks mudule

  1. #1
    Peasant
    Join Date
    Jul 2009
    Location
    China Xi'An
    Posts
    8

    Default an idea of callbacks mudule

    I have an idea of signals and callbacks mudule.

    Simple put, we can use Callbacks to implement Signals. Since some code of these two parts are quite similar. I think we can remove some classes of Signals, and use #include "callback_x.h" instead.

    For example:
    Code:
    class CL_Callback 
    {
    public:
    	CL_SlotCallback() : valid(true), enabled(true) { return; }
    	virtual ~CL_SlotCallback() { return; }
    	bool valid;
    	bool enabled;
    };
    
    
    template <class RetVal, class P1>
    class CL_Callback_1 : public CL_Callback
    {
    	...
    
    	void set(RetVal (*function)(P1))
    	{
    		impl = CL_SharedPtr< CL_Callback_Impl_1<RetVal, P1> >(new CL_Callback_Impl_1_static<RetVal, P1>(function));
    	}
    	void invoke(P1 p1)
    	{
    		return impl->invoke(p1);
    	}
    
    	...
    	
    }
    In signal_v1.h
    Code:
    #include "callback_1.h"
    ...
    
    template <class Param1>
    class CL_Signal_v1
    {
    	...
    
    	CL_Slot connect(void (*function)(Param1))
    	{
    		CL_Callback_1<void, Param1>* callback_1 = 
    			new CL_Callback_1<void, Param1>();
    		callback_1->set(function);
    		CL_SharePtr<CL_Callback> callback(callback_1);
    		impl->connected_slots.push_back(callback);
    		return CL_Slot(callback);
    	}
    		
    	...
    }
    Maybe some code should be modified as well.

    -Jiao

  2. #2
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    There are no known bugs in the current signal classes in 2.0, so why take a chance changing them?

    Every code change involves a risk of introducing a bug, so there has to be some immediate advantage that justifies this risk. In this situation I do not really see any obvious advantage in letting CL_Signal use CL_Callback as its implementation.

    If the current CL_Signal implementation was broken and not working, it would be a different discussion, but as nobody has complained about anything regarding CL_Signal for years, I consider the signal code pretty solid.

  3. #3
    Peasant
    Join Date
    Jul 2009
    Location
    China Xi'An
    Posts
    8

    Default

    OK, just suggestion.

  4. #4
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    Maybe I ended up sounding a bit too grumpy in that reply.

    Your idea isn't bad as such, since a signal is basically just a vector of callbacks. It could possibly even been a more clean implementation since it might make the code easier to read.

    But if something ain't broken, don't fix it.

Similar Threads

  1. Idea's for a Graveyard Mod
    By in forum Funeral Quest
    Replies: 1
    Last Post: 06-03-2005, 10:04 PM
  2. Another new Idea
    By in forum Funeral Quest
    Replies: 4
    Last Post: 02-13-2003, 12:54 AM
  3. New idea...
    By GrimMasterDeath in forum Funeral Quest
    Replies: 3
    Last Post: 12-24-2002, 02:41 AM
  4. Weird Idea
    By redink1 in forum Funeral Quest
    Replies: 1
    Last Post: 12-07-2002, 11:32 PM
  5. FQ ranking idea's
    By in forum Funeral Quest
    Replies: 1
    Last Post: 09-26-2002, 01:29 PM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •