[AccessD] OOP vs OBP

[Arthur Fuller]

I have never once called it useless. Your library has taught me numerous
tips and tricks, and I am thankful for that. So let's instead call this a
linguistic question. C# and C++ and Actor and numerous other languages are
OOP, not OBP, which is not to denigrate the latter, and in fact it's much
harder to write OOP than OBP. It just depends on what you need to do.

On Sun, Sep 6, 2020 at 10:36 AM John Colby <jwcolby at gmail.com> wrote:

> Arthur Fuller via <https://support.google.com/mail/answer/1311182?hl=en>
> databaseadvisors.com
> 8:26 AM (1 hour ago)
> to Access
> Without question you are one of the most skilled Access developers I have
> ever encountered. Also without question is the fact that one can work magic
> by wrapping Access classes. My sole objection was one of terminology. I
> distinguish OOP from OBP (Object-based programming). Let's use another
> example. An ancient language called Clipper introduced objects in V. 5.0,
> most notably Tbrowse,  which meant table-browser. I discovered that one
> could reduce a Tbrowser to a very tiny area, equivalent to the navigation
> buttons onan Access form, and then attach an actual form to this, so the
> form refreshed as one navigated using the Tbrowse object. That is not OOP,
> it is OBP., for the simple reason that I could not create a class from
> scratch, but merely create descendant classes. That is not to say that
> descendant classes are not powerful. But it is to say that OBP will not
> allow you to create classes from scratch -- say, for example, that I want
> to create a slider control.  In Access, this is impossible. That is all
> that I mean by distinguishing OOP from OBP. It's not an insult to Access or
> its developers, or any virtuoso such as you or Shamil or Jim Dettman (whose
> work is astounding). But it is to say that I cannot create a class from
> scratch, such as a Slider control. I have to begin with the existing
> classes and then wrap them.
> A.
>
> I understand and fully admit that Access cannot use inheritance.  However,
> the primary tenants of OOP are encapsulation of data and code, and
> abstraction - exposing a specific interface to users of the class, hiding
> the implementation details of what and how the class does whatever it
> does.  OOP is now generally considered to use inheritance, but not always.
> The terms OO was used way back when well before inheritance raised it's
> head.
>
> Google's Go language is usually considered an OOP language and yet has no
> inheritance.  It does have interfaces, as does Access.  Interfaces
> basically define what an object will look like, but completely absent any
> code or data.  What that allows however is passing of objects, as well as
> dimensioning objects that are "of" an interface instead of "of" a specific
> type.  So as long as the object being passed or dimensioned implements that
> interface it can be used in that context.
>
> Access, internally, is actually OOP complete with inheritance.  However it
> has a hard boundary, i.e. we cannot inherit any of the objects that are
> Access.
>
> As for me, I don't really care what you call it, what matters is what I can
> do with it.  I worked in C# for about 2 years, writing a pretty darned
> complex, system to automate SQL Server, exporting and importing data and
> doing other stuff, threaded. And never once inherited anything.
> Inheritance, while it can be useful, is IMHO highly over rated. In the end
> I can't use it in Access so I just move on to what I can do.
>
> So call it whatever you like.  Just don't call it as useless.
> --
> John W. Colby
> Colby Consulting
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


-- 
Arthur