[Nepomuk] Re: SimpleResource rcgen redesign draft

[Christian Mollekopf]

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.

Thats the same as with pointers, and it's c++ after all, developers have  
to think a bit.
I just think that forgetting r = pc.resource() is more likely than  
returning a generated class
containing a local reference, because that is a problem you should be used  
to as c++ developer
(although a bit nasty I admit) and

SimpleResource r;
NCO::PersonContact pc(r);
pc.setFullname("foobar");

doesn't really look "wrong" at all (unless you have a close look at the  
header).

Anyways, no strong preference from my side.

Cheers

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


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/