[Nepomuk] Re: SimpleResource rcgen redesign draft

[Sebastian Trüg]

On 07/26/2011 04:46 PM, Christian Mollekopf wrote:
> On Tue, 26 Jul 2011 13:37:12 +0200, Sebastian Trüg <trueg at kde.org> wrote:
> 
>> On 07/26/2011 10:06 AM, Christian Mollekopf wrote:
>>> On Tue, 26 Jul 2011 09:52:20 +0200, Sebastian Trüg <trueg at kde.org>  
>>> wrote:
>>>
>>>> On 07/25/2011 11:17 PM, Christian Mollekopf wrote:
>>>>> On Mon, 25 Jul 2011 23:09:26 +0200, Christian Mollekopf
>>>>> <chrigi_1 at fastmail.fm> wrote:
>>>>>
>>>>>> Another thing I just noticed:
>>>>>> The constructor should already set the type,
>>>>>> in case no properties are set.
>>>>>
>>>>> Hmm... I guess it was done this way to avoid setting the myriad of  
>>>>> types
>>>>> in the hierarchy.
>>>>
>>>> exactly.
>>>>
>>>>> Maybe add an explicit setType function instead, or add it to the
>>>>> resource() function,
>>>>> if you go for the copy version.
>>>>
>>>> Hm, is it really necessary to have a type if nothing else is set? Why
>>>> does one need the resource then anyway?
>>>>
>>>
>>> Because i.e. in the feeder I add only properties which don't actually
>>> belong to the most specific type.
>>> (Things like the label, NCAL:location for incidences, etc)
>>>
>>> Still all created items must have the right type, i.e. for queries with
>>> fulltext search.
>>> And btw. think of the AkonadiDataObject type, where we don't even have a
>>> property to add for collections.
>>
>> I suppose I could add a protected constructor to all classes which would
>> be used by child classes. This constructor would take a type URI as
>> input. That way only the top-level type would be set.
> 
> Yep, that sound like a good idea.

Ok, then, for documentation purposes and so I won't forget let me draft
one generated class:

namespace Nepomuk {
namespace NCO {
class PersonContact : public Contact
public:
PersonContact()
 : Contact(TYPE) {
}
PersonContact(const SimpleResource& r)
 : Contact(r, TYPE) {
}

protected:
PersonContact(const QUrl& type)
 : Contact(type) {
}
}
}

> Cheers
>>
>> Cheers,
>> Sebastian
>>
>>> Cheers
>>>
>>>>>>
>>>>>> On Mon, 25 Jul 2011 21:20:45 +0200, Sebastian Trüg <trueg at kde.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On 07/25/2011 07:52 PM, Christian Mollekopf wrote:
>>>>>>>> On Mon, 25 Jul 2011 18:30:05 +0200, Sebastian Trüg <trueg at kde.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Now that the SimpleResource rcgen is in git master[1] some people
>>>>>>>>> used
>>>>>>>>> it (mostly for Akonadi feeders and the web extractor framework)  
>>>>>>>>> and
>>>>>>>>> found it to be a bit strange.
>>>>>>>>>
>>>>>>>>> This is true. Current usage is as follows:
>>>>>>>>>
>>>>>>>>> SimpleResource r;
>>>>>>>>> NCO::PersonContact(&r).setFullname("foobar");
>>>>>>>>>
>>>>>>>>> The reason for this is simple: due to multi-inheritance problems I
>>>>>>>>> cannot derive the generated classes from SimpleResource. Thus, we
>>>>>>>>> need
>>>>>>>>> wrappers.
>>>>>>>>>
>>>>>>>>> Now some ideas were floating around and I would like to settle on
>>>>>>>>> one
>>>>>>>>> better solution.
>>>>>>>>>
>>>>>>>>> One idea would be to have a hybrid thing where you could do this:
>>>>>>>>>
>>>>>>>>>   NCO::PersonContact pc;
>>>>>>>>>   pc.setFullname("foobar");
>>>>>>>>>   SimpleResource r = rc.resource();
>>>>>>>>>
>>>>>>>>> and this:
>>>>>>>>>
>>>>>>>>>   SimpleResource r;
>>>>>>>>>   NCO::PersonContact pc(r);
>>>>>>>>>   pc.setFullname("foobar");
>>>>>>>>>   r = pc.resource();
>>>>>>>>>
>>>>>>>>> (The last line would be required since all SimpleResources would  
>>>>>>>>> be
>>>>>>>>> copies.)
>>>>>>>>
>>>>>>>> Why can't you just take the reference to r, and the last copy
>>>>>>>> wouldn't
>>>>>>>> be
>>>>>>>> needed?
>>>>>>>> Of course the accessor is still needed for the NCO::PersonContact  
>>>>>>>> pc;
>>>>>>>> usecase.
>>>>>>>
>>>>>>> I cannot use refs for security reasons. Imagine someone returns a
>>>>>>> generated class from a method after putting in a ref to a local
>>>>>>> SimpleRes. Anyway, SimpleRes is implicitly shared.
>>>>>>>
>>>>>>>>>
>>>>>>>>> We could go on like so:
>>>>>>>>>
>>>>>>>>>   r.addProperty(...);
>>>>>>>>>   pc = r;
>>>>>>>>>   pc.setResource(r);
>>>>>>>>>
>>>>>>>>> The only disadvantage I see here might be a slight performance
>>>>>>>>> overhead
>>>>>>>>> due to the copying of the resources.
>>>>>>>>>
>>>>>>>>> Opinions?
>>>>>>>>
>>>>>>>> Additionally it might be nice to have an accessor to the uri of the
>>>>>>>> SimpleResource directly in the wrapper,
>>>>>>>> and the << operator for the graph.
>>>>>>>>
>>>>>>>> So we would go from this:
>>>>>>>>
>>>>>>>>    Nepomuk::SimpleResource iconRes;
>>>>>>>>    Nepomuk::NAO::FreeDesktopIcon icon(&iconRes);
>>>>>>>>    icon.setIconNames( QStringList() << iconName );
>>>>>>>>    graph << iconRes;
>>>>>>>>    res.setProperty( Soprano::Vocabulary::NAO::prefSymbol(),
>>>>>>>> iconRes.uri() );
>>>>>>>>
>>>>>>>> to this:
>>>>>>>>
>>>>>>>>    Nepomuk::NAO::FreeDesktopIcon icon;
>>>>>>>>    icon.setIconNames( QStringList() << iconName );
>>>>>>>>    graph << icon;
>>>>>>>>    res.setProperty( Soprano::Vocabulary::NAO::prefSymbol(),
>>>>>>>> icon.uri()
>>>>>>>> );
>>>>>>>
>>>>>>> nice.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Sebastian
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> http://quickgit.kde.org/?p=kde-runtime.git&a=blob&h=304db56a9aff5523a5672415550c49d4b7269c3c&hb=344806a2e378f3421399cad39a63f14a4428308b&f=nepomuk/services/storage/lib/nepomuk-simpleresource-rcgen.py
>>>>>>>>> _____________________________________________
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk