[OpenWalnut-Dev] WItemSelection & friends improvement

Tue May 15 16:29:49 CEST 2012

;) There would be a way (if I don't forget sth.) if you could define a 
base class of the class template type T, like in generics of Java:
public class WAbstractItem* <T extends WAbstractItem*> ...
In this case you could write a new templatized base class of WItem* 
(WAbstractItem*) with the templatized code of the current WItem* and the 
current WItem* would be an implementation with a fixed type (WItem* 
<WItem*>) or just a typedef. So we do not have to write code twice, but 
could implement new WItem* without breaking old modules.
Anyway, with this limitation we can not change this with less effort.

see ya!

Am 15.05.2012 16:09, schrieb Sebastian Eichelbaum:
> Btw. backward compatibility is not the reason. Its a technical issue which arises from the fact that every instantiated template is its own type without any polymorphic relations. You always need a base class for classes which share some basic functionality as the WItem classes do. The current WItem* classes are these base classes. Replacing them with templatized classes will not resolve the issue.
>
> Bye
> Sebastian
>
> On Tue, 15 May 2012, Christof Pieloth wrote:
>
>> Hello,
>>
>> I have created a ticket with the *.diff:
>> http://www.openwalnut.org/issues/174
>> I decided to extend WItemSelectionItem as a container. This solution
>> allows us to use any types even those without a default constructor.
>> Sadly we now have a dynamic cast, but due to "downward
>> compatibility" we have to take this.
>>
>> Bye
>> Christof
>>
>>
>> Am 14.05.2012 18:28, schrieb Christof Pieloth:
>>> Tomorrow I will have a try and can hopefully send you a patch in a
>>> few days.
>>>
>>> Am 14.05.2012 15:56, schrieb Sebastian Eichelbaum:
>>>> Hi
>>>>
>>>> This is a nice idea. But technically, there are several things
>>>> to do to achieve this:
>>>>
>>>> You will need to derive a new templatized class from
>>>> WItemSelectionItem AND simultanously derive from the template
>>>> type T. With this, you can use a queried WItemSelectorItem as
>>>> your own type directly:
>>>>
>>>> template<   typename T>
>>>> class WIteSelectionItemTyped: public WItemSelectionItem,
>>>>                                public T
>>>>
>>>> Luckily, these items are handled using pointers. If they would
>>>> be handles as copies throughout the WItemSelection, your
>>>> explicitly derived typing would be lost. Now, you can provide a
>>>> method to WItemSelectionItem:
>>>>
>>>> const T&   getValue() const;
>>>> and
>>>> T&   getValue()
>>>> {
>>>>    return *dynamic_cast<   T*>( this );
>>>> }
>>>>
>>>> .. Then you would be able to use the item you query with
>>>> WItemSelector::at
>>>>
>>>> mySelector->at( someIndex )->getValue<   MyType>().MyFunction();
>>>>
>>>> Even nicer would be to also provide WItemSelector::at and atAll
>>>> with some template type to directly return a pointer to the
>>>> WItemSelectionItemTyped instance ... awesome :-)
>>>>
>>>> If you implement something like this, we would be very happy to
>>>> get a patch from you. You can create such a patch via hg export:
>>>>
>>>> $ hg pull -u
>>>> $ edit files
>>>> $ hg commit -m "[ADD] our nice feature"
>>>> $ hg export
>>>>
>>>>
>>>> The exported patch can be added by us to the upstream code and
>>>> next time you do a hg pull, you can merge the stuff in.
>>>>
>>>> Thank you for your idea!
>>>> If you have any problems when doing this, just drop a mail to the list!
>>>> Sebastian
>>>>
>>>>
>>>> On Mon, 14 May 2012, Christof Pieloth wrote:
>>>>
>>>>> Hello everybody,
>>>>>
>>>>> we are using a "WItemSelection"&   friends very often in our project
>>>>> and missing a feature.
>>>>> In most of our cases we fill a "WItemSelection" with an enum and
>>>>> have to code our own mapper to get the corresponding enum value for
>>>>> the selected "WItemSelectionItem", which we get from
>>>>> "WItemSelector.at()". We may can extend "WItemSelectionItem" to a
>>>>> template to hold a value of a generic type and a method like "T
>>>>> WItemSelectionItem.getValue()". So you can use a switch-case
>>>>> straight away.
>>>>> What are you thinking of this idea?
>>>>>
>>>>> Best regards
>>>>> Christof
>>>>>
>>>>> -- 
>>>>> HTWK Leipzig, University of Applied Sciences
>>>>> Faculty of Electrical Engineering and Information Technology
>>>>> Laboratory for Biosignal Processing (LaBP)
>>>>>
>>>>> fon:  +49 (0) 341 3076 3133
>>>>> fax:  +49 (0) 341 3076 853133
>>>>> mail: pieloth 'at' labp.htwk-leipzig.de
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenWalnut-Dev mailing list
>>>>> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
>>>>> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
>>>>>
>>>>> Archive:
>>>>> http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
>>>>>
>> -- 
>> HTWK Leipzig, University of Applied Sciences
>> Faculty of Electrical Engineering and Information Technology
>> Laboratory for Biosignal Processing (LaBP)
>>
>> fon:  +49 (0) 341 3076 3133
>> fax:  +49 (0) 341 3076 853133
>> mail: pieloth 'at' labp.htwk-leipzig.de
>>
>>
>> _______________________________________________
>> OpenWalnut-Dev mailing list
>> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
>> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
>>
>> Archive: http://lists.informatik.uni-leipzig.de/pipermail/openwalnut-dev/
>>

-- 
HTWK Leipzig, University of Applied Sciences
Faculty of Electrical Engineering and Information Technology
Laboratory for Biosignal Processing (LaBP)

fon:  +49 (0) 341 3076 3133
fax:  +49 (0) 341 3076 853133
mail: pieloth 'at' labp.htwk-leipzig.de