«

Vladimir Jovic <>, on 29/07/2010 15:53:00, wrote:

> Öö Tiib wrote:
>> On 24 juuli, 18:10, "Francesco S. Carta" <entul...@gmail.com> wrote:
>>> I'd like to ask you if you can come up with some real life examples
>>> where you have taken advantage of pointers to member functions -
>>> unfortunately, being an hobbyist, my best example comes straight from
>>> the top of my head
>>
>> For loosely coupling something.
>>
>> For example typical silly observer pattern implementation expects my
>> observer to have virtual handleEvent(Observed& ref) method. Virtual
>> from IObserver base interface. Why? Looks like direct translation from
>> java with no brain applied. I can just boost:bind any member function
>> as an observer functor. Only limit is that it has to have unique
>> member function name in class (may not have overloads).
>>
>> That way i need no useless interface base classes and virtuals and lot
>> of other bloat and nuisance usually connected to loose coupling
>> patterns. Patterns look like too tightly coupled after such thing
>> applied for my taste. The calling and binding of member function
>> pointers should be templatized to not confuse novices. Also i usually
>> suggest to consider boost::signals2 first when someone needs
>> multithreaded version of such.
>
> observer only = great pattern to greatly simplify the architecture and
> design (therefore the code as well)
>
> observer + MVP = killer combo for GUIs

uh... MVP stands for what? And with "killer" I suppose you mean that
that combo would be bad for GUIs, have I got it right?

I'd like to know the reason - not that it would mean much, before
knowing what MVP stands for, but you'll surely throw light on both.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com

Francesco S. Carta wrote:
> Vladimir Jovic <>, on 29/07/2010 15:53:00, wrote:
>
>> Öö Tiib wrote:
>>> On 24 juuli, 18:10, "Francesco S. Carta" <entul...@gmail.com> wrote:
>>>> I'd like to ask you if you can come up with some real life examples
>>>> where you have taken advantage of pointers to member functions -
>>>> unfortunately, being an hobbyist, my best example comes straight from
>>>> the top of my head
>>>
>>> For loosely coupling something.
>>>
>>> For example typical silly observer pattern implementation expects my
>>> observer to have virtual handleEvent(Observed& ref) method. Virtual
>>> from IObserver base interface. Why? Looks like direct translation from
>>> java with no brain applied. I can just boost:bind any member function
>>> as an observer functor. Only limit is that it has to have unique
>>> member function name in class (may not have overloads).
>>>
>>> That way i need no useless interface base classes and virtuals and lot
>>> of other bloat and nuisance usually connected to loose coupling
>>> patterns. Patterns look like too tightly coupled after such thing
>>> applied for my taste. The calling and binding of member function
>>> pointers should be templatized to not confuse novices. Also i usually
>>> suggest to consider boost::signals2 first when someone needs
>>> multithreaded version of such.
>>
>> observer only = great pattern to greatly simplify the architecture and
>> design (therefore the code as well)
>>
>> observer + MVP = killer combo for GUIs
>
> uh... MVP stands for what? And with "killer" I suppose you mean that
> that combo would be bad for GUIs, have I got it right?
>

Sorry for not being clearer

That combination is superb for GUIs. All alternatives are weaker.

Next link might give you idea what the MVP is, but I do not really
recommend it.
http://en.wikipedia.org/wiki/Model-view-presenter
Little googling should give you better presentations, something like this :
http://en.wikipedia.org/wiki/Presenter_First

> I'd like to know the reason - not that it would mean much, before
> knowing what MVP stands for, but you'll surely throw light on both.
>

Google for the "observer pattern", and play a bit with boost::signals
(what oo tib recommended).

Vladimir Jovic <>, on 29/07/2010 16:14:53, wrote:

> Francesco S. Carta wrote:
>> Vladimir Jovic <>, on 29/07/2010 15:53:00, wrote:
>>
>>> Öö Tiib wrote:
>>>> On 24 juuli, 18:10, "Francesco S. Carta" <entul...@gmail.com> wrote:
>>>>> I'd like to ask you if you can come up with some real life examples
>>>>> where you have taken advantage of pointers to member functions -
>>>>> unfortunately, being an hobbyist, my best example comes straight from
>>>>> the top of my head
>>>>
>>>> For loosely coupling something.
>>>>
>>>> For example typical silly observer pattern implementation expects my
>>>> observer to have virtual handleEvent(Observed& ref) method. Virtual
>>>> from IObserver base interface. Why? Looks like direct translation from
>>>> java with no brain applied. I can just boost:bind any member function
>>>> as an observer functor. Only limit is that it has to have unique
>>>> member function name in class (may not have overloads).
>>>>
>>>> That way i need no useless interface base classes and virtuals and lot
>>>> of other bloat and nuisance usually connected to loose coupling
>>>> patterns. Patterns look like too tightly coupled after such thing
>>>> applied for my taste. The calling and binding of member function
>>>> pointers should be templatized to not confuse novices. Also i usually
>>>> suggest to consider boost::signals2 first when someone needs
>>>> multithreaded version of such.
>>>
>>> observer only = great pattern to greatly simplify the architecture and
>>> design (therefore the code as well)
>>>
>>> observer + MVP = killer combo for GUIs
>>
>> uh... MVP stands for what? And with "killer" I suppose you mean that
>> that combo would be bad for GUIs, have I got it right?
>>
>
> Sorry for not being clearer
>
> That combination is superb for GUIs. All alternatives are weaker.

Ehehehe, "killer" is a double-edged (s)word

> Next link might give you idea what the MVP is, but I do not really
> recommend it.
> http://en.wikipedia.org/wiki/Model-view-presenter

Heck, I tried "define:mvp" on google and got completely unrelated
results - I wondered if that meant "multi-visitor pattern" but of course
that was weird as an addition to "observer"... I didn't think about
looking up the acronym on wikipedia, I would have gotten there, somehow.

> Little googling should give you better presentations, something like this :
> http://en.wikipedia.org/wiki/Presenter_First
>
>> I'd like to know the reason - not that it would mean much, before
>> knowing what MVP stands for, but you'll surely throw light on both.
>>
>
> Google for the "observer pattern", and play a bit with boost::signals
> (what oo tib recommended).

Thanks for the clarification and for the links, I'll have a look.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com