Rehashing NEW keyword a SECOND time, right NOW...

[Larry Serflaten]

Thanks for responding, it seems we are addressing the same problem,
using two different solutions. I would rather see the code all appear
uniform. As it is now, some things need 'New' while others do not.
I simply think we could remove New without loss of function. In as much
as the user can already declare similarly named variables at different scopes,
they will know that such things can cause problems.

I did not see how your C++ example applied to the VB problem other than
as an example of operator error! <g>

This example:

> Dim Person As Person
> Dim Person2 As Person
>
> Person2 = Person

Is similar to this:

Dim Integer As Integer ' or
Dim Long As Long

Which is not allowed, it is an invalid use of a keyword and is caught by the
syntax checker. That same checker could flag your statement as an ambigious
variable name, thereby eliminating the ambiguity problem before it gets compiled.

LFS


"Stephen Goguen" <sgoguen@nospam.hormel.goeinc.com> wrote

>
> One characteristic of a good programming language or environment is
> to make things as easy as possible so one can focus thier efforts on
> writing code rather than resolving ambigious statements.
>
> I would assume that most people would choose to type the three character
> "New", rather than hunting down bugs which are derived from ambiguity.
>
> The C++ novice and sometimes expect comes across this cute bug...
>
> if(x = 5) {
> // do something here
> }
>
> which should be
>
> if(x == 5) {
> // do something here
> }
>
> Don't get me wrong, this would probably be a neat feature for another
> language for those who elect to use this paradigm, but for most people
> I think it would cause too many headaches.
>
>
> > > Obvioulsy it would be really easy to get a clean compile even if the
> code
> > > you wrote is not what you actually intended to do...
> >
> > You lost me...
>
> In your scenerio as other posters have pointed out:
>
> Dim Person As Person
> Dim Person2 As Person
>
> Person2 = Person
>
> Would compile correctly, but may or may not do what is intended to do,
> much
> like the example I gave above. This isn't the case with the current
> situation as it
> is always clear you're specifying a class name rather than a variable name.
>
> Personally, If I was going to try to implement your idea, I would
> probably
> denote instantiating an object by adding parenthesis which would include
> class
> names with functions instead of including class names with variable names.
>
> Ex:
>
> Dim Person As Person
> Dim Person2 As Person
>
> 'Instantiates a new object
> Person2 = Person()
>
> 'Person2 references Person
> Person2 = Person
>
> This would allow you to defined variable names that do not conflict with
> objects,
> but your object names now conflict with functions which is certainly a more
> favorable situation than the former.
>
> Personally, I would still have to favor the New keyword as it clearly
> highlights
> the intended action. However, with some modification and evolution, your
> idea
> may prove to have some merit.
>
> Steve
>
>

[Ronald Laeremans [MSFT]]

Just to make sure non VC users are aware that if you use this construct the
VC compiler will emit a warning. In this case 2 warnings, 1 because you have
an assignment in a conditional, 1 because your conditional expression is
statically true. If you optimize this, there will be no conditional left in
the generated code.

-Ronald-

"Stephen Goguen" <sgoguen@nospam.hormel.goeinc.com> wrote in message
news:3b27d2fc@news.devx.com...
> The C++ novice and sometimes expect comes across this cute bug...
>
> if(x = 5) {
> // do something here
> }
>
> which should be
>
> if(x == 5) {
> // do something here
> }

[Patrice Scribe]

Unfortunately creating an object and making an object reference pointing to
the same object are *not* the same operation and should for this reason use
a different syntax to avoid confusion.

Anyway "New" is there and there is no plan to remove this keyword. Perhaps
the source of this confusion is class methods that are available at the
class level (and New is probably not needed though may work) rather than
instance methods that are working against a particular instance that needs
first to be created (but once again I'm not familiar yet with VB.NET).

--
Patrice Scribe

--
Patrice Scribe
"Larry Serflaten" <serflaten@usinternet.com> a écrit dans le message news:
3b27bea5@news.devx.com...
>
> "Gregor R. Peisker" <gregor@peisker.de> wrote
>
> > Sub Test()
> > Dim a, b As SomeClass ' create 2 refs
> > a = New SomeClass ' create 1 object, assign ref to a
>
> >
> > Here, there's only one object. In fact, there is nothing whatsoever in
VB.NET
> > code that can be regarded as an object. In this respect, the mantra that
> > "everything is an object" sounds all the more dubious.
>
> You only have one reference to a base class, aside from the Dim line.
That is
> the only one that is created. The others were only references, and you
did not
> assign them refering to the base class name.
>
> Look again, what was the advantage that New offered, that could not be
done
> using the base class's name?
>
> a = SomeClass
>
> As far as everything being an object, all I can say is; if it walks like a
duck, and
> quacks like a duck.... :-)
>
> LFS
>
>
>
>
>

[Gregor R. Peisker]

Hi Larry,

> You only have one reference to a base class, aside from the Dim line. That is
> the only one that is created. The others were only references, and you did
not
> assign them refering to the base class name.

OK, I have one Nothing reference ...

> Look again, what was the advantage that New offered, that could not be done
> using the base class's name?
>
> a = SomeClass

You mean, assigning a class name to a reference creates an instance? I don't
support this. The "New" keyword makes things more obvious, IMO. I want to be
able to find out about the number of instances I create - quickly. I think
"instance" is so fundamental a concept that I really, really want to know. But
maybe that's just me.

Anyway, it seems that the workings of class instantiation in VB are widely
misunderstood, so I would very much like for the language to keep the "New"
keyword.

Regards,
Gregor

[Gregor R. Peisker]

Hi Joe,

I'd like to clarify that I was refering to structures in VB.NET. Does this begin
to address the issue? Or perhaps even finalize it, deterministically?

Sorry about the misunderstanding here ...

Regards,
Gregor

> Eh? Structs don't support inheritance? When did this change? In _The C++
> Programming Language Third Edition_ Bjarne Stroustrup ISBN 0-201-88954-4
> section 10.2.8, "By definition, a /struct/ is a class in which members
> are by default public". The grammar in section A.8 supports this. Heck,
> it looks like even *unions* support inheritance! To wit:

[Gregor R. Peisker]

Hi Ted,

I was referring to structures in VB.NET.

As for the rest of your reply, I'm not sure whom you're addressing, and I don't
know what a "prick" is (for the record, anyway), so I'll leave that as it
stands.

Regards,
Gregor

[Larry Serflaten]

"Gregor R. Peisker" <gregor@peisker.de> wrote
> > Look again, what was the advantage that New offered, that could not be done
> > using the base class's name?
> >
> > a = SomeClass
>
> You mean, assigning a class name to a reference creates an instance? I don't
> support this.

Have you noticed how long the Let keyword has been optional? New could be
optional as well, could it not?

LFS

[Gregor R. Peisker]

Hi Larry,

> Have you noticed how long the Let keyword has been optional? New could be
> optional as well, could it not?

That's a different issue, IMO, but again, I'd prefer clarity here.

Of course, at the risk of prompting some reaction from the .Not camp, I'll say
that because Java and C# have the new operator, VB.NET should have it as well
:-).

Regards,
Gregor

[Ted]

>Do you deny that had I not already known the particulars of structs, I
>wouldn't have known that bit about structs' not supporting inheritance
>was wrong?

Actually yes. Being the great engineer that you are, I would have thought
that would come off the top of your head from your vast experiences. Does
something so basic in C++ need backup from Bjarne? Can you think on your
own? Judging from some of your other posts you rely on what you're told without
doing a little research on your own.


"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>"Ted" <TTarney@hotmail.com> wrote in message <news:3b27c7ea$1@news.devx.com>...
>
>> As for you prick, I would assume with all your knowledge of Star Wars
and
>> all the other half cocked projects you supposedly worked on would know
the
>> particulars of structs without reading them. Good job on the ISBN also.
>
>Do you deny that had I not already known the particulars of structs, I
>wouldn't have known that bit about structs' not supporting inheritance
>was wrong? Do you deny that providing a cite before having to be asked
>for it saved a little time for everyone involved? The book was nearby,
>and I had to look it up to be certain anyway, so whyever not?
>
>> Can you quote the C++ standard also.
>
>Not by heart. That's what reference works are for!
>
>--
>Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
>WARNING: I cannot be held responsible for the above They're coming
to
>because my cats have apparently learned to type. take me away,
ha ha!
>
>

[Patrick Steele]

In article <3b282700@news.devx.com> (from Larry Serflaten
<serflaten@usinternet.com>),
> Dim Integer As Integer ' or
> Dim Long As Long
>
> Which is not allowed, it is an invalid use of a keyword and is caught by the
> syntax checker.

I thought you could use wrap keywords in brackets if you wanted to use
them as variable/method names. Don't know *why* you would do this, but
I believe the syntax is:

Dim [Integer] As Integer
Dim [Long] As Long

--
Patrick Steele
(psteele@ipdsolution.com)
Lead Software Architect
Image Process Design

[Stephen Goguen]

> Dim Integer As Integer ' or
> Dim Long As Long
>
> Which is not allowed, it is an invalid use of a keyword and is caught by
the
> syntax checker. That same checker could flag your statement as an
ambigious
> variable name, thereby eliminating the ambiguity problem before it gets
compiled.
>
> LFS

Ok... This makes sense... I was under the assumption from a prior
post that you would allow to declare a variable Person if a person class
was defined.

However, I just thought of an issue which may lead you to lean towards
the usage of () after the class name. The one thing VB6 lacked was
constructors which allowed or required me to pass nessecary information
to the object upon creation. Example usage would be as below...

Dim mPerson As Person

'Creates a new person object and sets the name properties
Set mPerson = New Person("Stephen", "Goguen")

How would one go about doing this under your model?
Would you enclose the parameters in parenthesis or something
else, or would not support parameterized constructors?

If you do support parameterized constructors using something
like parameters, wouldn't it make it more consistant/uniform if
parameters or that something else were required?

Steve

[Ted]

Sorry. I was more replying to what Joe commented about. He was quoting out
of Stroustroups book. Forget what a prick is.

"Gregor R. Peisker" <gregor@peisker.de> wrote:
>Hi Ted,
>
>I was referring to structures in VB.NET.
>
>As for the rest of your reply, I'm not sure whom you're addressing, and
I don't
>know what a "prick" is (for the record, anyway), so I'll leave that as it
>stands.
>
>Regards,
>Gregor
>
>
>
>
>
>

[Larry Serflaten]

"Patrick Steele" <psteele@ipdsolution.com_> wrote
>
> I thought you could use wrap keywords in brackets if you wanted to use
> them as variable/method names. Don't know *why* you would do this, but
> I believe the syntax is:
>
> Dim [Integer] As Integer
> Dim [Long] As Long

You are correct sir!

But, the earlier examples were without backets. Now, really, because of their
usage:

Dim [Integer] As Integer

[Integer] = 4

msgbox([integer].ToString)

Doesn't it appear that the backets have simply changed the name?
That brings up the question about which objects need to be created again, as in:

msgbox(Integer.ToString)

Is a syntax error, lacking an object. What then?

msgbox(New Integer().ToString)

So here, New is required when it is implicit most everywhere else....
How about we get it all straightened out... How should we address
variables? <g>

I am saying go implicit.... Or at least have an option to! :-)

LFS

[Rohit Wason]

Larry,

We do need New Keyword in VB. This is because we need to distinguish between:

a) Object Creation and
b) Object Referencing.

a) above means that I want to "make" a new object called objPerson of class
Person so:
objPerson = New Person

b) above means that I already have an object pointer (or reference) as another
object or a function's output, and I just want another pointer (object) to
refer to it so:
objPerson1 = objPerson2

I see that "Set" is dropped because we dont deal with "Default" properties
so there is no confuasion like whether to set the whole object reference
or just the default property, New on the other hand is serving a different
purpose, which I see can not be done away with!

Cheers
Rohit


"Larry Serflaten" <serflaten@usinternet.com> wrote:
>Do we really need the New keyword at all? The Set keyword was dropped because
>all object assignments are now explicit object assignments, and not some
default
>property. Could we not drop the New keyword for similar reasons, that all
references
>to a named base class require a call to the base's New routine (constructor)?
>
>Is there a case where "= Person" would be used, without having to first
create a new
>Person object?

[Larry Serflaten]

"Stephen Goguen" <sgoguen@nospam.hormel.goeinc.com> wrote
> However, I just thought of an issue which may lead you to lean towards
> the usage of () after the class name. The one thing VB6 lacked was
> constructors which allowed or required me to pass nessecary information
> to the object upon creation. Example usage would be as below...
>
> Dim mPerson As Person
>
> 'Creates a new person object and sets the name properties
> Set mPerson = New Person("Stephen", "Goguen")
>
> How would one go about doing this under your model?

The parenthese would be required for parameters, so again, drop the New keyword,
and what have you?

Another interesting case is how value types normally do not use New, where the
reference types do, yet in this instance:

msgbox(New Integer().ToString)

New is required, as are your parentheses. Where is the consistancy there? Are
value types supposed to use New too? <g=sarcasm>


Whether we use "Integer" or "Integer()", could mean the same thing, a constructor
call without parameters, will create an instance. Using your parentheses might be
possible, but it still is something I would rather not deal with, at the BASIC level.
VB could add the trailing empty parentheses, only if required....

(Any one care for more auto-type features? <g>)

LFS