> Virtual is default in VB.NET, not in C#...
No, it's not :)
FB
>
>
> Thanks,
>
> Shawn Wildermuth
> Wildermuth Consulting Services, LLC
> http://adoguy.com
> C# MVP, MCSD.NET, Author and Speaker
>
>
> > -Original Message-
> > From: Discussion of advanced .NET top
If you read any text on OO, it uses terms such as virtual, abstract etc.
VB and C# have virtual and abstract (although VB uses different keywords
to fit in with the language) - I learned OO programming from a Java book
because it spoke in terms of virtual and abstract, and those concepts
applied di
Just for completeness:
- VB.NET is *not* virtual by default
- "Overloads" is the C# equivalent to "new" in C# (not Overrides like my
example showed)
- "Overridable" is the VB.NET equivalent to "virtual" in C#
- "Overrides" is the VB.NET equivalent to "override" in C#
So nevermind...my confusion w
Nevermind, I am an idiot...this shows jus the opposite...the base class's
Run was called.
Thanks,
Shawn Wildermuth
Wildermuth Consulting Services, LLC
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
> -Original Message-
> From: Discussion of advanced .NET topics.
> [mailto:[EMAI
This is how I tested it:
Module Module1
Sub Main()
Dim test As T = New X
test.Run()
Console.Read()
End Sub
End Module
Class T
Public Sub Run()
Console.WriteLine("T.Run()")
End Sub
End Class
Class X
Inherits T
Public Overloads Sub Run()
Console.WriteLine(
Shawn Wildermuth <[EMAIL PROTECTED]> wrote:
> Really Barry...I'll have to look at that again...I don't spend as much time
> in VB as I do C# so I am probably wrong...
I just tried it with a simple file:
Imports System
Public Class App
Shared Sub Main()
Console.WriteLine("Hello Worl
Really Barry...I'll have to look at that again...I don't spend as much time
in VB as I do C# so I am probably wrong...
Thanks,
Shawn Wildermuth
Wildermuth Consulting Services, LLC
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
> -Original Message-
> From: Discussion of advanced
David Lanouette <[EMAIL PROTECTED]> wrote:
> Thanks for the reply Barry.
>
> >They require two, independent, sets of semantics: one for callers
> > and another for implementers.
>
> What do you mean by this?
If you're calling a virtual method, you simply expect it to do
something. That's relati
Keywords have nothing to do with OO; they're pure language design. OO
contains the concepts of "virtual" and "non-virtual"; how a specific
language maps keywords to those concepts (as in Java's default = virtual and
"final" = non-virtual) is up to the individual language.
On 7/7/06, Dean Cleaver
Thanks for the reply Barry.
>They require two, independent, sets of semantics: one for callers
> and another for implementers.
What do you mean by this?
> Inheritance is probably the closest coupling that can be
> created between two classes, and we all know why coupling is
> bad when designing
Stoyan Damov <[EMAIL PROTECTED]> wrote:
> I think Shawn meant to say that methods are virtual by default in VB,
> nothing to do w/ the keyword used to denote that.
Actually, VB.NET defaults to non-virtual. Overridable is the equivalent
of "virtual", while NotOverridable corresponds to "sealed".
I think Shawn meant to say that methods are virtual by default in VB,
nothing to do w/ the keyword used to denote that.
On 7/8/06, David Lanouette <[EMAIL PROTECTED]> wrote:
Forgive my VB ignorance...
> Virtual is default in VB.NET
Then what is the Overridable keyword for?
___
Forgive my VB ignorance...
> Virtual is default in VB.NET
Then what is the Overridable keyword for?
__
- David Lanouette
- [EMAIL PROTECTED]
"Excellence, then, is not an act, but a habit" - Aristotle
> -Original Message-
> From: Discussion of advanced .N
Virtual is default in VB.NET, not in C#...
Thanks,
Shawn Wildermuth
Wildermuth Consulting Services, LLC
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
> -Original Message-
> From: Discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of
> David Lanouette
> S
On 7/8/06, David Lanouette <[EMAIL PROTECTED]> wrote:
Anybody know why methods aren't virtual by default in .NET? It seems like a
really bad default to have all methods non-virtual.
Because in theory, there's an overhead in calling a virtual as opposed
to non-virtual method. In practice, if yo
David Lanouette <[EMAIL PROTECTED]> wrote:
> Anybody know why methods aren't virtual by default in .NET? It seems like a
> really bad default to have all methods non-virtual.
If you consider the design and maintenance implications, it's actually
an incredibly bad idea to have methods default to
Java and other OO languages seem to get around it very nicely.
In Java all methods are virtual by default. If you want a method to be
non-virtual you mark it as final (yah, I know it's not quite the same). So,
why can't .NET?
> there is no keyword for "non-virtual".
C# and VB.NET are both new l
Because in OO programming, there is no keyword for "non-virtual".
It's an OO issue, not a .Net issue.
Dino
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of David
Lanouette
Sent: Saturday, 8 July 2006 11:37
To: ADVANCED-DOTNET@DISCUSS.DE
Anybody know why methods aren't virtual by default in .NET? It seems like a
really bad default to have all methods non-virtual.
__
- David Lanouette
- [EMAIL PROTECTED]
"Excellence, then, is not an act, but a habit" - Aristotle
===
Th
Mike,
I think the thing you might be missing is the "virtual" key word on your
methods. That's what corresponds to "Overridable" in VB. In C# and VB,
methods aren't virtual by default (one thing Java got right, IMHO)
If you don't add that then any child classes that had a Remove() method
would
I'm guessing that VB does something similar behind the scenes when compiling
to IL.
Otherwise it doesn't make any sense that VB allows such a construct but C#
does not.
In VB6, your interface definitions always had to be private (it's been a
while since I've done anything with VB6) and always acc
If the interface isnt public then the explicit implementation's only
difference is the need to go through the interface as opposed to the object.
If you really want internal methods on your object as well .. (I would
recommend using the interface instead but it seems to be your goal)
class Fo
It shouldn't have been public. That was a mistake on my part.
On 7/7/06, Shawn Wildermuth <[EMAIL PROTECTED]> wrote:
Then why is the interface public?
Thanks,
Shawn Wildermuth
Wildermuth Consulting Services, LLC
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
> -Original Messag
Make IBusiness interface internal.
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Andrews
Sent: Friday, July 07, 2006 15:22
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Implementing an Interface - C# vs. V
Then why is the interface public?
Thanks,
Shawn Wildermuth
Wildermuth Consulting Services, LLC
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
> -Original Message-
> From: Discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Andrews
> Sent: Friday, J
If you really want the protected internal you can accomplish something
similar with the following
class FooBase :IFoo {
protected virtual internal void internalbar() {
Console.WriteLine("FooBase");
}
void IFoo.Bar() {
this.internalbar();
}
The answer is that I want these methods to be utilized only within the
context of the namespace they are in. I don't want them accessible outside,
but only used as internal features of the object.
Thanks,
Mike
On 7/7/06, Shawn Wildermuth <[EMAIL PROTECTED]> wrote:
Then I would:
public abstra
The only thing you I don't think you can do is make the explicit
implementation also a protected internal (although this doesn't make much
sense anyways since you are exposing it through a public interface). YOu can
still reimplement the interface without issue.
public interface IFoo {
Doh! I meant base.Remove() in the derived class, not base:Remove().
Thanks,
Shawn Wildermuth
Wildermuth Consulting Services, LLC
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker
> -Original Message-
> From: Discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behal
Then I would:
public abstract class T: IBusiness {
public virtual void Remove() {
throw new Exception("The method or operation is not implemented.");
}
public virtual void Save() {
throw new Exception("The method or operation is not implemented.");
}
public virtual Guid ID {
Thank you.
However, that does not help with the idea that a base class implements an
interface and then I re-implement the interface on derived classes where
needed. This is so that ever class that inherits from the base class also
implements the interface, even if I do not re-implement it for t
What do you suggest in it's place?
I'm looking for something similar, but I'm uncertain as to how to do it.
Thanks,
Mike
On 7/7/06, Shawn Wildermuth <[EMAIL PROTECTED]> wrote:
I would probably *not* have the abstract class implement the interface,
since you'll need to have your derived classe
You have to do whats called "explicitly implementing" a interface. See
http://msdn2.microsoft.com/en-us/library/4taxa8t2.aspx
Cheers,
Greg
On 7/7/06, Mike Andrews <[EMAIL PROTECTED]> wrote:
Guys,
I have a question that I need some help with in regards to implementing an
interface.
I've been
I would probably *not* have the abstract class implement the interface,
since you'll need to have your derived classes expose the interface as
public members. Then your derived classes could just call the
protected/internal methods to do the work of the interface.
I am not sure why VB.NET allows
Guys,
I have a question that I need some help with in regards to implementing an
interface.
I've been a VB programmer for most of my career and now I use C#. Some of
the functionality that I used in VB seems to be lacking in C#.
I wanted to know if it's my imagination or if there's a workaround.
> It seems that the fact that the first Assembly.LoadFrom()
> call failed is
> cached in the current process and any subsequent calls to
> load the same DLL
> automatically fail.
>
> Is this a change in .NET 2.0?
Apparently so, although I can't find it documented anywhere after a cursory
look. Bu
Im not sure if the behavior changed, you may already be aware of this, but it
may help to turn on fusion logging:
HKLM\Software\Microsoft\Fusion
DWORD EnableLog=1
you can also run fuslogvw from a vs command prompt
-Original Message-
From: Charles Gamble <[EMAIL PROTECTED]>
Sent: Fri, 07
Thanks for the suggestion.
Unfortunately, this app is done in 1.x.
Cheers!
Dave
- Original Message -
From: "Sebastien Lorion" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 07, 2006 8:47 AM
Subject: Re: [ADVANCED-DOTNET] trim byte array
Have you looked at PowerCollections ? It has a BigLis
This clause prevents use with GPL type of license but as far as I
know, there is no problem with LGPL or MIT for example.
Sébastien
On 7/7/06, Barry Kelly <[EMAIL PROTECTED]> wrote:
Sebastien Lorion <[EMAIL PROTECTED]> wrote:
> Have you looked at PowerCollections ?
A caution about PowerCollec
Hi,
We have an application that generates .NET assembly DLLs at runtime and
executes them. It normally generates the assembly DLL once per user task and
any time the same user task is done again it simply loads the already
existing DLL and executes it.
We are using the .NET Code DOM to compile
Sebastien Lorion <[EMAIL PROTECTED]> wrote:
> Have you looked at PowerCollections ?
A caution about PowerCollections: it has a bizarre license. In
particular, this term here:
---8<---
In return, we simply require that you agree:
[...]
B. That you are not allowed to combine or distribute the
Have you looked at PowerCollections ? It has a BigList class which I think
would solve your problem of resizing.
Basically, it is a balanced tree of small arrays (length is 256 in release mode
i think). We use it here and it is really fast. The big plus of that collection
is that insertion and
42 matches
Mail list logo
