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

Fri Aug 8 15:53:31 PDT 2008

On Thu, Aug 7, 2008 at 1:35 PM, Francisco Tufró <nictuku at gmail.com> wrote:
> 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);

I think you should point the problems you found with more context (and
as i told you before, make a detailed list of them), I think many
cases could be still valid using a BaseControl instead of InControl
since the required interface is enough. In the file you pointed,
NetworkCanvas.hxx, i found that uses are related with bounds, so if we
implement the float-specific services that pau mentioned maybe could
solve those situations easily, but i think to make good decisions we
need an overall view of all the problems you faced with the migration
first (that's why the list). In other words, if those are the only
problems (bound related), maybe "1." has still more sense.

> 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
>
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>
>

-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9