"Implement interface" issues

Hey all,

Not sure if the "Implement interface" feature is
ready to receive bug
reports...let me know and I'll just open this in Bugzilla.

I'm loving this feature but I've noticed the following
issues when
using "Implement interface":

1. Generics don't seem to be handled for parameters or
return types.
If I specify IList<string> for a return type, for
example, the
generated code will show IList<>.

2. Generated code uses verbose/awkward type names.  For
example: int
-> Int32, bool -> Boolean, void -> Void

3. Generated code doesn't follow Mono coding standards (no
space
between method name and open parentheses).

Thanks for all the great new stuff in SVN to play with!

Cheers,
Sandy
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

On Thu, 2007-05-24 at 22:55 -0700, Sanford Armstrong wrote:
> Hey all,
> 
> Not sure if the "Implement interface" feature
is ready to receive bug
> reports...let me know and I'll just open this in
Bugzilla.

nah, not too early 

> 
> I'm loving this feature but I've noticed the following
issues when
> using "Implement interface":
> 
> 1. Generics don't seem to be handled for parameters or
return types.
> If I specify IList<string> for a return type, for
example, the
> generated code will show IList<>.

ah, yea, forgot to implement that 

> 
> 2. Generated code uses verbose/awkward type names.  For
example: int
> -> Int32, bool -> Boolean, void -> Void

yea, this annoys me too but I'm not sure how to fix it... I
gotta read
up more on the CodeDom generator I guess.

> 
> 3. Generated code doesn't follow Mono coding standards
(no space
> between method name and open parentheses).

hmmm, I'll look into that (I thought it did, but maybe I
wasn't paying
close enough attention) - will probably require more CodeDom
foolery :

(I've just been constructing CodeDom stubs and then having
them generate
code and I seem to have very little control over the output
it
generates)

> 
> Thanks for all the great new stuff in SVN to play
with!

np 

> 
> Cheers,
> Sandy
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

On Fri, 2007-05-25 at 06:26 -0400, Jeffrey Stedfast wrote:
> On Thu, 2007-05-24 at 22:55 -0700, Sanford Armstrong
wrote:
> > Hey all,
> > 
> > Not sure if the "Implement interface"
feature is ready to receive bug
> > reports...let me know and I'll just open this in
Bugzilla.
> 
> nah, not too early 
> 
> > 
> > I'm loving this feature but I've noticed the
following issues when
> > using "Implement interface":
> > 
> > 1. Generics don't seem to be handled for
parameters or return types.
> > If I specify IList<string> for a return
type, for example, the
> > generated code will show IList<>.
> 
> ah, yea, forgot to implement that 

ok, I have a solution for this that I'm getting ready to
commit to svn

> 
> > 
> > 2. Generated code uses verbose/awkward type names.
 For example: int
> > -> Int32, bool -> Boolean, void -> Void
> 
> yea, this annoys me too but I'm not sure how to fix
it... I gotta read
> up more on the CodeDom generator I guess.

got a fix for this too (turns out it's not CodeDom's fault
afterall)

> 
> > 
> > 3. Generated code doesn't follow Mono coding
standards (no space
> > between method name and open parentheses).
> 
> hmmm, I'll look into that (I thought it did, but maybe
I wasn't paying
> close enough attention) - will probably require more
CodeDom foolery :
> 
> (I've just been constructing CodeDom stubs and then
having them generate
> code and I seem to have very little control over the
output it
> generates)

think I'm gonna have to write a hack for this...

> 
> > 
> > Thanks for all the great new stuff in SVN to play
with!
> 
> np 
> 
> > 
> > Cheers,
> > Sandy
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-listlists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Speaking of such:

Has anybody spoken up about having configurable code
formatting settings
yet? I *think* sharp develop supports this?

Basically a dialog where you can tell it whether you want a
space after
method names and a dropped '{'.

On Fri, 2007-05-25 at 14:37 -0400, Jeffrey Stedfast wrote:
> On Fri, 2007-05-25 at 06:26 -0400, Jeffrey Stedfast
wrote:
> > On Thu, 2007-05-24 at 22:55 -0700, Sanford
Armstrong wrote:
> > > Hey all,
> > > 
> > > Not sure if the "Implement
interface" feature is ready to receive bug
> > > reports...let me know and I'll just open this
in Bugzilla.
> > 
> > nah, not too early 
> > 
> > > 
> > > I'm loving this feature but I've noticed the
following issues when
> > > using "Implement interface":
> > > 
> > > 1. Generics don't seem to be handled for
parameters or return types.
> > > If I specify IList<string> for a return
type, for example, the
> > > generated code will show IList<>.
> > 
> > ah, yea, forgot to implement that 
> 
> ok, I have a solution for this that I'm getting ready
to commit to svn
> 
> > 
> > > 
> > > 2. Generated code uses verbose/awkward type
names.  For example: int
> > > -> Int32, bool -> Boolean, void ->
Void
> > 
> > yea, this annoys me too but I'm not sure how to
fix it... I gotta read
> > up more on the CodeDom generator I guess.
> 
> got a fix for this too (turns out it's not CodeDom's
fault afterall)
> 
> > 
> > > 
> > > 3. Generated code doesn't follow Mono coding
standards (no space
> > > between method name and open parentheses).
> > 
> > hmmm, I'll look into that (I thought it did, but
maybe I wasn't paying
> > close enough attention) - will probably require
more CodeDom foolery :
> > 
> > (I've just been constructing CodeDom stubs and
then having them generate
> > code and I seem to have very little control over
the output it
> > generates)
> 
> think I'm gonna have to write a hack for this...
> 
> > 
> > > 
> > > Thanks for all the great new stuff in SVN to
play with!
> > 
> > np 
> > 
> > > 
> > > Cheers,
> > > Sandy
> > >
_______________________________________________
> > > Monodevelop-list mailing list
> > > Monodevelop-listlists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
> > 
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-listlists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-li
st
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

On Fri, 2007-05-25 at 14:44 -0500, Jerome Haltom wrote:
> Speaking of such:
> 
> Has anybody spoken up about having configurable code
formatting settings
> yet? I *think* sharp develop supports this?
> 
> Basically a dialog where you can tell it whether you
want a space after
> method names and a dropped '{'.

this would be a really nice feature to have, just haven't
gotten around
to implementing it yet.

I think the tricky bit will be writing our own custom parser
for this,
because:

1. my custom smart-indent parser is pretty loose, too loose
to be able
to enforce style at the level we'd probably want

2. I get the feeling the parser we use for code completion
(which is AST
based I think) stuff is too strict (which isn't good for
re-formatting
code because the user may do it when the code is
incomplete/invalid in
some way... perhaps missing using statements or a typo, a
block isn't
closed, etc)


then again, perhaps I'm quite wrong about the AST parser



oh, and I gather that these formatting options would not be
applied
on-the-fly as you type, correct? Just when you invoke a menu
option...?
(that's how I recall it working in IDEs like Visual Studio,
but I could
be wrong...)

Obviously we'd also want to apply these rules when
inserting
auto-generated code as well (e.g. like the refactory
features)

Jeff


_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

On Fri, 2007-05-25 at 16:06 -0400, Jeffrey Stedfast wrote:
> 
> 1. my custom smart-indent parser is pretty loose, too
loose to be able
> to enforce style at the level we'd probably want
> 

actually, I think we could maybe add the necessary extra
bits of state
to the smart-indent parser... and the more I think about it,
the more I
think that something close to the smart-indent parser is
what we want
from a parser for this type of re-formatting because it's
simple, fast,
doesn't need to resolve type information, etc.

Jeff


_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st