IProjectController

Hi,

we have:

    virtual IProject* projectAt( int ) const = 0;
    virtual int projectCount() const = 0;
    virtual QList<IProject*> projects() const = 0;


Do we really need all of them? I think it should be OK to
drop projectAt() and 
projectCount() .

Jens

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 01.07.07 16:21:14, Jens Herden wrote:
> we have:
> 
>     virtual IProject* projectAt( int ) const = 0;
>     virtual int projectCount() const = 0;
>     virtual QList<IProject*> projects() const =
0;
> 
> 
> Do we really need all of them? I think it should be OK
to drop projectAt() and 
> projectCount() .

Well, according to our wiki we should drop
QList<IProject*> projects()
const;
http://www.kdevelop.org/mediawiki/index.php/Platfor
m_API_TODO

I added the two count/at methods specifically because of
this note.

Andreas

-- 
You will inherit some money or a small piece of land.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Jul 1, 2007, at 11:10 AM, Andreas Pakulat wrote:

> On 01.07.07 16:21:14, Jens Herden wrote:
>> we have:
>>
>>     virtual IProject* projectAt( int ) const = 0;
>>     virtual int projectCount() const = 0;
>>     virtual QList<IProject*> projects() const
= 0;
>>
>>
>> Do we really need all of them? I think it should be
OK to drop  
>> projectAt() and
>> projectCount() .
>
> Well, according to our wiki we should drop
QList<IProject*> projects()
> const;
> http://www.kdevelop.org/mediawiki/index.php/Platfor
m_API_TODO
>
> I added the two count/at methods specifically because
of this note.
>
> Andreas
>

We need to keep all three of them. The first two that don't
return a  
list are for scripting purposes (think usage from dbus
commandline)  
and the one that returns the list is for C++ usage. IMHO,
requiring  
index iteration from C++ is just plain stupid when we can
use iterators.
--
Matt



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 01.07.07 15:45:28, Matt Rogers wrote:
> 
> On Jul 1, 2007, at 11:10 AM, Andreas Pakulat wrote:
> 
> > On 01.07.07 16:21:14, Jens Herden wrote:
> >> we have:
> >>
> >>     virtual IProject* projectAt( int ) const =
0;
> >>     virtual int projectCount() const = 0;
> >>     virtual QList<IProject*> projects()
const = 0;
> >>
> >>
> >> Do we really need all of them? I think it
should be OK to drop  
> >> projectAt() and
> >> projectCount() .
> >
> > Well, according to our wiki we should drop
QList<IProject*> projects()
> > const;
> > http://www.kdevelop.org/mediawiki/index.php/Platfor
m_API_TODO
> >
> > I added the two count/at methods specifically
because of this note.
> >
> 
> We need to keep all three of them. The first two that
don't return a  
> list are for scripting purposes (think usage from dbus
commandline)  

Aaah, that makes more sense, then just "Its hard to
wrap such types
using QVariante/QMetatype" as in the wiki.

> and the one that returns the list is for C++ usage.
IMHO, requiring  
> index iteration from C++ is just plain stupid when we
can use iterators.

Ok, this information needs to go into a prominent place.
I'll see how I
can integrate that into our doxygen files tomorrow. Else
this won't be
the last question of this type.

Andreas

-- 
Good news from afar can bring you a welcome visitor.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 01 July 2007, Matt Rogers wrote:
> On Jul 1, 2007, at 11:10 AM, Andreas Pakulat wrote:
> > On 01.07.07 16:21:14, Jens Herden wrote:
> >> we have:
> >>
> >>     virtual IProject* projectAt( int ) const =
0;
> >>     virtual int projectCount() const = 0;
> >>     virtual QList<IProject*> projects()
const = 0;
> >>
> >>
> >> Do we really need all of them? I think it
should be OK to drop
> >> projectAt() and
> >> projectCount() .
> >
> > Well, according to our wiki we should drop
QList<IProject*> projects()
> > const;
> > http://www.kdevelop.org/mediawiki/index.php/Platfor
m_API_TODO
> >
> > I added the two count/at methods specifically
because of this note.
> >
> > Andreas
>
> We need to keep all three of them. The first two that
don't return a
> list are for scripting purposes (think usage from dbus
commandline)
> and the one that returns the list is for C++ usage.
IMHO, requiring
> index iteration from C++ is just plain stupid when we
can use iterators.

I understand what you mean. However I am not sure about the
plain stupid 
because the list of open project will not be very long. 

Jens

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Jul 2, 2007, at 3:47 AM, Jens Herden wrote:

> On Sunday 01 July 2007, Matt Rogers wrote:
>> On Jul 1, 2007, at 11:10 AM, Andreas Pakulat
wrote:
>>> On 01.07.07 16:21:14, Jens Herden wrote:
>>>> we have:
>>>>
>>>>     virtual IProject* projectAt( int )
const = 0;
>>>>     virtual int projectCount() const = 0;
>>>>     virtual QList<IProject*>
projects() const = 0;
>>>>
>>>>
>>>> Do we really need all of them? I think it
should be OK to drop
>>>> projectAt() and
>>>> projectCount() .
>>>
>>> Well, according to our wiki we should drop
QList<IProject*>  
>>> projects()
>>> const;
>>> http://www.kdevelop.org/mediawiki/index.php/Platfor
m_API_TODO
>>>
>>> I added the two count/at methods specifically
because of this note.
>>>
>>> Andreas
>>
>> We need to keep all three of them. The first two
that don't return a
>> list are for scripting purposes (think usage from
dbus commandline)
>> and the one that returns the list is for C++ usage.
IMHO, requiring
>> index iteration from C++ is just plain stupid when
we can use  
>> iterators.
>
> I understand what you mean. However I am not sure about
the plain  
> stupid
> because the list of open project will not be very
long.
>
> Jens
>

It doesn't matter how long the list is. But IMO, the use of
a non  
object-oriented construct (in this case, index-based
iteration) in  
object oriented code is really quite silly.
--
Matt



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 02 July 2007, Matt Rogers wrote:
> It doesn't matter how long the list is. But IMO, the
use of a non  
> object-oriented construct (in this case, index-based
iteration) in  
> object oriented code is really quite silly.

OT: And I think it is a matter of taste...

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Hi!

Il giorno 01/lug/07, alle ore 16:21, Jens Herden ha
scritto:

> Hi,
>
> we have:
>
>     virtual IProject* projectAt( int ) const = 0;
>     virtual int projectCount() const = 0;
>     virtual QList<IProject*> projects() const =
0;
>
>
> Do we really need all of them? I think it should be OK
to drop  
> projectAt() and
> projectCount() .

if you want drop one you should drop projects() 
projectAt(int) is  
virtual and it returns a pointer to an IProject. That's
great,  
because you can use covariant returns to keep your code
clean and  
simple. For example, if AutomakeProject extends IProject you
can write
   virtual AutomakeProject *projectAt(int index) { ... }

then you don't need awful casts from IProject* to
AutomakeProject* in  
your plug-in.

ciao robe


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel