Re: KDE/kdevplatform/plugins/subversion

On 29.07.07 07:26:33, dukju ahn wrote:
> 2007/7/29, Andreas Pakulat <apakugmx.de>:
> > On 29.07.07 06:54:16, dukju ahn wrote:
> > > 2007/7/29, Andreas Pakulat <apakugmx.de>:
> > > > On 29.07.07 04:58:06, dukju ahn wrote:
> > > > > 2007/7/28, Andreas Pakulat
<apakugmx.de>:
> > > > > > On 28.07.07 18:30:14, Dukju
Ahn wrote:
> > > > > > > ---
trunk/KDE/kdevplatform/plugins/subversion/svn_revision.h
#693699:693700
> > > > > > >  -24,6 +24,7 
> > > > > > >  #define SVN_REVERT  
(KDevelop::VcsJob::Revert)
> > > > > > >  #define SVN_COPY    
(KDevelop::VcsJob::Copy)
> > > > > > >  #define SVN_MOVE    
(KDevelop::VcsJob::Move)
> > > > > > > +#define SVN_CAT     
(KDevelop::VcsJob::Cat)
> > > > > >
> > > > > > Whats this? Apart from the
fact that you didn't commit the change in
> > > > > > vcsjob and thus broke the
build, why these defines? Whats the use case
> > > > > > for that?
> > > > >
> > > > > Because svn has its unique
operations that are not counted
> > > > > by our common interface. In most
cases its ok but, think about
> > > > > "svn switch", "svn
info". The VcsJob will not define enums for
> > > > > these operations, but subversion
plugin still needs this.
> > > > >
> > > > > So I had no choice but to define
job types again.
> > > >
> > > > I'm not questioning wether you need to
invent new enum values, but I'm
> > > > questioning the use of the #define's
here. #define is _not_ a proper
> > > > enum and I don't see a reason why you
have them and not use
> > > > KDevelop::VcsJob::Cat and Co directly -
or SvnJob::Info, SvnJob::Switch.
> > >
> > > But why is the #define too bad?
> >
> > Because they are unneeded and IMHO its just the
wrong tool for the job.
> > enum is a far better tool.
> 
> It's needed for uniformity. Suppose that in somewhere
we use
> VcsJob::Add and in other place we use SvnJob::Info.
They are different
> type. So I can't, at lease, use VcsJob enums directly.
> I need to redefine every enums in a single type.

AFAIK you can extend the existing VcsJob enum, but I
currently am not
100% sure how... There may be an example in Qt...

> > > It doesn't do any harm as far as the values
are defined correctly.
> > > What is the benefit if I redefine everything
into enum values such as
> > > SvnJob::commit ..?
> >
> > For example: proper typing and type checking by
the compiler, not
> > polluting the global namespace because the enum
values would be
> > "namespaced" by the class name in which
they are defined.
> 
> In point of syntax it is true.  But I'm not clear why
it should be
> confined to namespace. Also, the type is regarded just
"int". Then
> there is no problem is typechecking.

Yes there is a problem: You're loosing proper type checking
because then
you can use any int, wether its a properly understood value
or not,
thats the reason to use the enum type instead of the int. If
you use the
enum value the compiler will choke if you pass a non-enum
value in.

Andreas

-- 
You dialed 5483.

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

> > > > But why is the #define too bad?
> > >
> > > Because they are unneeded and IMHO its just
the wrong tool for the job.
> > > enum is a far better tool.
> >
> > It's needed for uniformity. Suppose that in
somewhere we use
> > VcsJob::Add and in other place we use
SvnJob::Info. They are different
> > type. So I can't, at lease, use VcsJob enums
directly.
> > I need to redefine every enums in a single type.
>
> AFAIK you can extend the existing VcsJob enum, but I
currently am not
> 100% sure how... There may be an example in Qt...
>
> > > > It doesn't do any harm as far as the
values are defined correctly.
> > > > What is the benefit if I redefine
everything into enum values such as
> > > > SvnJob::commit ..?
> > >
> > > For example: proper typing and type checking
by the compiler, not
> > > polluting the global namespace because the
enum values would be
> > > "namespaced" by the class name in
which they are defined.
> >
> > In point of syntax it is true.  But I'm not clear
why it should be
> > confined to namespace. Also, the type is regarded
just "int". Then
> > there is no problem is typechecking.
>
> Yes there is a problem: You're loosing proper type
checking because then
> you can use any int, wether its a properly understood
value or not,
> thats the reason to use the enum type instead of the
int. If you use the
> enum value the compiler will choke if you pass a
non-enum value in.

Well, thanks. I think I need to define new enums for
subversion later.

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