I first started with the C language using TurboC moving up to the full C++ with both borland/ms extensions. For the last couple of (dry) years, I have not needed to do full bore projects. As a result I switched to VB to make those quick util progs. Now that I am back into full(+1/2)-time coding, and using .NET now, I was wondering which direction would be better to take. I realise that I can create different 'modules' using either language and add them into a final project, but at the moment I am a one man team, so all the code will be mine. Which one is better for speed? and size? I've already noticed that VB.NET takes a lot of the drudgery out of code typing by auto-completing/formating a lot more than C# does, but C# provides a lot more control over events and interfaces. Does anyone have any thoughts or facts to put forward? I am interested in hearing what side other people have chosen and the reasons for it.
Jul 21 '05
106  3547 
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:u8**************@TK2MSFTNGP12.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eT**************@TK2MSFTNGP10.phx.gbl...
To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer
not
to use VB or use classes written using the interface mapping.
Just out of curiosity, what exactly bothers you about the interface
mapping? It seems very intuitive to me.
I shouldn't say interface mapping as a whole, but I abhor the ability to
rename interface methods, it tends to break my expectations of the class.
For example if you use Close() to implement IDisposable.Dispose I'd be
against it. Hiding it is one thing(which I'm not to keen on either, fyi),
but I dislike the notion of renaming an interface method.
Jeremy
Jeremy Todd <jh****@uiuc.edu> wrote: Maybe my knowlegde is not up to date. last time I saw VB it was
a hybrid language like C++, that allowed normal functions or
variables not to belong to a class.
In .NET, all classes inherit from Object, so you can do the same thing
you can in C# and assign any type to an Object variable.
What does that have to do with variables and methods not belonging to a
class?
But you can also leave it out or forget it and you have a problem. What if
the implementor of the library you are using leaves it out?
If the implementer of the library you're using is a bad programmer, then
he's a bad programmer. Using a library written by someone who doesn't know
what he's doing will cause just as many problems no matter what language
he's using.
True. "Option strict" not being the default was a bad idea though, IMO.
<snip explanation of using different names>
It's a very useful mechanism, and can potentially save a lot of coding.
Being able to declare Private methods to implement the interface is useful
if you don't want to expose those methods outside the interface context; for
example, when you have an object which implements many interfaces and don't
want 100 methods cluttering things up when you'll never use them unless
you're already casting to that interface type.
You can do that with explicit interface implementation in C#.
Personally I don't like it, but there we go. a long time ago when I used pascal I also liked this feature but I also
saw that it leads to unreadable and ambigous code. now Iam glad that neither
C/C++ nor Java or C# have such a feature.
VB.NET doesn't have such a feature, either. VB's With mechanism is
neither unreadable nor ambiguous. In fact, I find
Dim myVariable As ListItem = New ListItem
With myVariable
.Text = "New Item"
.ForeColor = Color.Red
.BackColor = Color.LightGray
.Tag = 5
End With
to be more readable than
Dim myVariable As ListItem = New ListItem
myVariable.Text = "New Item"
myVariable.ForeColor = Color.Red
myVariable.BackColor = Color.LightGray
myVariable.Tag = 5
The key is to name your variables better, of course. I dislike "with"
blocks myself, like Cody.
<snip>
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jeremy Todd <jh****@uiuc.edu> wrote: Maybe my knowlegde is not up to date. last time I saw VB it was
a hybrid language like C++, that allowed normal functions or
variables not to belong to a class.
In .NET, all classes inherit from Object, so you can do the same thing
you can in C# and assign any type to an Object variable.
What does that have to do with variables and methods not belonging to a
class?
But you can also leave it out or forget it and you have a problem. What if
the implementor of the library you are using leaves it out?
If the implementer of the library you're using is a bad programmer, then
he's a bad programmer. Using a library written by someone who doesn't know
what he's doing will cause just as many problems no matter what language
he's using.
True. "Option strict" not being the default was a bad idea though, IMO.
<snip explanation of using different names>
It's a very useful mechanism, and can potentially save a lot of coding.
Being able to declare Private methods to implement the interface is useful
if you don't want to expose those methods outside the interface context; for
example, when you have an object which implements many interfaces and don't
want 100 methods cluttering things up when you'll never use them unless
you're already casting to that interface type.
You can do that with explicit interface implementation in C#.
Personally I don't like it, but there we go. a long time ago when I used pascal I also liked this feature but I also
saw that it leads to unreadable and ambigous code. now Iam glad that neither
C/C++ nor Java or C# have such a feature.
VB.NET doesn't have such a feature, either. VB's With mechanism is
neither unreadable nor ambiguous. In fact, I find
Dim myVariable As ListItem = New ListItem
With myVariable
.Text = "New Item"
.ForeColor = Color.Red
.BackColor = Color.LightGray
.Tag = 5
End With
to be more readable than
Dim myVariable As ListItem = New ListItem
myVariable.Text = "New Item"
myVariable.ForeColor = Color.Red
myVariable.BackColor = Color.LightGray
myVariable.Tag = 5
The key is to name your variables better, of course. I dislike "with"
blocks myself, like Cody.
<snip>
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Cody,
German is case sensitive. The word "Rennen" is a noun, whereas "rennen" is
a verb.
If that was in all with latin written languages than it could be a very good
extention to all program languages.
That could make sense in my opinion when it was in program languages the
same. However I never have seen that. (And although German is the major
language in the EU, I think it is very rare for other people).
Cor
Hi Cody,
German is case sensitive. The word "Rennen" is a noun, whereas "rennen" is
a verb.
If that was in all with latin written languages than it could be a very good
extention to all program languages.
That could make sense in my opinion when it was in program languages the
same. However I never have seen that. (And although German is the major
language in the EU, I think it is very rare for other people).
Cor
> > And VB.NET supports lots of features that C# doesn't have: better interface implementation support (in VB.NET, any method with any scope
and name can implement one or more interface methods -- this is a HUGE plus
for
me, and the primary reason I chose VB.NET over C#), With blocks, etc.
There
are pros and cons to both languages.
To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer not
to use VB or use classes written using the interface mapping.
However, support for exception filters, safer event raising, and a MyClass
are things I'd like to have equivilents of in C# (although exception
filters and MyClass accesses are things I wouldn't use often at all, I do wish
they were there).
What do you mean by Exception filters and MyClass? Could you give an
example?
--
cody
Freeware Tools, Games and Humour http://www.deutronium.de.vu || http://www.deutronium.tk
> > And VB.NET supports lots of features that C# doesn't have: better interface implementation support (in VB.NET, any method with any scope
and name can implement one or more interface methods -- this is a HUGE plus
for
me, and the primary reason I chose VB.NET over C#), With blocks, etc.
There
are pros and cons to both languages.
To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer not
to use VB or use classes written using the interface mapping.
However, support for exception filters, safer event raising, and a MyClass
are things I'd like to have equivilents of in C# (although exception
filters and MyClass accesses are things I wouldn't use often at all, I do wish
they were there).
What do you mean by Exception filters and MyClass? Could you give an
example?
--
cody
Freeware Tools, Games and Humour http://www.deutronium.de.vu || http://www.deutronium.tk
Cor Ligthert <no**********@planet.nl> wrote: German is case sensitive. The word "Rennen" is a noun, whereas "rennen" is
a verb.
If that was in all with latin written languages than it could be a very good
extention to all program languages.
That could make sense in my opinion when it was in program languages the
same. However I never have seen that. (And although German is the major
language in the EU, I think it is very rare for other people).
Here's another example: "Reading" vs "reading" - Reading is a town,
reading is an activity. You can easily distinguish between the two
within an English sentence (assuming it's not the first word of the
sentence) by case.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Cor Ligthert <no**********@planet.nl> wrote: German is case sensitive. The word "Rennen" is a noun, whereas "rennen" is
a verb.
If that was in all with latin written languages than it could be a very good
extention to all program languages.
That could make sense in my opinion when it was in program languages the
same. However I never have seen that. (And although German is the major
language in the EU, I think it is very rare for other people).
Here's another example: "Reading" vs "reading" - Reading is a town,
reading is an activity. You can easily distinguish between the two
within an English sentence (assuming it's not the first word of the
sentence) by case.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Jon,
Here's another example: "Reading" vs "reading" - Reading is a town,
reading is an activity. You can easily distinguish between the two
within an English sentence (assuming it's not the first word of the
sentence) by case.
I assume this one is in every language written with Latin characters (I know
it from 6) . And as I said, I think that it would be a greath extention to
all program languages if the German way was used. There could be even done
checking on it when typing it in the IDE.
However I have not seen in a language ReaDing or things like that.
Cor
Hi Jon,
Here's another example: "Reading" vs "reading" - Reading is a town,
reading is an activity. You can easily distinguish between the two
within an English sentence (assuming it's not the first word of the
sentence) by case.
I assume this one is in every language written with Latin characters (I know
it from 6) . And as I said, I think that it would be a greath extention to
all program languages if the German way was used. There could be even done
checking on it when typing it in the IDE.
However I have not seen in a language ReaDing or things like that.
Cor
Cor Ligthert <no**********@planet.nl> wrote: Here's another example: "Reading" vs "reading" - Reading is a town,
reading is an activity. You can easily distinguish between the two
within an English sentence (assuming it's not the first word of the
sentence) by case.
I assume this one is in every language written with Latin characters (I know
it from 6) . And as I said, I think that it would be a greath extention to
all program languages if the German way was used. There could be even done
checking on it when typing it in the IDE.
However I have not seen in a language ReaDing or things like that.
No - but that's because in computer languages we use other conventions
than spaces to separate words within tokens, using spaces to separate
actual tokens.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Cor Ligthert <no**********@planet.nl> wrote: Here's another example: "Reading" vs "reading" - Reading is a town,
reading is an activity. You can easily distinguish between the two
within an English sentence (assuming it's not the first word of the
sentence) by case.
I assume this one is in every language written with Latin characters (I know
it from 6) . And as I said, I think that it would be a greath extention to
all program languages if the German way was used. There could be even done
checking on it when typing it in the IDE.
However I have not seen in a language ReaDing or things like that.
No - but that's because in computer languages we use other conventions
than spaces to separate words within tokens, using spaces to separate
actual tokens.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too No - but that's because in computer languages we use other conventions
than spaces to separate words within tokens, using spaces to separate
actual tokens.
For me that proves that we are still in the middle ages with programming
languages.
The same things are in the books from those times.
:-)
Cor No - but that's because in computer languages we use other conventions
than spaces to separate words within tokens, using spaces to separate
actual tokens.
For me that proves that we are still in the middle ages with programming
languages.
The same things are in the books from those times.
:-)
Cor
"cody" <no****************@gmx.net> wrote in message
news:O9**************@TK2MSFTNGP09.phx.gbl... > And VB.NET supports lots of features that C# doesn't have: better
> interface implementation support (in VB.NET, any method with any scope and > name can implement one or more interface methods -- this is a HUGE plus
> for
> me, and the primary reason I chose VB.NET over C#), With blocks, etc.
> There
> are pros and cons to both languages.
> To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer
not
to use VB or use classes written using the interface mapping.
However, support for exception filters, safer event raising, and a
MyClass
are things I'd like to have equivilents of in C# (although exception
filters and MyClass accesses are things I wouldn't use often at all, I do wish
they were there).
What do you mean by Exception filters and MyClass? Could you give an
example?
Exception Filters: http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called on
this results in the most derived method being called, when its called on
somthing like MyClass, the version defined in the class that makes the call
is used. If that makes any sense...
--
cody
Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"cody" <no****************@gmx.net> wrote in message
news:O9**************@TK2MSFTNGP09.phx.gbl... > And VB.NET supports lots of features that C# doesn't have: better
> interface implementation support (in VB.NET, any method with any scope and > name can implement one or more interface methods -- this is a HUGE plus
> for
> me, and the primary reason I chose VB.NET over C#), With blocks, etc.
> There
> are pros and cons to both languages.
> To show a bit of a difference in peoples opinions, the above features are
two of things I really dislike about VB. Enough so that I would prefer
not
to use VB or use classes written using the interface mapping.
However, support for exception filters, safer event raising, and a
MyClass
are things I'd like to have equivilents of in C# (although exception
filters and MyClass accesses are things I wouldn't use often at all, I do wish
they were there).
What do you mean by Exception filters and MyClass? Could you give an
example?
Exception Filters: http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called on
this results in the most derived method being called, when its called on
somthing like MyClass, the version defined in the class that makes the call
is used. If that makes any sense...
--
cody
Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... What does that have to do with variables and methods not belonging to a
class?
Ah, I misunderstood the question. I thought he was referring to late
binding again. Yes, VB.NET does allow methods and variables outside of a
class definition, though I'm not sure how this is implemented internally. I
agree this is a bad idea, so I never use it myself.
True. "Option strict" not being the default was a bad idea though, IMO.
Agreed. I have no idea why they chose to do it this way.
The key is to name your variables better, of course. I dislike "with"
blocks myself, like Cody.
Well, Cody's reasons for disliking them didn't apply to VB.NET. What
don't you like about them, if I may ask?
Jeremy
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... What does that have to do with variables and methods not belonging to a
class?
Ah, I misunderstood the question. I thought he was referring to late
binding again. Yes, VB.NET does allow methods and variables outside of a
class definition, though I'm not sure how this is implemented internally. I
agree this is a bad idea, so I never use it myself.
True. "Option strict" not being the default was a bad idea though, IMO.
Agreed. I have no idea why they chose to do it this way.
The key is to name your variables better, of course. I dislike "with"
blocks myself, like Cody.
Well, Cody's reasons for disliking them didn't apply to VB.NET. What
don't you like about them, if I may ask?
Jeremy
> > What do you mean by Exception filters and MyClass? Could you give an example?
Exception Filters:
http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
I cannot imaginge when this can ever be useful. You can use a rethrow
instead.
I read that the debugger cannot find the orignin of rethrown exceptions but
you can
set the debugger that it catches exception first-chance.
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called on
this results in the most derived method being called, when its called on
somthing like MyClass, the version defined in the class that makes the
call is used. If that makes any sense...
Interesting feature. I found that in C# there is _no way_ to call the
original method that was overridden!
I tried everything but nothing worked (as expected):
class A
{
public A()
{
a();
this.a();
((A)this).a();
}
public virtual void a(){Console.WriteLine("a");}
}
class B : A
{
public override void a(){Console.WriteLine("b");}
}
But there are certainly very rare circumstances where you really would need
that feature
and I think you can still solve it using reflection if you really want.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
> > What do you mean by Exception filters and MyClass? Could you give an example?
Exception Filters:
http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
I cannot imaginge when this can ever be useful. You can use a rethrow
instead.
I read that the debugger cannot find the orignin of rethrown exceptions but
you can
set the debugger that it catches exception first-chance.
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called on
this results in the most derived method being called, when its called on
somthing like MyClass, the version defined in the class that makes the
call is used. If that makes any sense...
Interesting feature. I found that in C# there is _no way_ to call the
original method that was overridden!
I tried everything but nothing worked (as expected):
class A
{
public A()
{
a();
this.a();
((A)this).a();
}
public virtual void a(){Console.WriteLine("a");}
}
class B : A
{
public override void a(){Console.WriteLine("b");}
}
But there are certainly very rare circumstances where you really would need
that feature
and I think you can still solve it using reflection if you really want.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl... I shouldn't say interface mapping as a whole, but I abhor the ability to
rename interface methods, it tends to break my expectations of the class.
For example if you use Close() to implement IDisposable.Dispose I'd be
against it.
I don't know if there's any getting around it, really, since I believe
many of the classes in the .NET Framework itself do this. System.IO.Stream
certainly behaves this way, though I don't know if the Close method actually
implements IDisposable.Dispose, or merely calls a hidden implementation of
it. Same difference to the developer, though.
In cases where I want to make it absolutely clear that I'm intending to
call an interface method, I always cast the object to that interface type
first:
DirectCast(MyObject, IDisposable).Dispose
Hiding it is one thing(which I'm not to keen on either, fyi),
but I dislike the notion of renaming an interface method.
This preference of mine probably stems from one particularly huge
project I worked on. There were a good, oh, 50 or 60 interfaces used
internally by the project, but that didn't need to be exposed to consumers
of the assembly. Any given class could implement 10 or more of these
interfaces. If the interface implementation hadn't been hidden, the classes
would've had dozens of methods that not only cluttered things up, but
actually exposed functionality that the consumer wasn't supposed to have
access to. I found VB.NET to be much more convenient in handling this than
C#, especially since a lot of those interfaces had methods in common, and
being able to use a single method to implement multiple interfaces made
maintenance easier in this case. For cases when you wouldn't want to do
that, because the behavior of one of those interfaces may change down the
line, you of course have the option of doing it the old-fashioned way.
MANY classes in the Framework have hidden interface implementations,
too -- just about any implementation of IList hides most of its members, for
example.
Jeremy
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl... I shouldn't say interface mapping as a whole, but I abhor the ability to
rename interface methods, it tends to break my expectations of the class.
For example if you use Close() to implement IDisposable.Dispose I'd be
against it.
I don't know if there's any getting around it, really, since I believe
many of the classes in the .NET Framework itself do this. System.IO.Stream
certainly behaves this way, though I don't know if the Close method actually
implements IDisposable.Dispose, or merely calls a hidden implementation of
it. Same difference to the developer, though.
In cases where I want to make it absolutely clear that I'm intending to
call an interface method, I always cast the object to that interface type
first:
DirectCast(MyObject, IDisposable).Dispose
Hiding it is one thing(which I'm not to keen on either, fyi),
but I dislike the notion of renaming an interface method.
This preference of mine probably stems from one particularly huge
project I worked on. There were a good, oh, 50 or 60 interfaces used
internally by the project, but that didn't need to be exposed to consumers
of the assembly. Any given class could implement 10 or more of these
interfaces. If the interface implementation hadn't been hidden, the classes
would've had dozens of methods that not only cluttered things up, but
actually exposed functionality that the consumer wasn't supposed to have
access to. I found VB.NET to be much more convenient in handling this than
C#, especially since a lot of those interfaces had methods in common, and
being able to use a single method to implement multiple interfaces made
maintenance easier in this case. For cases when you wouldn't want to do
that, because the behavior of one of those interfaces may change down the
line, you of course have the option of doing it the old-fashioned way.
MANY classes in the Framework have hidden interface implementations,
too -- just about any implementation of IList hides most of its members, for
example.
Jeremy
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...
I shouldn't say interface mapping as a whole, but I abhor the ability to
rename interface methods, it tends to break my expectations of the class.
For example if you use Close() to implement IDisposable.Dispose I'd be
against it.
I don't know if there's any getting around it, really, since I believe
many of the classes in the .NET Framework itself do this.
System.IO.Stream
certainly behaves this way, though I don't know if the Close method
actually
implements IDisposable.Dispose, or merely calls a hidden implementation of
it. Same difference to the developer, though.
It calls an explicit implementation of IDisposable.Dispose(or Dispose calls
Close, I forget which way it goes, that doesn't really matter). Although I'd
rather have not seen Dispose hidden, that was a choice made by the
developers, probably to avoid confusing consumers.
In cases where I want to make it absolutely clear that I'm intending to
call an interface method, I always cast the object to that interface type
first:
DirectCast(MyObject, IDisposable).Dispose
That is generally the prefered way, although I don't really like the VB cast
operators either(not that C#'s are much better, I think I prefer the newer
C++ cast operators actually).
Hiding it is one thing(which I'm not to keen on either, fyi),
but I dislike the notion of renaming an interface method.
This preference of mine probably stems from one particularly huge
project I worked on. There were a good, oh, 50 or 60 interfaces used
internally by the project, but that didn't need to be exposed to consumers
of the assembly. Any given class could implement 10 or more of these
interfaces. If the interface implementation hadn't been hidden, the
classes
would've had dozens of methods that not only cluttered things up, but
actually exposed functionality that the consumer wasn't supposed to have
access to. I found VB.NET to be much more convenient in handling this
than
C#, especially since a lot of those interfaces had methods in common, and
being able to use a single method to implement multiple interfaces made
maintenance easier in this case. For cases when you wouldn't want to do
that, because the behavior of one of those interfaces may change down the
line, you of course have the option of doing it the old-fashioned way.
MANY classes in the Framework have hidden interface implementations,
too -- just about any implementation of IList hides most of its members,
for
example.
As I said, hiding is one thing(although I rarely like hiding part of the
interface and exposing the rest), but renaming is quite another. While the
convience of implementing multiple similar methods is nice, it makes me
wonder why you had so many identical methods across so many interfaces. That
bothers me. But I'm not here to critique a project I've never seen.
In most cases, I don't think that interface members should be hidden, with
the exception of IDisposable when a Close method exists, IList(when in the
presence of strongly typed equivilent members, IList<T> will probably remove
all need to hide its members completely), and a very, very, small number of
others(which I can't think of right now).
Jeremy
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%2****************@TK2MSFTNGP09.phx.gbl...
I shouldn't say interface mapping as a whole, but I abhor the ability to
rename interface methods, it tends to break my expectations of the class.
For example if you use Close() to implement IDisposable.Dispose I'd be
against it.
I don't know if there's any getting around it, really, since I believe
many of the classes in the .NET Framework itself do this.
System.IO.Stream
certainly behaves this way, though I don't know if the Close method
actually
implements IDisposable.Dispose, or merely calls a hidden implementation of
it. Same difference to the developer, though.
It calls an explicit implementation of IDisposable.Dispose(or Dispose calls
Close, I forget which way it goes, that doesn't really matter). Although I'd
rather have not seen Dispose hidden, that was a choice made by the
developers, probably to avoid confusing consumers.
In cases where I want to make it absolutely clear that I'm intending to
call an interface method, I always cast the object to that interface type
first:
DirectCast(MyObject, IDisposable).Dispose
That is generally the prefered way, although I don't really like the VB cast
operators either(not that C#'s are much better, I think I prefer the newer
C++ cast operators actually).
Hiding it is one thing(which I'm not to keen on either, fyi),
but I dislike the notion of renaming an interface method.
This preference of mine probably stems from one particularly huge
project I worked on. There were a good, oh, 50 or 60 interfaces used
internally by the project, but that didn't need to be exposed to consumers
of the assembly. Any given class could implement 10 or more of these
interfaces. If the interface implementation hadn't been hidden, the
classes
would've had dozens of methods that not only cluttered things up, but
actually exposed functionality that the consumer wasn't supposed to have
access to. I found VB.NET to be much more convenient in handling this
than
C#, especially since a lot of those interfaces had methods in common, and
being able to use a single method to implement multiple interfaces made
maintenance easier in this case. For cases when you wouldn't want to do
that, because the behavior of one of those interfaces may change down the
line, you of course have the option of doing it the old-fashioned way.
MANY classes in the Framework have hidden interface implementations,
too -- just about any implementation of IList hides most of its members,
for
example.
As I said, hiding is one thing(although I rarely like hiding part of the
interface and exposing the rest), but renaming is quite another. While the
convience of implementing multiple similar methods is nice, it makes me
wonder why you had so many identical methods across so many interfaces. That
bothers me. But I'm not here to critique a project I've never seen.
In most cases, I don't think that interface members should be hidden, with
the exception of IDisposable when a Close method exists, IList(when in the
presence of strongly typed equivilent members, IList<T> will probably remove
all need to hide its members completely), and a very, very, small number of
others(which I can't think of right now).
Jeremy
"cody" <pl*************************@gmx.de> wrote in message
news:u0**************@TK2MSFTNGP09.phx.gbl... > What do you mean by Exception filters and MyClass? Could you give an
> example?
> Exception Filters:
http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
I cannot imaginge when this can ever be useful. You can use a rethrow
instead.
I read that the debugger cannot find the orignin of rethrown exceptions
but
you can
set the debugger that it catches exception first-chance.
Thats not entirely true, rethrowing an exception changes things. The primary
use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called on
this results in the most derived method being called, when its called on
somthing like MyClass, the version defined in the class that makes the call is used. If that makes any sense...
Interesting feature. I found that in C# there is _no way_ to call the
original method that was overridden!
I tried everything but nothing worked (as expected):
class A
{
public A()
{
a();
this.a();
((A)this).a();
}
public virtual void a(){Console.WriteLine("a");}
}
class B : A
{
public override void a(){Console.WriteLine("b");}
}
But there are certainly very rare circumstances where you really would
need
that feature
and I think you can still solve it using reflection if you really want.
There is no real way to do it in C#. I have considered proposing the use of
the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.
Using reflection or the new dynamic methods in .net 2.0 it wouldn't be hard
at all. A dynamic method could be built with just the proper IL to make the
call to the method you want.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@tk2msftngp13.phx.gbl... As I said, hiding is one thing(although I rarely like hiding part of the
interface and exposing the rest), but renaming is quite another. While the
convience of implementing multiple similar methods is nice, it makes me
wonder why you had so many identical methods across so many interfaces.
Because they weren't necessarily identical for all implementations.
Suppose you had interfaces IMass, which has a property which returns the
mass of some item, and IWeight, which returns its weight. For class
GoldBrick, the implementations of those would be (mostly) identical. For
class HotAirBalloon, they'd be very different.
That's horribly oversimplified, of course, but it gives the general
idea.
In most cases, I don't think that interface members should be hidden, with
the exception of IDisposable when a Close method exists, IList(when in the
presence of strongly typed equivilent members, IList<T> will probably
remove all need to hide its members completely), and a very, very, small number
of others(which I can't think of right now).
What about implementations of non-public interfaces? :)
Jeremy
"cody" <pl*************************@gmx.de> wrote in message
news:u0**************@TK2MSFTNGP09.phx.gbl... > What do you mean by Exception filters and MyClass? Could you give an
> example?
> Exception Filters:
http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
I cannot imaginge when this can ever be useful. You can use a rethrow
instead.
I read that the debugger cannot find the orignin of rethrown exceptions
but
you can
set the debugger that it catches exception first-chance.
Thats not entirely true, rethrowing an exception changes things. The primary
use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called on
this results in the most derived method being called, when its called on
somthing like MyClass, the version defined in the class that makes the call is used. If that makes any sense...
Interesting feature. I found that in C# there is _no way_ to call the
original method that was overridden!
I tried everything but nothing worked (as expected):
class A
{
public A()
{
a();
this.a();
((A)this).a();
}
public virtual void a(){Console.WriteLine("a");}
}
class B : A
{
public override void a(){Console.WriteLine("b");}
}
But there are certainly very rare circumstances where you really would
need
that feature
and I think you can still solve it using reflection if you really want.
There is no real way to do it in C#. I have considered proposing the use of
the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.
Using reflection or the new dynamic methods in .net 2.0 it wouldn't be hard
at all. A dynamic method could be built with just the proper IL to make the
call to the method you want.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@tk2msftngp13.phx.gbl... As I said, hiding is one thing(although I rarely like hiding part of the
interface and exposing the rest), but renaming is quite another. While the
convience of implementing multiple similar methods is nice, it makes me
wonder why you had so many identical methods across so many interfaces.
Because they weren't necessarily identical for all implementations.
Suppose you had interfaces IMass, which has a property which returns the
mass of some item, and IWeight, which returns its weight. For class
GoldBrick, the implementations of those would be (mostly) identical. For
class HotAirBalloon, they'd be very different.
That's horribly oversimplified, of course, but it gives the general
idea.
In most cases, I don't think that interface members should be hidden, with
the exception of IDisposable when a Close method exists, IList(when in the
presence of strongly typed equivilent members, IList<T> will probably
remove all need to hide its members completely), and a very, very, small number
of others(which I can't think of right now).
What about implementations of non-public interfaces? :)
Jeremy
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:ex*************@TK2MSFTNGP12.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@tk2msftngp13.phx.gbl...
As I said, hiding is one thing(although I rarely like hiding part of the
interface and exposing the rest), but renaming is quite another. While
the
convience of implementing multiple similar methods is nice, it makes me
wonder why you had so many identical methods across so many interfaces.
Because they weren't necessarily identical for all implementations.
Suppose you had interfaces IMass, which has a property which returns the
mass of some item, and IWeight, which returns its weight. For class
GoldBrick, the implementations of those would be (mostly) identical. For
class HotAirBalloon, they'd be very different.
Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work the
same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics example
to qualify it. Once you do that, how do you seperate them again in a derived
class? You could say I don't like the conceptual muxing of different ideas
for convenience.
That's horribly oversimplified, of course, but it gives the general
idea.
In most cases, I don't think that interface members should be hidden,
with
the exception of IDisposable when a Close method exists, IList(when in
the
presence of strongly typed equivilent members, IList<T> will probably remove all need to hide its members completely), and a very, very, small number
of others(which I can't think of right now).
What about implementations of non-public interfaces? :)
How often are non-public interfaces on public types a good idea? IMHO not
very often. ;) You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal POV.
Jeremy
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:u4**************@TK2MSFTNGP11.phx.gbl... Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work
the same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics
example to qualify it. Once you do that, how do you seperate them again in a
derived class? You could say I don't like the conceptual muxing of different ideas
for convenience.
Yes, this was discussed at length. :) In the end, we decided the pros
and cons slightly favored doing it my way, because the class hierarchy was
determined early on and we knew well in advance how each class would behave.
How often are non-public interfaces on public types a good idea? IMHO not
very often. ;) You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal POV.
I don't follow. How is the use of non-public interfaces different from
non-public class members? Are you also opposed to private fields and
methods? :)
Jeremy
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:ex*************@TK2MSFTNGP12.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@tk2msftngp13.phx.gbl...
As I said, hiding is one thing(although I rarely like hiding part of the
interface and exposing the rest), but renaming is quite another. While
the
convience of implementing multiple similar methods is nice, it makes me
wonder why you had so many identical methods across so many interfaces.
Because they weren't necessarily identical for all implementations.
Suppose you had interfaces IMass, which has a property which returns the
mass of some item, and IWeight, which returns its weight. For class
GoldBrick, the implementations of those would be (mostly) identical. For
class HotAirBalloon, they'd be very different.
Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work the
same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics example
to qualify it. Once you do that, how do you seperate them again in a derived
class? You could say I don't like the conceptual muxing of different ideas
for convenience.
That's horribly oversimplified, of course, but it gives the general
idea.
In most cases, I don't think that interface members should be hidden,
with
the exception of IDisposable when a Close method exists, IList(when in
the
presence of strongly typed equivilent members, IList<T> will probably remove all need to hide its members completely), and a very, very, small number
of others(which I can't think of right now).
What about implementations of non-public interfaces? :)
How often are non-public interfaces on public types a good idea? IMHO not
very often. ;) You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal POV.
Jeremy
> >> Exception Filters: http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
I cannot imaginge when this can ever be useful. You can use a rethrow
instead.
I read that the debugger cannot find the orignin of rethrown exceptions
but
you can
set the debugger that it catches exception first-chance.
Thats not entirely true, rethrowing an exception changes things. The
primary use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.
Hm I have to agree now. I wonder why they didn't implement that in C# but
instead did it in VB?
Is there any reasoing behind that?
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called
on this results in the most derived method being called, when its called
on somthing like MyClass, the version defined in the class that makes the
call is used. If that makes any sense...
Interesting feature. I found that in C# there is _no way_ to call the
original method that was overridden!
I tried everything but nothing worked (as expected):
class A
{
public A()
{
a();
this.a();
((A)this).a();
}
public virtual void a(){Console.WriteLine("a");}
}
class B : A
{
public override void a(){Console.WriteLine("b");}
}
But there are certainly very rare circumstances where you really would
need
that feature
and I think you can still solve it using reflection if you really want.
There is no real way to do it in C#. I have considered proposing the use
of the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.
Using the keyword class for other purposes than declaring a class was my
idea too a few weeks ago.
I wanted to use it to get the current type of the class:
static void Foo()
{
Type t = class
Console.Writeline("Iam declared in " + t);
}
Since GetType() is not available in static methods and hardcoding the class
via typeof(MyClass) is errorprone and confusing,
I find using "class" here is completely fine.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:u4**************@TK2MSFTNGP11.phx.gbl... Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work
the same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics
example to qualify it. Once you do that, how do you seperate them again in a
derived class? You could say I don't like the conceptual muxing of different ideas
for convenience.
Yes, this was discussed at length. :) In the end, we decided the pros
and cons slightly favored doing it my way, because the class hierarchy was
determined early on and we knew well in advance how each class would behave.
How often are non-public interfaces on public types a good idea? IMHO not
very often. ;) You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal POV.
I don't follow. How is the use of non-public interfaces different from
non-public class members? Are you also opposed to private fields and
methods? :)
Jeremy
> >> Exception Filters: http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
I cannot imaginge when this can ever be useful. You can use a rethrow
instead.
I read that the debugger cannot find the orignin of rethrown exceptions
but
you can
set the debugger that it catches exception first-chance.
Thats not entirely true, rethrowing an exception changes things. The
primary use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.
Hm I have to agree now. I wonder why they didn't implement that in C# but
instead did it in VB?
Is there any reasoing behind that?
MyClass on the other hand allows direct access to the current classes
members without considering virutality. Where a virtual method called
on this results in the most derived method being called, when its called
on somthing like MyClass, the version defined in the class that makes the
call is used. If that makes any sense...
Interesting feature. I found that in C# there is _no way_ to call the
original method that was overridden!
I tried everything but nothing worked (as expected):
class A
{
public A()
{
a();
this.a();
((A)this).a();
}
public virtual void a(){Console.WriteLine("a");}
}
class B : A
{
public override void a(){Console.WriteLine("b");}
}
But there are certainly very rare circumstances where you really would
need
that feature
and I think you can still solve it using reflection if you really want.
There is no real way to do it in C#. I have considered proposing the use
of the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.
Using the keyword class for other purposes than declaring a class was my
idea too a few weeks ago.
I wanted to use it to get the current type of the class:
static void Foo()
{
Type t = class
Console.Writeline("Iam declared in " + t);
}
Since GetType() is not available in static methods and hardcoding the class
via typeof(MyClass) is errorprone and confusing,
I find using "class" here is completely fine.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
"cody" <pl*************************@gmx.de> wrote in message
news:eI**************@TK2MSFTNGP10.phx.gbl... >> Exception Filters:
> http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
>
> I cannot imaginge when this can ever be useful. You can use a rethrow
> instead.
> I read that the debugger cannot find the orignin of rethrown exceptions
> but
> you can
> set the debugger that it catches exception first-chance.
Thats not entirely true, rethrowing an exception changes things. The
primary use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.
Hm I have to agree now. I wonder why they didn't implement that in C# but
instead did it in VB?
Is there any reasoing behind that?
Best I've seen was from Eric Gunnerson, said something about it being
possible but that it didn't offer anything so they hadn't decided to do it
yet. >> MyClass on the other hand allows direct access to the current classes
>> members without considering virutality. Where a virtual method called on >> this results in the most derived method being called, when its called on >> somthing like MyClass, the version defined in the class that makes the
> call
>> is used. If that makes any sense...
>
> Interesting feature. I found that in C# there is _no way_ to call the
> original method that was overridden!
> I tried everything but nothing worked (as expected):
>
> class A
> {
> public A()
> {
> a();
> this.a();
> ((A)this).a();
> }
> public virtual void a(){Console.WriteLine("a");}
> }
>
> class B : A
> {
> public override void a(){Console.WriteLine("b");}
> }
>
> But there are certainly very rare circumstances where you really would
> need
> that feature
> and I think you can still solve it using reflection if you really want.
There is no real way to do it in C#. I have considered proposing the use
of the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.
Using the keyword class for other purposes than declaring a class was my
idea too a few weeks ago.
I wanted to use it to get the current type of the class:
Yes, I remember. It was actually what finally gave me the bit of syntax I
needed for deciding on this. static void Foo()
{
Type t = class
Console.Writeline("Iam declared in " + t);
}
I would rather see typeof(class) over just assigning class.
Since GetType() is not available in static methods and hardcoding the
class
via typeof(MyClass) is errorprone and confusing,
I find using "class" here is completely fine.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
"cody" <pl*************************@gmx.de> wrote in message
news:eI**************@TK2MSFTNGP10.phx.gbl... >> Exception Filters:
> http://blogs.msdn.com/toub/archive/2.../05/84698.aspx
>
> I cannot imaginge when this can ever be useful. You can use a rethrow
> instead.
> I read that the debugger cannot find the orignin of rethrown exceptions
> but
> you can
> set the debugger that it catches exception first-chance.
Thats not entirely true, rethrowing an exception changes things. The
primary use(which in VB I consider a bit of a malformation) is to access the
exception without the change in the stack frame which occurs when you
actually enter a catch block. Also, rethrowing doesn't continue down the
catch handlers in the current try\catch set, while returning false from a
filter does.
Hm I have to agree now. I wonder why they didn't implement that in C# but
instead did it in VB?
Is there any reasoing behind that?
Best I've seen was from Eric Gunnerson, said something about it being
possible but that it didn't offer anything so they hadn't decided to do it
yet. >> MyClass on the other hand allows direct access to the current classes
>> members without considering virutality. Where a virtual method called on >> this results in the most derived method being called, when its called on >> somthing like MyClass, the version defined in the class that makes the
> call
>> is used. If that makes any sense...
>
> Interesting feature. I found that in C# there is _no way_ to call the
> original method that was overridden!
> I tried everything but nothing worked (as expected):
>
> class A
> {
> public A()
> {
> a();
> this.a();
> ((A)this).a();
> }
> public virtual void a(){Console.WriteLine("a");}
> }
>
> class B : A
> {
> public override void a(){Console.WriteLine("b");}
> }
>
> But there are certainly very rare circumstances where you really would
> need
> that feature
> and I think you can still solve it using reflection if you really want.
There is no real way to do it in C#. I have considered proposing the use
of the keyword class for this several times, I've yet to take the time to
implement it to test its fundamentals and see if it works.
Using the keyword class for other purposes than declaring a class was my
idea too a few weeks ago.
I wanted to use it to get the current type of the class:
Yes, I remember. It was actually what finally gave me the bit of syntax I
needed for deciding on this. static void Foo()
{
Type t = class
Console.Writeline("Iam declared in " + t);
}
I would rather see typeof(class) over just assigning class.
Since GetType() is not available in static methods and hardcoding the
class
via typeof(MyClass) is errorprone and confusing,
I find using "class" here is completely fine.
--
cody
[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
Jeremy Todd <jh****@uiuc.edu> wrote: The key is to name your variables better, of course. I dislike "with"
blocks myself, like Cody.
Well, Cody's reasons for disliking them didn't apply to VB.NET. What
don't you like about them, if I may ask?
General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jeremy Todd <jh****@uiuc.edu> wrote: The key is to name your variables better, of course. I dislike "with"
blocks myself, like Cody.
Well, Cody's reasons for disliking them didn't apply to VB.NET. What
don't you like about them, if I may ask?
General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:O5**************@TK2MSFTNGP09.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:u4**************@TK2MSFTNGP11.phx.gbl...
Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work the same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics
example to qualify it. Once you do that, how do you seperate them again in a
derived class? You could say I don't like the conceptual muxing of different
ideas
for convenience.
Yes, this was discussed at length. :) In the end, we decided the pros
and cons slightly favored doing it my way, because the class hierarchy was
determined early on and we knew well in advance how each class would
behave.
How often are non-public interfaces on public types a good idea? IMHO not
very often. ;) You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal
POV.
I don't follow. How is the use of non-public interfaces different from
non-public class members? Are you also opposed to private fields and
methods? :)
Merely that they are interfaces. Its not so much a necessity as a goal I
strive to reach. I don't like to implement internal interfaces on public
classes, I'd rather rely on managers\factories and implement the interfaces
there and write the public classes without interfaces designed for internal
usage.
I also do my best to avoid designs which rely on internal members(I can't
think of the VB keyword for this, but assembly only access). They are a
nessecery evil in many cases, but something I always look for other ways
around. I don't mean that protected methods or private method(which usually
are helpers for public or protected methods) shouldn't exist, just that when
possible an interface should strive to be public and if a class can't expose
all its externally required behaviour publically there is probably a better
design available. However, this is a guideline I try to follow, not a
steadfast rule; I have written more than one internal interface\method in my
lifetime. Jeremy
"Jeremy Todd" <jh****@uiuc.edu> wrote in message
news:O5**************@TK2MSFTNGP09.phx.gbl... "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:u4**************@TK2MSFTNGP11.phx.gbl...
Yes, but I'd argue that IMass.Mass and IWeight.Weight, even if they work the same in one situation, are entirely different and as a matter of
understanding using the same method to implement them isn't going to make
code that makes immediate sense. Although I can't think of a physics
example to qualify it. Once you do that, how do you seperate them again in a
derived class? You could say I don't like the conceptual muxing of different
ideas
for convenience.
Yes, this was discussed at length. :) In the end, we decided the pros
and cons slightly favored doing it my way, because the class hierarchy was
determined early on and we knew well in advance how each class would
behave.
How often are non-public interfaces on public types a good idea? IMHO not
very often. ;) You should be designing your architecture so that public
types contain mostly publically accessible functionality(or underlying
protected functionality for virtuality). However, that is my personal
POV.
I don't follow. How is the use of non-public interfaces different from
non-public class members? Are you also opposed to private fields and
methods? :)
Merely that they are interfaces. Its not so much a necessity as a goal I
strive to reach. I don't like to implement internal interfaces on public
classes, I'd rather rely on managers\factories and implement the interfaces
there and write the public classes without interfaces designed for internal
usage.
I also do my best to avoid designs which rely on internal members(I can't
think of the VB keyword for this, but assembly only access). They are a
nessecery evil in many cases, but something I always look for other ways
around. I don't mean that protected methods or private method(which usually
are helpers for public or protected methods) shouldn't exist, just that when
possible an interface should strive to be public and if a class can't expose
all its externally required behaviour publically there is probably a better
design available. However, this is a guideline I try to follow, not a
steadfast rule; I have written more than one internal interface\method in my
lifetime. Jeremy
Hi Jon,
General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.
Although we agree this one completely, is this the same as using distinction
between upper and lowercase in C derived languages (and a lot more older
languages).
You are not obligated to use it.
Cor
Hi Jon,
General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.
Although we agree this one completely, is this the same as using distinction
between upper and lowercase in C derived languages (and a lot more older
languages).
You are not obligated to use it.
Cor
Cor Ligthert <no**********@planet.nl> wrote: General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.
Although we agree this one completely, is this the same as using distinction
between upper and lowercase in C derived languages (and a lot more older
languages).
You are not obligated to use it.
That's never a good enough reason, IMO - if a feature is present,
people *will* use it, and like it or not, we don't always read code
that we've written ourselves.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Cor Ligthert <no**********@planet.nl> wrote: General readability. There seems absolutely no need for it, and it
makes the context of a statement harder to see.
Although we agree this one completely, is this the same as using distinction
between upper and lowercase in C derived languages (and a lot more older
languages).
You are not obligated to use it.
That's never a good enough reason, IMO - if a feature is present,
people *will* use it, and like it or not, we don't always read code
that we've written ourselves.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Jon,
There is a very simple question in the VB.language group, almost everybody
was busy with it.
There is this sentence in.
dialogresult = me.show
My answer was this is not possible, when you want to do that it should be
with a new created form and a showdialog.
I did not understand how he would do this. Now he says he got the program
from someone else and it is to complex for him to read. I think there is
something in that program as.
\\\
Shadows Sub Show()
Dim frm As New Form2
Dim result As DialogResult
result = frm.ShowDialog()
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Me.Hide()
Me.Show()
Me.Button1.Parent.Show()
End Sub
///
I told that if this is true that he was working in my idea, as I call them,
by the
maker obfuscated program.
Maybe it is not this code or something (I see now that it should be minimal
a function with a return of the result) however than you are talking about
the "with". Which what I said we agree. (second time in two days)
:-)
Cor
I hope you understand the last row of this message, I see now, that I
corrected it to often.
The meaning is.
Maybe it is not exactly this code what is made (I see now too that it should
be minimal function with a return of the result)
However if it is this kind of code why should we than talk about the "with"/
Cor
Hi Jon,
There is a very simple question in the VB.language group, almost everybody
was busy with it.
There is this sentence in.
dialogresult = me.show
My answer was this is not possible, when you want to do that it should be
with a new created form and a showdialog.
I did not understand how he would do this. Now he says he got the program
from someone else and it is to complex for him to read. I think there is
something in that program as.
\\\
Shadows Sub Show()
Dim frm As New Form2
Dim result As DialogResult
result = frm.ShowDialog()
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Me.Hide()
Me.Show()
Me.Button1.Parent.Show()
End Sub
///
I told that if this is true that he was working in my idea, as I call them,
by the
maker obfuscated program.
Maybe it is not this code or something (I see now that it should be minimal
a function with a return of the result) however than you are talking about
the "with". Which what I said we agree. (second time in two days)
:-)
Cor
Cor Ligthert <no**********@planet.nl> wrote: There is a very simple question in the VB.language group, almost everybody
was busy with it.
There is this sentence in.
dialogresult = me.show
My answer was this is not possible, when you want to do that it should be
with a new created form and a showdialog.
What was not possible? Sorry, you haven't said what the actual question
was...
I did not understand how he would do this. Now he says he got the program
from someone else and it is to complex for him to read. I think there is
something in that program as.
\\\
Shadows Sub Show()
Dim frm As New Form2
Dim result As DialogResult
result = frm.ShowDialog()
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Button1.Click
Me.Hide()
Me.Show()
Me.Button1.Parent.Show()
End Sub
///
I told that if this is true that he was working in my idea, as I call them,
by the maker obfuscated program.
Maybe it is not this code or something (I see now that it should be minimal
a function with a return of the result) however than you are talking about
the "with". Which what I said we agree. (second time in two days)
I'm afraid I really didn't follow any of that... what point were you
trying to make again?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I hope you understand the last row of this message, I see now, that I
corrected it to often.
The meaning is.
Maybe it is not exactly this code what is made (I see now too that it should
be minimal function with a return of the result)
However if it is this kind of code why should we than talk about the "with"/
Cor
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: William C. White |
last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using
cURL? Our website is hosted on a shared drive and the webhost company
doesn't installed additional software (such as cURL)...
|
by: Albert Ahtenberg |
last post by:
Hello,
I don't know if it is only me but I was sure that header("Location:url")
redirects the browser instantly to URL, or at least stops the execution of
the code. But appearantely it continues...
|
by: James |
last post by:
Hi,
I have a form with 2 fields.
'A'
'B'
The user completes one of the fields and the form is submitted.
On the results page I want to run a query, but this will change
subject to which...
|
by: Ollivier Robert |
last post by:
Hello,
I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9
system. The link succeeds but everytime I try to run php, I get a SEGV from
inside the libcnltsh.so library.
...
|
by: Richard Galli |
last post by:
I want viewers to compare state laws on a single subject.
Imagine a three-column table with a drop-down box on the top. A viewer
selects a state from the list, and that state's text fills the...
|
by: Albert Ahtenberg |
last post by:
Hello,
I have two questions.
1. When the user presses the back button and returns to a form he filled
the form is reseted. How do I leave there the values he inserted?
2. When the...
|
by: inderjit S Gabrie |
last post by:
Hi all
Here is the scenerio ...is it possibly to do this...
i am getting valid course dates output on to a web which i have designed
....all is okay so far , look at the following web url
...
|
by: Jack |
last post by:
Hi All,
What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g.
select x from y where z=:parameter
Which in asp/jsp would be followed by some statements to bind a value...
|
by: Sandwick |
last post by:
I am trying to change the size of a drawing so they are all 3x3.
the script below is what i was trying to use to cut it in half ... I
get errors.
I can display the normal picture but not the...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
