Singleton pattern in VB6 & MTS
MV
Here's what I've done:
- I created a GlobalMultiUse class
- With a Public Static Function GetInstance and a static
member within (Static m_objFactory As
Notif.clsInterfaceFactory)
What's missing?, how do I 'hide' this class constructor
since I cannot configure this class as PublicNotCreateable?
One last question: Are there any (threading) issues in
placing this GlobalMultiUse class in MTS?
Thanks a lot
Steffen Ramlow
"MV" <m_vi...@hotmail.com> wrote in message
news:8c9a01c208ab$7c0271c0$a4e62ecf@tkmsftngxa06...
> What is the best way to implement this pattern in VB6?
>
> Here's what I've done:
> - I created a GlobalMultiUse class
don't do it! it is not safe
> - With a Public Static Function GetInstance and a static
> member within (Static m_objFactory As
> Notif.clsInterfaceFactory)
humm - what is a static method in VB?? my VB6 compiles it - but i have no
clue what it means
2 build a singleton with VB6:
make ur dll single threaded and store the pointer to the instance in a
standard module
this may become a performance bottleneck since ur instances runs on the same
thread the whole time
or:
ROT
Joseph Geretz
> > - I created a GlobalMultiUse class
>
> don't do it! it is not safe
Digressing a bit from the issue if Singleton. What's wrong with
GlobalMultiUse in general? Why is this any less desirable than a BAS module?
> humm - what is a static method in VB?? my VB6 compiles it - but i have no
> clue what it means
Static: Optional. Indicates that the Sub procedure's local variables are
preserved between calls. The Static attribute doesn't affect variables that
are declared outside the Sub, even if they are used in the procedure.
Hmm. Does this cause the Method's variables to be stored in TLS?
Interesting, safer than regular Global variables, since MethodA and MethodB
can each have their own static variable with the same name, without causing
a collision. But what about two of the same methods in the same STA
'stepping on' each other's static variables (the way any global variable can
be stepped on). Interesting...
--
Joseph Geretz
jge...@nospam.com
(replace nospam with FPSNow to reply by e-mail)
"Steffen Ramlow" <nos...@gmx.net> wrote in message
news:umTyCYLCCHA.1108@tkmsftngp04...
solex
Check this link out, (I found Willy to be very helpful):
http://users.skynet.be/wvdd2/General_techniques/Singletons/singletons.html
Dan
"MV" <m_vi...@hotmail.com> wrote in message
news:8c9a01c208ab$7c0271c0$a4e62ecf@tkmsftngxa06...
Steffen Ramlow
"Joseph Geretz" <jge...@nospam.com> wrote in message
news:eNA51hLCCHA.1696@tkmsftngp05...
> > > Here's what I've done:
> > > - I created a GlobalMultiUse class
> >
> > don't do it! it is not safe
>
> Digressing a bit from the issue if Singleton. What's wrong with
> GlobalMultiUse in general? Why is this any less desirable than a BAS
module?
it is not testet with com+
u may get a strange behaviour
> Hmm. Does this cause the Method's variables to be stored in TLS?
> Interesting, safer than regular Global variables, since MethodA and
MethodB
> can each have their own static variable with the same name, without
causing
> a collision. But what about two of the same methods in the same STA
> 'stepping on' each other's static variables (the way any global variable
can
> be stepped on). Interesting...
i have no clue.
Joseph Geretz
> > GlobalMultiUse in general? Why is this any less desirable than a BAS
> module?
>
> it is not testet with com+
> u may get a strange behaviour
Sounds like some developers I've met :-)
But seriously, I've been using GlobalMultiUse since MTS, continued using it
with COM+ and have seen no undesirable effects. I have encountered some
Microsoft consultants (really no different than you or me, they just wear
different logos on their jerseys) who, like yourself, advised against it.
But they couldn't provide any reason not to use it, they just 'advised' that
it shouldn't be used.
So until someone can provide me an explanation of how this can have an
adverse affect on my applications (with a factor which is relevant to my
applications) I'll keep using it. The microprocessor doesn't seem to care
:-)
(If a future implementation of COM+ 'breaks' my usage of GlobalMultiUse,
I'll just 'retreat' and convert these into BAS modules. My GlobalMultiUse's
are simply libraries of absolutely stateless methods. The syntactical impact
on the codebase will be minimal.)
--
Joseph Geretz
jge...@nospam.com
(replace nospam with FPSNow to reply by e-mail)
"Steffen Ramlow" <nos...@gmx.net> wrote in message
news:ebiJcqMCCHA.2172@tkmsftngp04...
Steffen Ramlow
> My GlobalMultiUse's
> are simply libraries of absolutely stateless methods. The syntactical
impact
> on the codebase will be minimal.)
moooment :-)
we were talking about state. if ur GlobalMultiUse's do not have state - then
it is ok
btw: why do u use then GlobalMultiUse's and mit standard modules?
maintenance?
solex
Based on the title of this thread: "Singleton pattern....", I believe that
the problem is that one should not confuse "Global Multi-Use" with
Singleton.
"Joseph Geretz" <jge...@nospam.com> wrote in message
news:#snqH6MCCHA.2672@tkmsftngp05...
Joseph Geretz
then
> it is ok
OK, I was just curios, because you expressed reservation above, when I
mentioned GMU on a different thread when we were taliking about BAS modules.
> btw: why do u use then GlobalMultiUse's and mit standard modules?
> maintenance?
Yeah. I don't like to recompile the whole app, just to
correct/enhance/upgrade code inside of a shared utility method. What if a
developer forgets one project :-( late at night, these things happen ;-) And
managing shared BAS modules is a pain. If they're not in the project
directory, you zip up the project and when you get home you find you're
missing code :-(. If you replicate them then you need to keep them in synch.
Yes, you can use VSS for this and I do this upon occasion, but I do keep
shared BAS usage to a minimum. I favor GMU.
MV
<solex> wrote in message news:#vvvQuLCCHA.2540@tkmsftngp05...
Enrico Sabbadin
you can make network wide singletons with .NET
p.s.: watch for the singleton not to get a bottleneck, and consider it gets
a single point of failure.
this is all you need to make Basicbroker class a singleton
-------------
Dim l_channel As tcp.tcpChannel = New tcp.tcpChannel(1098)
ChannelServices.RegisterChannel(l_channel)
Dim l_obj As Object = Activator.CreateInstance("MomBrokerNETRemotingImpl",
"MomBrokerNETRemotingImpl.BasicBroker").Unwrap()
RemotingServices.Marshal(CType(l_obj, MarshalByRefObject),
"MomBrokerNETRemotingImplUri")
Console.ReadLine()
-----------
rememebr that Basicbroker must inherit form marshalbyrefobject & must call
Public Overrides Function InitializeLifetimeService() As Object
Return Nothing
End Function
to never die
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"MV" <m_vi...@hotmail.com> wrote in message
news:8c9a01c208ab$7c0271c0$a4e62ecf@tkmsftngxa06...
Steffen Ramlow
"Enrico Sabbadin" <sabb...@infinito.it> wrote in message
news:OyhSAWnCCHA.1108@tkmsftngp04...
> Dim l_channel As tcp.tcpChannel = New tcp.tcpChannel(1098)
damned - u r still using VB? :-)
Enrico Sabbadin
languages (remember I started computer programming with Access 1.0 :) ).
I'll love c# a little bit when it will convert for me automagically system
to System ..do i ask too much ? :)
and btw, the C# intellisense messes up very often.
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"Steffen Ramlow" <nos...@gmx.net> wrote in message
news:#to4eYnCCHA.1360@tkmsftngp05...
Steffen Ramlow
> well, I don't know if I'll never get a C# guy, I hate so much case
sensitive
> languages (remember I started computer programming with Access 1.0 :) ).
hm - the only time i had a prob with C# was String (java) vs. string (c#)
i got it now.. :-)
hm, hm
i would recommend c#...
Enrico Sabbadin
tell me why you think C# is better then VB.NET ...
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"Steffen Ramlow" <nos...@gmx.net> wrote in message
news:u3LE3znCCHA.1576@tkmsftngp04...
Steffen Ramlow
"Enrico Sabbadin" <sabb...@infinito.it> wrote in message
news:ulIIy5nCCHA.2164@tkmsftngp02...
> Ok .. you want to start the flame ! :)
> tell me why you think C# is better then VB.NET ...
- no regards to vb
- not handled as toy language (u should read the some java-ng's..)
- nearly compatible with java
- language of coice for most tutorials / commerial impls / ... based on .net
- ...
Joseph Geretz
Fwooooooossssshhhhhh
Maybe it's just me. But I've got both books by Andrew Troelsen from APress.
C# and the .Net platform; Visual Basic.Net and the .Net Platform. I have not
had time to go through both of these in depth but what I have seen seems a
cut-and-paste job from one book to the other. Same examples, just different
code implementations. Browsing through the index, I see the same topics
covered.
So here's what I'd like to know. What is it that C# can do, that VB.Net
can't? And what about vice versa? What is quicker to implement in C#? In
VB.Net? From what I've seen so far, 99.44% of the power of .Net is in the
framework. The language of choice is just the glue to hold it together.
(And I don't care if the Java guys sneer at me. I've got my flame suit on
anyway. Anyway, ex-COBOL guys are immune to stuff like that :-)
--
Joseph Geretz
jge...@nospam.com
(replace nospam with FPSNow to reply by e-mail)
"Steffen Ramlow" <nos...@gmx.net> wrote in message
news:OO7BuNoCCHA.1764@tkmsftngp02...
Steffen Ramlow
> So here's what I'd like to know. What is it that C# can do, that VB.Net
> can't? And what about vice versa? What is quicker to implement in C#? In
> VB.Net? From what I've seen so far, 99.44% of the power of .Net is in the
> framework. The language of choice is just the glue to hold it together.
i did not said that there is something what can't be done on VB.Net or in c#
ok, there r little things like delegates or latebinding, but it doesn't
matter
> (And I don't care if the Java guys sneer at me. I've got my flame suit on
> anyway. Anyway, ex-COBOL guys are immune to stuff like that :-)
well, but in my opinion:
- most teams will use c#, then it should / will not be allowed to use vb.net
- most (server side) jobs will be c#, not vb.net
Enrico Sabbadin
I'd say we all agree that 99% language is irrelevant in .net,
at least when some well documented performance measurement will show c# is
faster.
btw, if you want I'll give you the tip on how to set "option strict on" by
default on new vb.net projects :)
about java guys, who cares :)
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"Steffen Ramlow" <nos...@gmx.net> wrote in message
news:uVpVxiuCCHA.2096@tkmsftngp04...
Michael D. Long
Microsoft Support, one of the first things they ask is if your
components are GlobalMultiUse.
Michael D. Long
Microsoft MVP - Windows SDK
"Joseph Geretz" <jge...@nospam.com> wrote in message
news:eNA51hLCCHA.1696@tkmsftngp05...
Alejandro Mesa
Limitations of GlobalMultiUse Objects
When you’re deciding whether to use a global object or explicitly declare a variable to hold an instance of an object, the following may be of use:
- You can’t set the hidden reference to a global object to Nothing when
you’re done using it. Visual Basic does not provide any way to access the
hidden global object directly.
- GlobalMultiUse is a convenience for programmers; you incur the same slight
overhead on each procedure call as you would if you used a global variable
declared As New (for example, As New Financials).
- As explained earlier in this topic, when you are authoring a component
that provides a GlobalMultiUse class, you cannot use the properties and
methods of the class if they were global procedures.
Joseph Geretz
"Alejandro Mesa" <alej...@gardensamerica.com> wrote in message news:elesIkyCCHA.2004@tkmsftngp02...
Joseph Geretz
> Microsoft Support, one of the first things they ask is if your
> components are GlobalMultiUse.
Tell them no... ;-)
I have a bit of skepticism toward any technical advice which can't be
rationally explained. Again, let me qualify my GMU usage. Purely stateless
methods. No class level variables whatsoever. I've met more than one MS
consultant in the past who recommended against GMU, but not a single one who
could explain what was actually wrong with it. Witch hunts for the new
millenium...
"Michael D. Long" <michael...@bellsouth.net> wrote in message
news:uRWbNLyCCHA.2572@tkmsftngp05...
Joe "Nuke Me Xemu" Foster
> What is the best way to implement this pattern in VB6?
Beware of GMU classes -- they can always be instantiated "manually",
though this may not be a problem in your particular case. However,
ActiveX DLLs compiled to native code can also sometimes be shut down
without having all their Class_Terminate events fire. Dunno if this
can also happen with ActiveX DLLs compiled to P-code instead.
This may be another potential drawback of "stateful" GMU classes:
URL:http://groups.google.com/groups?selm=613d01c1baed%242dbcadc0%24a4e62ecf%40tkmsftngxa06
The rest of the thread is also interesting, or even frightening...
--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <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!
Joe "Nuke Me Xemu" Foster
> not such a big flame :)
> I'd say we all agree that 99% language is irrelevant in .net,
Even in Cobol.NET, Fortran.NET, or <shudder/> APL.NET!?
URL:http://www.adtools.com/info/whitepaper/dotnet_whitepaper.html
URL:http://www.fs.fujitsu.com/products/fortran.html
URL:http://www.dyadic.com/msnet.htm
> at least when some well documented performance measurement will show c# is
> faster.
> btw, if you want I'll give you the tip on how to set "option strict on" by
> default on new vb.net projects :)
>
> about java guys, who cares :)
Even though C# and B# are just Java with the serial numbers filed off and
your "choice" of a quickie paint job?
--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
Steve Walker
<nos...@gmx.net> writes
I quite like the case sensitivity. I like being able to use theVariable
as a variable name, and TheVariable as a property name, for example. The
way VB6 recased your source code got on my nerves, too.
>hm, hm
>
>i would recommend c#...
So would I, but it's more of an aesthetic consideration than anything
else...
--
Listen to others, even to the dull and ignorant;
for you too may be a Manager some day.
steve at otolith dot demon dot co dot uk
http://www.otolith.co.uk/
Steve Walker
<jge...@nospam.com> writes
>So here's what I'd like to know. What is it that C# can do, that VB.Net
>can't?
Unsafe code, although we've decided that anyone wanting to use pointers
needs a damn good justification for it, and I don't expect to see it
used much.
Operator overloading; yeah, I know, syntactic sugar for a static method,
but it *is* cool.
Explicit casting; I don't know what VB.NET does about this, do we still
have Evil Type Coercion?
Oh, XML comments are neat.
>And what about vice versa? What is quicker to implement in C#? In
>VB.Net?
Dunno. I haven't done very much in VB.NET. When I did the initial
evaluation, it was with the prejudice that we would be going VB, and
that C# was just for the C++ guys. We were getting very excited about
the new OO features in VB, but we switched track fairly early. C# looked
more elegant, and was pretty easy to learn. There was also a feeling
that we didn't want to end up working with the less favoured son, if you
see what I mean.
>From what I've seen so far, 99.44% of the power of .Net is in the
>framework. The language of choice is just the glue to hold it together.
Quite. It doesn't really matter, it's much more a matter of personal
preference than anything else. It's nice that sample code written in
either language is perfectly comprehensible to either party.
Joseph Geretz
> as a variable name, and TheVariable as a property name, for example. The
> way VB6 recased your source code got on my nerves, too.
I've got to disagree. If I had a developer using variable names like
PrincipalAmount and principalAmount in the same scope, we'd need to have a
discussion. One typo can cost hours in debugging.
- Joe Geretz -
Steve Walker
<jge...@nospam.com> writes
But they aren't both variable names, one is effectively a method name; I
can see the risk of typos, but if you've standardised on camel casing
for variables and Pascal casing for methods, it should be clear.
Obviously, principalAmount (the class level storage variable) should be
semantically the same as PrincipalAmount (the accessor method). If the
property is calculated, rather than merely validated/encapsulated, the
variable name should be something else. The alternative is using
Hungarian-style scope specifiers, which apparently we are now
discouraged from doing, or else thinking up synonyms, which seems likely
to make the code even harder to read for a non domain-expert (What has
trainRollingResistanceNm to do with TrainFrictionNm?).
Possibly dictating that only property sets/gets are allowed directly to
access internal variables, and that other access is through
this.PrincipalAmount would be wise; there's some merit in it as a design
pattern, in that it makes any internal modifications to the value of
principalAmount go through the same validation process as an external
modification, and reduces the impact of changing
set{principalAmount = value;}
to
set{this.NewAccountStuffObject.PrincipalAmount = value;}
Obviously there is some overhead if you already know that value is
valid, but it's more robust, and will get inlined if the implementation
is trivial.
I think that, ultimately, it doesn't really matter what your naming
convention is, so long as everyone understands and follows it, and while
I can see why variables differing only in case might cause a few
jitters, you may as well use it, and it's much more dangerous if its
random.
Joseph Geretz
simply mistakes and, as such, are outside the realm of logic. As long as
humans are involved, mistakes will occur, no matter how elegant and
persuasive your arguments are.
One thing which characterizes my basic development strategy, is not so much
the attempt to eliminate mistakes altogether; as long as humans are
involved, this is an impossible goal. Rather I strive to utilize
methodologies which eliminate types of mistakes which can occur, in order to
reduce the number of mistakes which ultimately do occur.
> I think that, ultimately, it doesn't really matter what your naming
> convention is, so long as everyone understands and follows it, and while
> I can see why variables differing only in case might cause a few
> jitters, you may as well use it, and it's much more dangerous if its
> random.
If your language does not support cases sensitivity, then it's not dangerous
at all, since it's impossible to have two variables in the same scope whose
names differ only by case. Not by convention, and not by random chance
either. This reduces a rather common cause of error - the common typo.
- Joe Geretz -
"Steve Walker" <st...@spam.spam.spam> wrote in message
news:+oQdPrKZMS$8E...@otolith.demon.co.uk...
Joseph Geretz
Oops! There goes one now - typos not typo's.
:-)
Joe "Nuke Me Xemu" Foster
> Obviously, principalAmount (the class level storage variable) should be
> semantically the same as PrincipalAmount (the accessor method). If the
> property is calculated, rather than merely validated/encapsulated, the
> variable name should be something else. The alternative is using
> Hungarian-style scope specifiers, which apparently we are now
> discouraged from doing, or else thinking up synonyms, which seems likely
> to make the code even harder to read for a non domain-expert (What has
> trainRollingResistanceNm to do with TrainFrictionNm?).
>
> Possibly dictating that only property sets/gets are allowed directly to
> access internal variables, and that other access is through
> this.PrincipalAmount would be wise; there's some merit in it as a design
> pattern, in that it makes any internal modifications to the value of
> principalAmount go through the same validation process as an external
> modification, and reduces the impact of changing
Lately I've been putting all private member variables into a Private Type
and using This.Whatever to get at them. One advantage is that you get an
Intellisense list of the member variables! Here's a quickie example:
option explicit
private type stash
a as double
r as double
end type
private this as stash
public property get x() as double
x = this.r * cos(this.a)
end property
public property get y() as double
y = this.r * sin(this.a)
end property
public sub init(byval a as double, byval r as double)
if r < 0 then err.raise 5 ' invalid procedure call or argument
this.a = a
this.r = r
end sub
--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
Enrico Sabbadin
but anyway .. my degree is on nuclear engineering .. if i think about all
the flames i had to face about pro or against nuclear power plants, this
java vs .net or case sensitive against case insensitive sounds just like a
funny game to me :)
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"Steve Walker" <st...@spam.spam.spam> wrote in message
news:ySX+xuHHRL$8E...@otolith.demon.co.uk...
Enrico Sabbadin
the states so slang stuff has got hard to understand again :(
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:ukqCct1CCHA.2540@tkmsftngp05...
Joseph Geretz
> what's a "quickie paint job" ?
It's a cheap paint job you put on an old piece of junk car in order to make
it look new. The engine is still junk but you can fool someone into giving
you a better price for it. How do you say that in Italian?
- Joe Geretz. -
"Enrico Sabbadin" <sabb...@infinito.it> wrote in message
news:O92f7TBDCHA.1064@tkmsftngp04...
Joseph Geretz
> but anyway .. my degree is on nuclear engineering ..
NO! Not the 'button'! I said press the 'Button' :-)
BOOM! :-(
"Enrico Sabbadin" <sabb...@infinito.it> wrote in message
news:ufy#LSBDCHA.1272@tkmsftngp04...
Enrico Sabbadin
.. again .. who cares :)
--
Enrico Sabbadin
sabb...@infinito.it
MTS - COM+ - VBCOM - Security FAQ / .NET, COM+, XML books selection & more :
http://www.sabbasoft.com
"Joseph Geretz" <jge...@nospam.com> wrote in message
news:##yzwaBDCHA.1880@tkmsftngp04...
Steve Walker
<jge...@nospam.com> writes
>Everything you say is quite logical and quite correct. However, typo's are
>simply mistakes and, as such, are outside the realm of logic. As long as
>humans are involved, mistakes will occur, no matter how elegant and
>persuasive your arguments are.
Sure, I take your point, but that kind of bug is likely to happen
however you get round naming synonymous variables, unless you use a
scope specifier. Is that the approach your folks are using, or have you
another way round it? I had a feeling that you got a compiler warning if
you had local variables overriding class level ones, but you don't.
Perhaps you should. Perhaps it falls into one of those areas where you
really need a third-party tool to enforce your particular rules; Numega
sell something that does this kind of thing.
>One thing which characterizes my basic development strategy, is not so much
>the attempt to eliminate mistakes altogether; as long as humans are
>involved, this is an impossible goal.
Quite. I've only ever induced a recursive loop in a VB6 property get
once, but I've seen plenty of other people stumped at why they are
getting a stack overflow on property access... It's one of those things
so simple and obvious that unless you've seen it before, you don't see
it; it's like those sentences contrived to show that people don't
actually read text properly, they scan it;
A bird
in the
the hand
kind of thing.
>> I think that, ultimately, it doesn't really matter what your naming
>> convention is, so long as everyone understands and follows it, and while
>> I can see why variables differing only in case might cause a few
>> jitters, you may as well use it, and it's much more dangerous if its
>> random.
>
>If your language does not support cases sensitivity, then it's not dangerous
>at all, since it's impossible to have two variables in the same scope whose
>names differ only by case. Not by convention, and not by random chance
>either. This reduces a rather common cause of error - the common typo.
True, but at the cost of having to think up synonyms rather than use a
consistent convention; again, unless you use m_ or similar.
It's a small thing, case sensitivity, and I think it's one of those
areas where language choice falls into personal preference. If you don't
like it, it's a pain in the butt, if you do like it, it's a benefit of
the language.
Steve Walker
<sabb...@infinito.it> writes
>in my opinion whoever likes case sensitive is sick :) ..
>but anyway .. my degree is on nuclear engineering .. if i think about all
>the flames i had to face about pro or against nuclear power plants, this
>java vs .net or case sensitive against case insensitive sounds just like a
>funny game to me :)
<g>
Funnily enough, my current project's Project class includes a
"Sensitivity" class, containing a bool and an InternalContact:Person.
We're a civil engineering company, and we may have done some nuclear
work...
Steve Walker
<j...@bftsi0.UUCP> writes
Bloody hell, Joe, for a second there, when I saw this.foo I thought you
had adopted C#...
Don't scare me like that.
:o)
It's an interesting approach, and from a C# point of view, using a value
type for the internal field storage should be very cheap; if the
implementation is trivial, it will get inlined, and the storage object
will be on the stack. Same goes for VB.NET. I can't imagine that there's
much overhead in VB6 either.
It looks conceptually like abstracting data from methods, so;
___________ ___________
| class |1 1| data class|
|___________|<>--|___________|
|-data class| | +members |
|-----------| |-----------|
| +methods | |___________|
|___________|
Joseph Geretz
> however you get round naming synonymous variables, unless you use a
> scope specifier. Is that the approach your folks are using, or have you
> another way round it?
> True, but at the cost of having to think up synonyms rather than use a
> consistent convention; again, unless you use m_ or similar.
That's exactly how I do it. From what I've seen, this is pretty common in
fact. So confusing a local variable with a module scoped variable would take
more than a minor typo.
- Joe Geretz -
Steve Walker
<jge...@nospam.com> writes
>> Sure, I take your point, but that kind of bug is likely to happen
>> however you get round naming synonymous variables, unless you use a
>> scope specifier. Is that the approach your folks are using, or have you
>> another way round it?
>...
>> True, but at the cost of having to think up synonyms rather than use a
>> consistent convention; again, unless you use m_ or similar.
>
>That's exactly how I do it. From what I've seen, this is pretty common in
>fact.
It is common, and was our standard. MS are now, it would seem,
discouraging the use of Hungarian warts, and we're now using a
case-sensitive language, so we're rethinking our conventions.
>So confusing a local variable with a module scoped variable would take
>more than a minor typo.
True. Are you using cClassName? The argument about giving good names to
classes and thus denying them to objects falls into the same territory;
we would have used;
dim oMyClass as new cMyClass
whereas we are now considering
MyClass myClass = new MyClass();
We haven't really sorted this out thoroughly, but my gut feeling is that
if we aren't having scope and type specifiers baked into variable names,
we probably ought to make use of case to encode some of that
information.
Joseph Geretz
> discouraging the use of Hungarian warts, and we're now using a
> case-sensitive language, so we're rethinking our conventions.
Best idea I've heard all day! So many of today's conventions and standards
in many shops are really holdovers from a different development era.
> We haven't really sorted this out thoroughly, but my gut feeling is that
> if we aren't having scope and type specifiers baked into variable names,
> we probably ought to make use of case to encode some of that
> information.
Actually, I'd restate that just a bit. if you don't bake scope and type
specifiers into variable names, you might first want to consider whether you
need to have this. If you decide that you should, then you will want to
consider what sort of convention you want to use. Personally, I'd find
reliance on case to be a bit too obscure and less than intutitive. Everyone
understands what m_ means. I'm sure though, that if you use case to indicate
this, a lot of your developers will spend a lot of their time wondering....
Was that uppercase private and lowercase module level?
or
Was that uppercase module level and lower case private?
I know I would.
Not to mention the havoc a small typo would cause.
As far as type - I beleive that encoding the type specifier into the
variable name is a holdover from days when the variable was declared way way
up at the top of the source and then used way way down at the bottom. (COBOL
was like this - all variable were globals.) finding out the type of a
varible could be physically inconvenient whether you were scanning through a
printout or viwing the source on-line.
We don't do stuff like this nowadys. (When is the last time you printed out
your source? I haven't even seen a ream of greenbar in years! newcomer's
will be asking 'what's greenbar' :-)
Globals are discouraged and most variables are locals. Furthermore most
methods are relatively short in length (or they should be!). Thus to find
the type of a variable usually requires simply scrolling back 10 lines or
so. In this scenario, if I need to know the type of a variable, I'm going to
look at its declaration which is more reliable than looking at its name.
What if a developer changed the type but didn't change the type specifier
prefix? Also, IntelliSense provides type definition for parameters so that's
not needed anymore either.
(I don't see why VB can't give us a tooltip when we hover the mouse over a
variable or method declaration and give us the scope and type. Hmm. Sounds
like an idea for an add in. Is this possible?)
In a nutshell, that's why I elect to use scope specifiers, but don't use
type specifiers. I also don't emphasize comments as much as others seem to
do, but that's another issue...
http://www.smotricz.com/kabutz/Issue039.html
- Joe Geretz -
Klaus H. Probst
> in my opinion whoever likes case sensitive is sick :) ..
> but anyway .. my degree is on nuclear engineering .. if i think about all
> the flames i had to face about pro or against nuclear power plants, this
> java vs .net or case sensitive against case insensitive sounds just like a
> funny game to me :)
My company did a project at a nuclear generation station once... you
couldn't believe all the jokes about On Error Resume Next :-)
____________
Klaus
Slava
Steve Walker
<jge...@nospam.com> writes
>> It is common, and was our standard. MS are now, it would seem,
>> discouraging the use of Hungarian warts, and we're now using a
>> case-sensitive language, so we're rethinking our conventions.
>
>Best idea I've heard all day! So many of today's conventions and standards
>in many shops are really holdovers from a different development era.
Yes. The standard we had was reached by consensus, not too hard to do
when there are only four of you. I did document it in a standards and
conventions document about six months ago, when we had three new guys
join the team. It will have to be redone anyway, because some of the
rules have changed with .NET and C#.
>As far as type - I beleive that encoding the type specifier into the
>variable name is a holdover from days when the variable was declared way way
>up at the top of the source and then used way way down at the bottom. (COBOL
>was like this - all variable were globals.) finding out the type of a
>varible could be physically inconvenient whether you were scanning through a
>printout or viwing the source on-line.
Yes. It's less of an issue with explicit casts and no implicit narrowing
conversions, too. The only strict standard I'd still use is a units
postfix in anything engineering-related. Being able to do dimensional
analysis on a function makes some mistakes very obvious. (Not that I do
much of that, almost all of our modelling software is written by experts
in the problem domain rather by full-time programmers)
>We don't do stuff like this nowadys. (When is the last time you printed out
>your source? I haven't even seen a ream of greenbar in years! newcomer's
>will be asking 'what's greenbar' :-)
I know what you mean, but I've never used it, and never seen it since I
was an undergraduate!
>(I don't see why VB can't give us a tooltip when we hover the mouse over a
>variable or method declaration and give us the scope and type. Hmm. Sounds
>like an idea for an add in. Is this possible?)
I'd have thought so. The IDE is scriptable, isn't it?
>In a nutshell, that's why I elect to use scope specifiers, but don't use
>type specifiers. I also don't emphasize comments as much as others seem to
>do, but that's another issue...
>
>http://www.smotricz.com/kabutz/Issue039.html
Wow! REM brings a few memories back, though in my case it was CBM BASIC,
not Sinclair... I take his point, although the trouble with self
documenting code is that the person who thinks the function is obvious
already understands it!
The classic "bad comment",
//initialise q to 7
int q = 6;
kind of thing, we've all seen, and probably also the comments put in by
programmers who are so proud of a neat bit of code that they have to put
in an explanation of just how clever they are being (this is really just
a variation on
//You aren't meant to understand what this does
) but I think a quick explanation of the rationale for something
non-intuitive is worthwhile, particularly if something has been done for
no apparent reason.