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

[Francisco Tufró]

I think the first may be a good solution.

Another problem that i see in code is that Get*Control(s) is used in this
way:

InControl& control = proc.GetInControl("Some Control 1")

We'll have to rewrite all these case by case, watching carefully why this is
done and what to do with each case.
Simply run grep -R * -e "GetInControl" | grep -v svn | grep -v "Binary"  to
see this, in the network editor source tree
For example:
NetworkCanvas.hxx:        CLAM::InControl& inControl =
processing->GetInControls().GetByNumber(index);


On Tue, Aug 5, 2008 at 4:50 AM, Pau Arumí <parumi at iua.upf.edu> wrote:

> 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
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080807/b02d7253/attachment-0004.htm>