[Clam-devel] TYPEDCONTROLS REFACTORING: Opinions about actual controls compatibility

[Pau Arumí]

Of course, here we have the core of the typedcontrols problem: we want
homogeneous interface (which is nice for connection). 
But at the same time we want services that doesn't make sense for all
typedcontrols, such as bounds. And that require coupling with the Type
of the control (such as GetDefault() or GetBounds() )

Francisco says that maybe we could rethink how the framework handles
bounds. If we want to to maintain the feature (I think we do) I see no
simple solution. 
We could either 
1. taint the BaseTyped*Control interface with float-specific services
(such as float GetDefautl(); or float GetInferiorBound() ) or
2. use downcast.

If we do 2, it is not absolutely necessary to have a Float*Control
subclass. We could implement the GetDefault(), GetBounds() etc methods
in the Typed*Control<Type> template class by method specialization.
 
I'm more for 1 because it is much simpler for control clients and I
don't foresee the float-specific interface grow a lot.
But I'd like to hear more discussion...

P


On dl, 2008-08-04 at 19:57 -0300, Francisco Tufró wrote:
> I have it, but, no real changes were made to network editor to accept
> typed controls, and i think this is the moment to talk a bit about
> this, maybe some effort on removing these functions can bring much
> help on migrating everything in a small step. In the patch you are
> talking about InControl was kept intact, only inheriting
> TypedInControl<int> was modified (and connection stuff also).
> 
> On Mon, Aug 4, 2008 at 7:47 PM, Hernán Ordiales <h at ordia.com.ar>
> wrote:
>         
>         On Mon, Aug 4, 2008 at 7:38 PM, Francisco Tufró
>         <nictuku at gmail.com> wrote:
>         > Hi, one of the topics that we didn't defined about the typed
>         control
>         > migration is what to do with the actual controls.
>         > The first idea (and the one i like most) was to do a simple
>         typedef
>         > Typed[In|Out]Control [In|Out]Control.
>         > The problem with this solution is that there are functions
>         implemented in
>         > InControl that have no sense in TypedInControl, specially
>         those for bounds
>         > and GetLastValueAs[Int|Bool].
>         > My question is if it possible to structure the framework
>         code so these
>         > functions can be removed. For example, NetworkEditor uses
>         this bounding
>         > stuff, should we rethink the way it works with controls to
>         simplify the
>         > migration.
>         > The other solution was to do InControl inherit
>         TypedInControl and add the
>         > missing functionality, but i think this solution is going to
>         bring problems
>         > when we migrate everything, and introduces some complexity
>         to the framework
>         > that i don't know if it is correct, and that's why i'm
>         asking for opinions.
>         > That's all by now!
>         
>         
>         You have a previous patch (AFAIK full working at least with
>         clam lib)
>         with this last approach, don't? why not attach it to this
>         thread?
>         
>         cheers
>         --
>         Hernán
>         http://h.ordia.com.ar
>         GnuPG: 0xEE8A3FE9
>         
>         _______________________________________________
>         Clam-devel mailing list
>         Clam-devel at llistes.projectes.lafarga.org
>         https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
> 
> 
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel