S
Scott M.
I rarely put anyone on my filter list, so if he's on it, he must be a real
winner!
winner!
lloyd
I just said that 80% of vb6 programmers 'never used a class'
why did we need to get enlightened?
does moving to classes make our code faster?
so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?
I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it
does this make the app slower?
does it make carol in accounting enter data _FASTER_ ??
something close to it). My (personal, mind you) rule of thumb is, if I
must use Imports, then I must create an alias to it:
Imports SysThread = System.Threading
Imports SysRegex = System.Text.RegularExpression
As opposed to:
Imports System.Threading
Imports System.Text.RegularExpression
Don't know if this relates to what you're talking about, and my
apologies if it drifts to OT.
namespace-qualified types inside the implementation because they blow up
code resulting in very long lines. In general I qualify types (classes,
structures, ...) and functions (in modules) only if there would be a name
clash otherwise.
startup a vb6 forms app.. and startup a vb 2005 forms app
it's obvious to me which is faster
module aaron
module matt
I can refer to aaron.method1 or matt.method2 just as easily as with a
class; but I don't need to instantiate an instance of the class first
module aaron
module matt
I can refer to aaron.method1 or matt.method2 just as easily as with a
class; but I don't need to instantiate an instance of the class first
yeah, vb6 had classes; it didn't support inheritence
Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.
Zytan
with a module. You can have a module that relies on functions in
another module, just as you can have a class that relies on functions
in another class. Both create cause your code to be tightly coupled,
and that should be avoided as much as possible, whether you use classes
or modules.
Yes, very true. I guess that's what I was trying to say, is that
neither is worse than the other. But, yeah, the way my post came out
was ridiculous. Thanks for clarifying.
Zytan