[AccessD] Class Rebuttal was: Basic Unbound Form ...

There probably isn't anything wrong with using a goto. Every VB routine with
error handling has one. It's when there are gotos all over the place that
the spaghetti starts getting tangled! :-)

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Tuesday, June 13, 2006 11:23 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...


<<Not the language, I like inheritance, in fact, if they could have just
given VB inheritance, it would blow .Net out of the water. >>

  You should try VFP.  But I'm far from convinced that OOP is everything it
is cracked up to be either.

  It still amazes me how often we reinvent computer concepts and in the
process, just make it more difficult to get the job done.

  I still argue that there is nothing wrong with using a GOTO <g>.

  Let's see what that starts<g>....

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com
Sent: Tuesday, June 13, 2006 10:48 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...

On a lighter topic.... .Net.  You know, I've played around with it, and
quite frankly, I don't like it.

Not the language, I like inheritance, in fact, if they could have just given
VB inheritance, it would blow .Net out of the water.  

What really bugs me is the .Net framework required to implement a project.
VB had it's runtimes....ok, so you couldn't create a drop in place .exe,
like you can in C++ (or Power Basic), but you're talking about 1.5 megs
worth of a runtime, not 40 megs.  That is just too much of a pain with what
I do.  Doesn't make up for the extra capabilities of .Net.

Just my humble opinion.

Drew

-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com]
Sent: Tuesday, June 13, 2006 9:37 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...


Ken,

It is valid to suggest alternatives IF the alternatives provide essentially
the same functionality.  This list is about supporting development in
Microsoft Access.  For that reason alone, suggesting it as alternative is
probably unhelpful in this list.  

Depending on where you come from pretty much any language / environment is
"less useful" than some other.  Those who come from LISP say "it can't do
this that LISP can do", those that come from C++ say "it can't do this that
C++ can do".

I am not saying that Ruby isn't something that should be looked at by a
serious developer, but for developers wishing (or required) to develop in
Access, telling us what VBA can't do that Product XYZ can do just doesn't
accomplish much.

We have discussed at length what is missing in VBA, and it is indeed a lot.
In the end though, VBA is the integrated language for the current versions
of Office / Access.  Additionally, in spite of what anyone says, Access/VBA
is still one of the most RAD database application environments on the
planet, and by far the most widely accepted, i.e. the most work available
for / because of it.

Personally, I think that .Net is the future.  Microsoft has apparently
decided that it will be their future and at this point in time, they are the
elephant.  I will get there someday, but in the meantime, I eat because of
my Access skills.

John W. Colby

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Kenneth Ismert
Sent: Tuesday, June 13, 2006 10:05 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...


OK, lets see... 

Lambert is correct in that using public variables to create class properties
is 'bad practice', or at least non-standard.

Drew is correct in that because it can be done in the language, it is
'right', or at least allowable. 

But the interesting thing to me is no one talks about what is missing in VB
objects: 

 * No true class-level variables. All member variables of a class are
instance variables. Class variables would eliminate most of the need for
globals in VB.
 * No true constructor. You'd like to create objects like this, but you
can't: 
     Set Obj = New clsPerson("Ken", "123 Any St", 789)
 * No true singleton object. You can simulate it using modules with
properties, or public object variables, but neither approach is a complete
solution.
 * No inheritance model, whether it be single, multiple, or mixin. 

Finally, if you want compact and correct property declarations, look at this
Ruby example: 

  Class MyClass
    attr_accessor :name, :address, :emplID
  End

This creates the instance variables, getters and setters for the three named
properties, all in one line. 

I bring Ruby up because, in arguements over what are essentially limitations
of a language, it is valid to suggest alternatives.

-Ken
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com