[Nepomuk] Re: SimpleResource rcgen redesign draft

[Sebastian Trüg]

On 07/26/2011 08:54 PM, Sebastian Trüg wrote:
> 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) {
> }
> }
> }

damn, sent this one by accident. Please disregard.

>> 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
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk