Why is passing the owner object ByVal more appropriate than ByRef? I thought ByRef because I wish to store the application object's reference. Am I misunderstanding VB's use of ByVal and ByRef?
Charles Rapp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
VB.NET 2003 gives me a compiler error -- it will *not* accept ByRef parameters to Property Set(). I believe that in .NET, using ByVal parameters with objects is akin to something like "const SomeDataType &" in C++. (Forgive my rusty C++ syntax -- it's been years since I've done C++.) So ByVal, I believe, does *not* do an expensive copy when passed as a parameter; hence .NET refusing to allow you to use a ByRef parameter in this case is not such a bad thing, in fact, it makes a certain amount of sense, given the Property Set usage:
Dim someObject As SomeObjectType
myObject.MyProperty = someObject
' Functionally equivalent to this:
' myObject.set_MyProperty(someObject)
Can you imagine the havoc that would result if setting myObject.Property changed what someObject referred to? So the ByVal restriction completely makes sense to me.
As you can see from the patch, there was also a missing "End Set" statement.
Anyway, in the mean time, love this project, so much so that I thought I would contribute my (tiny) changes back. I was thinking of implementing Namespaces in VB, when I have some spare time. I'm in Japan
- Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hit "Post Comment" prematurely, so my message got cut off.
I'm in Japan for a few weeks, so I won't be making any Namespace changes for a while.
I'm new to SourceForge and could not submit a bug report -- what's the best way to submit a patch that I think might be handy? This forum? I would like to contribute a Namespace change if I ever get around to it.
Thanks.
- Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I love this project! Unfortunately, there are some minor errors in the VB.NET code generation, which I have fixed here:
--- 1.4/SmcVBGenerator.java 2006-06-11 20:02:54.278543000 +0900
+++ SmcVBGenerator.java 2006-06-11 20:02:01.160077600 +0900
@@ -24,7 +24,7 @@
// examples/Python.
//
// RCS ID
-// $Id: SmcVBGenerator.java,v 1.4 2006/06/03 19:39:25 cwrapp Exp $
+// $Id: SmcVBGenerator.java,v 1.3 2005/11/07 19:34:54 cwrapp Exp $
//
// CHANGE LOG
// (See the bottom of this file.)
@@ -236,17 +236,18 @@
_source.println(" Get");
_source.println(" Return _owner");
_source.println(" End Get");
- _source.print(" Set(ByRef owner As ");
+ _source.print(" Set(ByVal owner As ");
_source.print(context);
_source.println(")");
_source.println();
_source.println(" If owner Is Nothing _");
_source.println(" Then");
_source.println(
- " Throw New NullPointerException");
+ " Throw New NullReferenceException");
_source.println(" End If");
_source.println();
_source.println(" _owner = owner");
+ _source.println(" End Set");
_source.println(" End Property");
_source.println();
@@ -868,7 +869,7 @@
{
_source.println();
_source.print(
- " Public Overrides Sub Exit(ByRef context As ");
+ " Public Overrides Sub Exit_(ByRef context As ");
_source.print(context);
_source.println("Context)");
_source.println();
@@ -1557,9 +1558,6 @@
//
// CHANGE LOG
// $Log: SmcVBGenerator.java,v $
-// Revision 1.4 2006/06/03 19:39:25 cwrapp
-// Final v. 4.3.1 check in.
-//
// Revision 1.3 2005/11/07 19:34:54 cwrapp
// Changes in release 4.3.0:
// New features:
I forgot to mention that this is Visual Studio .NET 2003, a.k.a. .NET Framework 1.1.
I have not used SMC with VS 2005 (.NET 2.0).
My apologies. Here is the patch I wanted to upload, for VS 2003 (.NET CLR 1.1):
239c239
< _source.print(" Set(ByRef owner As ");
---
> _source.print(" Set(ByVal owner As ");
246c246
< " Throw New NullPointerException");
---
> " Throw New NullReferenceException");
249a250
> _source.println(" End Set");
James,
Why is passing the owner object ByVal more appropriate than ByRef? I thought ByRef because I wish to store the application object's reference. Am I misunderstanding VB's use of ByVal and ByRef?
Charles Rapp
Charles,
VB.NET 2003 gives me a compiler error -- it will *not* accept ByRef parameters to Property Set(). I believe that in .NET, using ByVal parameters with objects is akin to something like "const SomeDataType &" in C++. (Forgive my rusty C++ syntax -- it's been years since I've done C++.) So ByVal, I believe, does *not* do an expensive copy when passed as a parameter; hence .NET refusing to allow you to use a ByRef parameter in this case is not such a bad thing, in fact, it makes a certain amount of sense, given the Property Set usage:
Dim someObject As SomeObjectType
myObject.MyProperty = someObject
' Functionally equivalent to this:
' myObject.set_MyProperty(someObject)
Can you imagine the havoc that would result if setting myObject.Property changed what someObject referred to? So the ByVal restriction completely makes sense to me.
As you can see from the patch, there was also a missing "End Set" statement.
Anyway, in the mean time, love this project, so much so that I thought I would contribute my (tiny) changes back. I was thinking of implementing Namespaces in VB, when I have some spare time. I'm in Japan
- Jim
I hit "Post Comment" prematurely, so my message got cut off.
I'm in Japan for a few weeks, so I won't be making any Namespace changes for a while.
I'm new to SourceForge and could not submit a bug report -- what's the best way to submit a patch that I think might be handy? This forum? I would like to contribute a Namespace change if I ever get around to it.
Thanks.
- Jim
Jim,
I submitted the bug report. It is bug 1504804.
Charles