A bit more discussion about libsigc++. Don't worry I'll stop forwarding
these soon.
Allan. (ARRae)
---------- Forwarded message ----------
Date: Thu, 04 Mar 1999 22:07:49 -0800
From: Karl Nelson <[EMAIL PROTECTED]>
To: Allan Rae <[EMAIL PROTECTED]>
Subject: Re: [gtkmm] Libsigc++
In message <[EMAIL PROTECTED]>Allan Ra
e writes
>On Thu, 4 Mar 1999, Karl Nelson wrote:
>
>This is also the convention we use up to a point. Functions are
>slightly different.
>[...]
>>
>> Now, what should these factories be named...
>>
>> slot(), Slot(), new_slot() ...
>> data(), Data(), slot_data() ...
>
>My first thoughts were to use Slot and Data because it implies the
>class that is being constructed by the factory but this convention may
>lead to extra confusion with the other factories. For example,
>slot_convert would perhaps have to be named SlotConvert to match -- this
>is silly because, of course, this factory is a customising shop not a OEM
>(to continue the analogy).
>
>So, that leads me back to all lowercase. It is still accurate to
>consider it a function call. If you really wanted to distinguish
>factories from class constructors and function calls you could use
>slot, slotConvert, slotRetype (thereby using a different labelling
>convention of their own -- maybe slotNew instead of slot).
Yeah, I am of similar mind.
How about using the mixed convention for all but the primary factory.
slot(), slotData(), slotRetype(), slotConvert()
(Really this needs to be in a namespace of some sort like Slot, but
one of our main compilers (egcs 1.0) lacks support for this, so
it would be an awkward transition.)
>
>> Other factories will likely be things like
>> slot_retype<return_type>(S s) - recast the return type
>> slot_rearg<R,P1,P2,P3..>(S s) - change the types of arguments & rettype
>> (through sandard means)
>>
>> slot_convert(S s,R (*f)(P1,P2,P3..,S)
>> slot_convert(S s,M& m,R (M::*f)(P1,P2,P3..,S)) - convert the slot type
>> from one type to another with static function or method function
>>
>> These will provide the means for doing such wild things as
>> completely retyping and manipulating slots. Thus if a
>> slot is type int f(float,double) and you have a void f(double,double,int,int
>)
>> signal there is a defined way to make such a connection if it is
>> necessary. Hopefully, this will be a powerful feature and not
>> an flop.
>
>Hmmm, okay I can see how they'd work but I'm inclined to think that
>someone who needed to do this would probably be better off fixing their
>design so they don't have to do such things. Then again maybe my
>imagination is letting me down. I'll have to think about these a bit
>more.
Well, this is part of the problem of library design as opposed to
application design. It is easy enough to say in the application level
that we should just change the type of the function to fit the use.
It is another to go and alter some library to fit your application.
I think your project has discovered this already with the XForms
library. The interface for the library is set and unchangable. It
therefore falls to the application programmer who is viewing the
problem from the use to decide how to make use of the library.
So the question that this raises it to whom this part of the signal
system is targeting? In this case, I am trying to target the
application writter by providing a wide range of tools to alter an
existing library. Without such tools the application writter has
to use kludges or extra unnecessary data to get the interface to
do something it was not intending to do.
Only one of these tools is targeted at the library writter. That
is the convert function. The convert function will allow the library
For example assume the library writter intends to provide an interface
that can accept either strings or char* transparently. This is how
it might be achieved....
class A
{
public:
class MySig: public Basic_Signal1<int,string&>
{public:
Connection connect(Slot1<int,char*> *s)
{return connect(slotConvert(s,_Char2String));}
} mysig;
}
The convert allows a heterogeneous list to be made by converting all
the slots to a single type.
connect to string& comes from the basic signal, the other is then
added to make for more flexiblity.
>(...potentially a heterogeneous list of slots activated by a signal...)
>
>Will you be allowing slot conversion down as well as up?
> (you example above expands the parameter list ie. up)
>and if so how would you allow the programmer to specify the default
>parameters?
data reduces the number of arguments (slot3 => slot2)
ignore would likely be the opposite (slot2 => slot3) by adding ignored
arguments.
--Karl
