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

[Joe \Nuke Me Xemu\ Foster]

"Russell Jones" <arj1@northstate.net> wrote in message <news:3b26ea2f$1@news.devx.com>...

> Joe:
>
> Set *did* go away. Why don't you get a copy of VB.NET and try it?

This close to Beta 2? Any findings I have to report from B1 will merely
be met with, "Wait for Beta 2!" while anything I might find with Beta 2
will merely be met with "Wait for the release!" from the NDA'd. Or I
could sign the dotted line like Daniel Webster and Be In The Know, but
also likely be enjoined to stf up at last. Oh boy! Where can I sign up?

--
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!

[Gregor R. Peisker]

Hi Larry,

> The real question I wanted to address, one that I have sent feedback to MS
> on, is why the New keyword is needed for the creation of a new object? Unless
> I am mistaken, every reference to a base class will create a new object.

The "New" keyword is needed because of the perhaps most important
characteristic of classes (besides the usual OO gang of three) in VB and
VB.NET (and in C#, and Java as well) - *reference_semantics* (TM).

Because of reference semantics, we have the following keywords: Is, New,
Nothing, and, in VB6, Set. Not understanding that classes are reference types
is the cause of many a myth regarding object creation, duplication, reference
comparison, value comparison, parameter passing mechanisms, and so on.

Consider the following:

Sub Test()
Dim a, b As SomeClass ' create 2 refs
a = New SomeClass ' create 1 object, assign ref to a
b = a ' copy ref.
MySub(a) ' pass reference ByVal
Dim fRef, fVal As Boolean
fRef = (a Is b) ' True
fVal a.CompareTo(b) ' False (needs IComparable)
b = a.Clone ' copy object (needs ICloneable)
End Sub
Sub MySub(ByVal a As SomeClass)
a.SomeProp = 5 ' update the one and only object so
' far, using a copy of the reference
End Sub

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. It's all about
references. VB.NET forces reference semantics on you. Mostly, that suits
object-oriented programming better: encapsulate the data in one place.

If you want to choose, use C++ (which offers you value semantics, implicit
reference semantics with reference variables, or explicit use of pointers).
You can also use structures, which are light-weight value-type classes (but
they don't support inheritance, for example).

Regards,
Gregor

[Joe \Nuke Me Xemu\ Foster]

"Gregor R. Peisker" <gregor@peisker.de> wrote in message <news:3b27a64d@news.devx.com>...

> If you want to choose, use C++ (which offers you value semantics, implicit
> reference semantics with reference variables, or explicit use of pointers).
> You can also use structures, which are light-weight value-type classes (but
> they don't support inheritance, for example).

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:

/class-head:/
/class-key/ /identifier[opt]/ /base-clause[opt]/
/class-key/ /nested-name-specifier/ /identifier/ /base-clause[opt]/
/class-key/ /nested-name-specifier/ template /identifier/ /base-clause[opt]/

/class-key:/
class
struct
union

Now stand by for that Te(r)d-wit to reply with something completely inane...

--
Joe Foster <mailto:jfoster@ricochet.net> DC8s in Spaace: <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!

[Zane Thomas]

Joe,

> Now stand by for that Te(r)d-wit to reply with something completely
inane...

I'm going to ask you again to abide by the rules of this forum, as I have
been for many days. Your continued personal attacks are unnecessary and do
nothing to contribute to the debate. If you continue then later today or
tomorrow I'm going to take this issue up with the other section leaders, the
result could include cancelation of your posts which consistently - day
after day and hour after hour - violate this forum's rules.

An occasionaly exhuberant step over the line is typically ignored here. But
you've been way over the line for a long time.

Zane

[Zane Thomas]

Joe,

There's a post waiting for your reply on the off.ramp newsgroup.

Zane

[Larry Serflaten]

"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

[Ted]

Just can't get over can ya dumbass. Unfortunately this jerk off is right Gregor.
He does one **** of a job reading a ****ing book.

Gregor,
you can do this following with structs:

typedef struct _A
{
int x;
}A;

typedef struct _B : public A
{

}B;

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.
Can you quote the C++ standard also.


"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>"Gregor R. Peisker" <gregor@peisker.de> wrote in message <news:3b27a64d@news.devx.com>...
>
>> If you want to choose, use C++ (which offers you value semantics, implicit
>> reference semantics with reference variables, or explicit use of pointers).
>> You can also use structures, which are light-weight value-type classes
(but
>> they don't support inheritance, for example).
>
>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:
>
>/class-head:/
> /class-key/ /identifier[opt]/ /base-clause[opt]/
> /class-key/ /nested-name-specifier/ /identifier/ /base-clause[opt]/
> /class-key/ /nested-name-specifier/ template /identifier/ /base-clause[opt]/
>
>/class-key:/
> class
> struct
> union
>
>Now stand by for that Te(r)d-wit to reply with something completely inane...
>
>--
>Joe Foster <mailto:jfoster@ricochet.net> DC8s in Spaace: <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!
>
>

[Stephen Goguen]

> If you meant that VB would have a hard time telling the
> difference between a local "Someone" variable and a project wide "Someone"
> reference, that's the programmer's fault, using conflicting names.... the
local
> variable (reference object) would be used.

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

[Ted]

Appologies to you. Sorry for that.

"Zane Thomas" <zane@mabry.com> wrote:
>Ted,
>
>> Just can't get over can ya dumbass.
>
>We have a place for rants, name-calling, insults and often interesting
>discussions too. That newsgroup is the off.ramp newsgroup. Please take
>name-calling and etc there.
>
>Zane
>
>
>

[Zane Thomas]

Ted,

> Just can't get over can ya dumbass.

We have a place for rants, name-calling, insults and often interesting
discussions too. That newsgroup is the off.ramp newsgroup. Please take
name-calling and etc there.

Zane

[Zane Thomas]

Ted,

> Appologies to you. Sorry for that.

No problem, thanks. We all get a bit carried away once in a while.

Zane

[Joe \Nuke Me Xemu\ Foster]

"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!

[Phil Weber]

> if(x = 5) {
> // do something here
> }

Stephen: I've been bitten by that one, but it was JavaScript, not C++.
Wasted about half a day!
---
Phil Weber

[Zane Thomas]

Phil,

> > if(x = 5) {

C# doesn't allow that, it gives an "cannot convert int to bool" error.
Dunno about VB. :-)

Zane

[Bill McCarthy]

"Zane Thomas" <zane@mabry.com> wrote in message
news:3b2803f1$1@news.devx.com...
> Phil,
>
> > > if(x = 5) {
>
> C# doesn't allow that, it gives an "cannot convert int to bool" error.
> Dunno about VB. :-)
>

hehe... yep that one will catch a few VBers going to C#. In C# that should be
==
BTW: in VB.NET you can test for If x =5 Then, but not If x Then